How Tiro Remembers Business Context: MCP, API, CLI, Skill
"Our team installed every AI tool, but the AI still doesn't know what was decided in our meetings."
This is the first wall most enterprise AI teams hit. Notion is connected. Jira is wired up. Slack is exposed through MCP. And yet the source of all that data, the meeting context that holds "why was this decision made," is out of an AI agent's reach.
The reason is simple. About 90% of business context is generated in spoken conversation and disappears without being digitized. Documents in Notion, tickets in Jira, messages in Slack – those make up only about 10% of the full context. The other 90% lives in "who said what and why in that meeting," and if no one captures it, it’s gone before the next meeting starts.
Handing that missing 90% to the AI is what Conversation Intelligence is for: take meeting audio and turn it into something an agent can actually use. But the conversion is only half the work. How you connect that context to the agent changes how the agent performs.
In the previous article, we covered the four tools (API, MCP, CLI, Skill) an AI agent uses to work with external systems. This article goes one step further: how to actually use those four tools to connect the disappearing 90% of context to an AI agent – and how Tiro solves this problem in practice.
The biggest empty space in the 5-Layer stack
AI Transformation has five layers: Context Source, Ontology, AI Model, Agentic Workflow, and User Interface. The top three, AI Model, Agentic Workflow, and UI, are already saturated. Models like Claude and GPT get smarter every month. Workflow tools like n8n and Zapier are accessible to anyone. Slack and the terminal are already great interfaces.
The bottom two layers, Context Source and Ontology, are empty in most organizations. And within Context Source, the biggest empty space is meeting and conversation data. This data lives as audio, vanishes the moment meetings end, and unless someone deliberately converts it, an AI cannot reach it.
The software that fills this gap is called Conversation Intelligence. Its core job is to take voice meeting data and turn it into a form that an AI can use, that is, LLM-Ready Data.
Digitizing context and connecting it to an agent are different things
Digitizing the context is only half the work. The other half is connecting the context so that the agent can actually use it. In a world where one meeting transcript is thousands to tens of thousands of tokens, the wrong connection design will slow the agent down.
One-line summary of the previous article: even with the same data, the destination changes depending on which tool an AI agent uses to access it. An API sends results wherever the code asks. An MCP returns them inside the chatbot's reply. A CLI drops them as files in a folder. A Skill carries them into the next procedure. The four tools are not substitutes. They are complements with different destinations.
For a Conversation Intelligence product, this principle matters even more. The data is inherently heavy: A one-hour meeting transcript can run as tens of thousands of tokens, an audio file can reach hundreds of megabytes, and thirty notes pulled at once is practically an encyclopedia in scale. Push it all through a single tool, and you’ll exceed what the AI can handle at one time.
That is why Tiro supports all four: API, MCP, CLI, and Skill.
Full spec at api-docs.tiro.ooo.
API: the skeleton
Under Tiro's API, 45 methods span four domains (Notes, Folders, Voice Files, Word Memory). It is the starting point for everything: connecting to another SaaS, calling from your own backend, or building an internal tool.
The API shines when no agent reasoning is needed. For example, "when a sales meeting ends, log it automatically in Salesforce," or "every Monday morning, have last week's meeting summaries already in a Notion page." Once IT wires it up, no human hands are involved.
A note: MCP and CLI both call this API underneath. That is why we call it the skeleton.
Real call examples are collected at the end of this article.
MCP: light context goes into the window
MCP is the path that lets a chatbot reach directly into meeting data. Ask Claude or ChatGPT, "What was decided last week that has not happened yet?", and the chatbot goes in through MCP, looks for itself, and answers.
Tiro's MCP server organizes 14 tools across six areas: Authentication, Notes Discovery, Notes Retrieval, Templates, Share Links, and Folders.
The core design principle is spending the token budget in stages. We call it Progressive Disclosure: a 3-step pattern.
Step 1. Questions like "what meetings did we have?" can be answered from a list of meetings and a short match snippet. So list_notes or search_notes pulls only metadata and match snippets first. Tens to hundreds of tokens per note, or a paragraph's worth. This is sufficient for most "What meetings did we have?"
Step 2. For notes that actually need their body, get_note pulls the body. The include option lets you choose a summary or a formal document. The summary is around 200 to 800 tokens.
Step 3. Only when you actually need the raw spoken content, get_note_transcript pulls the full transcript. Three to five thousand tokens, roughly one short story.
This staging cuts token usage by over 90% in typical search and summary scenarios. To find one meeting out of ten, pulling all ten transcripts costs about 30,000 tokens. The list_notes (list only) -> get_note (only the candidates' summaries) pattern lands at about 800 tokens.
MCP shines when the chatbot narrows judgement through multi-turn questions. "Of the decisions from last week's meetings, which haven't moved yet?" is a classic case. Scan the list, pull summaries for the relevant ones, and the reason: this chain is MCP territory.
CLI: heavy loads go to disk
Say a quarterly review is coming up, and you need transcripts from 12 customer meetings over the last 90 days. Pull all of that through MCP and you blow past what a chatbot can hold at once.
CLI is the path for dropping heavy loads into a folder. One command, and 90 days of meetings (12 of them) land as markdown in a folder. What the chatbot holds is a receipt: where it was saved and how big it is. The chatbot stays light.
The same work over MCP would call get_note_transcript 12 times, each time pouring the full transcript into the context window. For 12 notes, that is 60 to 600KB of dead weight. CLI sends results to disk and leaves only paths and metadata in context.
CLI shines for bulk operations and automation. Auto-generating weekly reports. Processing meeting data in CI/CD. Scheduled exports with cron. Wherever disk and pipes feel natural, CLI does the work.
Real command examples are collected at the end.
Skill: your team's procedure manual
Here, the story deepens. API, MCP, and CLI are tools. Tools gain value only when you know how to use them. Writing down the how is what Skill is for.
A Skill is procedural knowledge written into a SKILL.md markdown file. It does not fetch data or take action. It writes a guide ("for this task, in this order, use these tools") and the agent executes that procedure.
This matters because the same Conversation Intelligence data gets used differently by every organization. A consultancy connects client meeting summaries to a CRM. A product team turns sprint review decisions into Linear issues. HR converts interview records into onboarding material. Same data source, completely different workflows.
Two concrete examples.
Weekly metric review Skill
---
name: weekly-metric-review
description: Use to extract decisions and context from the weekly AARRR metric review meeting
---
## Procedure
1. Find this week's metric review meeting
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. Save each meeting's transcript to disk
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. Read the .md files in ./reviews/ and organize by:
- *Reasons* behind numeric changes (why did this metric rise or fall)
- Decisions and owners
- Experiment list for next week
4. Update the Notion weekly review page with the results
Quarterly client review Skill
---
name: quarterly-client-review
description: Use to synthesize the last 90 days of meetings for a specific client into a quarterly review
---
## Procedure
1. Search the last 90 days of meetings by client keyword
`tiro notes search "<client name>" --since 90d --json > client.jsonl`
2. Save transcripts to disk
`cat client.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./client-reviews/{}.md`
3. Read all transcripts and write the quarterly review by:
- Shifts in major discussion topics
- Open issues and risks
- Relationship health (positive/negative signals)
4. Post the result to the #account-reviews Slack channel
See the pattern? CLI lays the heavy data on disk, MCP makes judgements on light metadata, and Skill remembers the order. Borrowing the metaphor from the previous article: feet carry the load, hands handle the precision, muscle memory remembers the sequence.
Read, Reason, Act, Learn
Skill is not just a script collection. A well-designed Skill creates a loop.
Read. CLI brings meeting context to disk. MCP reads metadata and summaries.
Reason. The agent judges based on the context: "this customer has repeated the same complaint in the last three meetings," "this metric has dropped for three weeks straight."
Act. Based on the judgement, do something: create a Linear issue, send a Slack alert, generate a report.
Learn. The result is discussed again in the next meeting. That meeting is recorded in Tiro too, and referenced by the next Skill run. The loop closes.
Adopting Tiro is not adopting a recorder. It is adopting a workflow. Meeting -> context preserved -> agent executes -> result feedback -> next meeting. Once this loop runs, the organization's meetings finally become an asset.
The trap heavy-context products fall into
This design is not specific to Tiro. It applies to any product where context is naturally heavy, not just Conversation Intelligence. The previous article covered Scalekit's 32x token benchmark. Load everything into MCP and the context window bursts. Use only CLI and you lose multi-turn reasoning.
If you are considering AI adoption, ask this first.
Where, in our organization, is the context that the AI cannot reach? And when we connect that context to the AI, should the output live inside the agent's context, or as a file?
The first question points to the Context Source layer. The second points to tool selection. Once you can answer both, AI Transformation starts moving from 10%.
FAQ
Q. What is Conversation Intelligence?
Software that takes voice conversations like meetings and calls and turns them into a form an AI can use (LLM-Ready Data). It is the core area of the Context Source layer in the 5-layer architecture for AI transformation, and it fills the 90% of business context (spoken conversation) that is not digitized.
Q. What tools does Tiro's MCP have?
14 tools across six areas. Notes Discovery (list_notes, search_notes), Notes Retrieval (get_note, get_note_transcript), Templates, Share Links, Folders, Authentication. Progressive Disclosure spends tokens in stages. Full list at api-docs.tiro.ooo/mcp.
Q. Who writes the SKILL.md?
An AI lead or engineer at the organization. Since it is one markdown file with a procedure, coding knowledge is not strictly required. The point is to make explicit "in what order and where our team uses meeting data." Once written, the whole team can run the same procedure consistently.
Q. When do I split work between MCP and CLI?
The criterion is where the output goes. If it has to live in the agent's context for reasoning, MCP. If it has to be saved as a file, CLI. The summary of one note (hundreds of tokens) is natural in MCP. A bulk export of 10 transcripts (several MB) is natural in CLI. The detailed decision tree is in the previous article.
Q. We already use a meeting notes tool. What is different?
A simple meeting notes tool stops at recording. Tiro supports all four tools (API, MCP, CLI, Skill) because recorded context has to flow into the AI agent's workflow for AI Transformation to actually happen. Adopting a recorder and adopting a workflow are not the same thing.
Read more
The Missing Piece of AI Transformation: Conversation Intelligence
API, MCP, CLI, and Skill: What's Different, and When to Use Each
Get started
Tiro's API, MCP, CLI specs are at api-docs.tiro.ooo.
Appendix
For readers who want to see the code, the call examples that were pulled out of the body.
API call example
curl -H "Authorization: Bearer $TIRO_API_KEY" \
https://api.tiro.ooo/v1/external/notesWe publish the OpenAPI spec, so SDK auto-generation and Postman import work out of the box.
CLI bulk-processing example
The tiro command saves transcripts to disk, pipes search results as NDJSON, and composes well with jq.
For a quarterly review, finding all "Acme Corp" meetings from the last 30 days and downloading their transcripts looks like this:
# Search -> metadata as NDJSON
tiro notes search "Acme Corp" --since 30d --json > /tmp/acme.jsonl
# Save each transcript to disk
cat /tmp/acme.jsonl \
| jq -r '.guid' \
| xargs -I{} tiro notes transcript {} --format md --output ./out/{}.mdWith --output, stdout only carries a one-line metadata line.
{"saved":"./out/abc123.md","size":5234,"format":"md","guid":"abc123","paragraphCount":42}Skill file example (weekly metric review)
---
name: weekly-metric-review
description: Use to extract decisions and context from the weekly AARRR metric review meeting
---
## Procedure
1. Find this week's metric review meeting
`tiro notes search "AARRR" --since 7d --json > metrics.jsonl`
2. Save each meeting's transcript to disk
`cat metrics.jsonl | jq -r '.guid' | xargs -I{} tiro notes transcript {} --format md --output ./reviews/{}.md`
3. Read the .md files in ./reviews/ and organize by:
- *Reasons* behind numeric changes (why did this metric rise or fall)
- Decisions and owners
- Experiment list for next week
4. Update the Notion weekly review page with the results
Full API, MCP, CLI specs at api-docs.tiro.ooo.