Our users have thousands of meeting transcripts in Acta. They kept asking: “Can I just ask Claude about my meetings?” So we built an MCP server. Here’s what we learned.

  1. Don’t expose raw data; expose answers Our first version had one tool, get_transcript. Claude would pull a 2-hour transcript and run out of context. We added tools that return facts already worked out:

find_risks: risks raised across meetings
get_promises: who promised what, by when
check_follow_through: was a decision actually carried out?
decision_history: why something was decided, with the meeting it came from

The model gets short, structured facts instead of 40,000 words.

  1. Cite everything
    Every result numbers its facts [1] [2] and ends with source links to the exact meeting. Users trust answers they can check.

  2. Auth was the hard part
    Claude connects using OAuth with dynamic client registration: each client registers itself, and the user approves access to their own meetings only. It’s worth getting this right before you write any tools.

  3. Treat meeting text as data, not instructions
    Transcripts can contain anything people said. Our server tells the model never to act on requests found inside a meeting’s text. That’s basic prompt-injection hygiene for any MCP server over user content.

  4. Keep write tools small and explicit
    We allow a few safe writes (mark_action_item_done, comment_on_action_item) and nothing that sends email or deletes data.

What’s next
We’re using the same approach for Agent Builder, where actions always wait for human approval.

Questions about MCP auth or tool design? Ask in the comments.

(I’m the founder of Acta, an AI meeting notes app that records without a bot: https://acta.ai)

Before you publish, check the details are accurate:

the tool names;
the “never act on instructions in meeting text” rule;
that send and delete really aren’t exposed.

These match what your MCP server shows in this session, but your engineers should confirm before it goes out.