Enables using local Ollama instances as a provider, allowing offline model access for meetings, collaborations, and chat completions.
Provides access to OpenAI's Chat Completions API for meetings, collaborations, and direct chat completions with configurable models.
Integrates with Replicate's predictions API, allowing models to be called via owner/name, version, or URL.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-roundtable Start a collaboration between the CEO and engineer personas on the Q3 roadmap"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server (stdio) that lets Claude Code — or any MCP client — convene meetings and collaborations between AI agent personas and LLMs from six providers, run local meetings on your own claude CLI, and call any provider directly.
Agents that can convene other agents. A persona is a markdown file; a meeting is a conversation between the caller and one persona on a chosen model; a collaboration is two or more personas taking turns on a topic. All of it runs over a plain MCP server, provider-agnostic: the same persona can sit on Anthropic today, a Together-hosted open model tomorrow, and a local Ollama model when you are offline. Debates and other multi-agent formats are natural extensions of the same primitives. State is in memory; there is no database and nothing to host.
Related MCP server: Agents Council
The caller talks to one agent persona. Provider and model are fixed at start_meeting (default provider anthropic).
Tool | Arguments |
|
|
|
|
|
|
| — |
Spawns the local claude CLI with --system-prompt-file, so the conversation runs on your Claude subscription. The persona file is passed verbatim. The CLI is stateless, so the whole transcript is re-sent each turn — keep local meetings short.
Tool | Arguments |
|
|
|
|
|
|
| — |
Two or more personas take turns on a topic. One provider/model is used for the whole session.
Tool | Arguments |
|
|
|
|
|
|
|
|
|
|
|
|
| — |
Tool | Arguments |
|
|
Tool | Returns |
| version, which keys are configured (6-character prefix only), Ollama reachability, default models, agents dir, active sessions |
Provider id | Backend | Default model | Notes |
| Anthropic Messages API |
| Aliases |
| OpenAI Chat Completions |
| Uses |
| Together AI |
| Any Together model id, e.g. |
| Replicate predictions API |
|
|
| Local Ollama at |
| Only usable when |
| Any |
| Base URL from |
Every provider call is bounded by ROUNDTABLE_LLM_TIMEOUT_MS (default 600000 = 10 min). Empty replies are errors, never blank messages. Unknown provider ids are rejected. Missing keys fail per call with a message naming the variable — the server itself always starts.
Variable | Required for | Default |
|
| — |
|
| — |
|
| — |
|
| — |
|
| — |
| optional | — |
|
|
|
|
|
|
| agent prompt lookup |
|
| default Anthropic model (id or alias) |
|
| default OpenAI model |
|
| default Together model |
|
| default Replicate model |
|
| default Ollama model |
|
| max output tokens (thinking tokens count) |
|
| per-request timeout |
|
.env is loaded from the package directory (next to package.json) with override: true, so values there win over anything the MCP host passes in its env block. .env is gitignored and is the single source of truth for secrets. See .env.example.
The agent argument is resolved, in order, as:
a literal path;
<ROUNDTABLE_AGENTS_DIR>/<agent>.md;
<ROUNDTABLE_AGENTS_DIR>/subagent-<agent>.md;
<ROUNDTABLE_AGENTS_DIR>/<agent>/AGENT.md.
A leading YAML frontmatter block (--- ... --- with at least one key: value line, as in Claude Code agent files) is stripped before the text becomes the system prompt; a body that merely opens with a markdown horizontal rule is left intact. Three generic personas ship in examples/ (cfo.md, product-lead.md, skeptic.md); copy them into your agents directory or point ROUNDTABLE_AGENTS_DIR at examples/ to try them.
Requires Node 20+.
git clone <repository-url> agent-roundtable
cd agent-roundtable
cp .env.example .env # fill in the keys you have
npm install
npm run build # dist/ is gitignored — a fresh clone must build
npm test # offline: unit tests with stubbed fetch + a stdio smoke test, zero API spendOpt-in live check (one tiny chat_completion per provider; costs well under a cent):
ROUNDTABLE_LIVE_TEST=1 npm run test:live
# providers default to anthropic,openai,together; replicate is billed per second, so it is opt-in:
ROUNDTABLE_LIVE_TEST=1 ROUNDTABLE_LIVE_PROVIDERS=replicate npm run test:liveUse absolute paths. Any of the three forms works.
(a) claude mcp add (add --scope user to make it global):
claude mcp add agent-roundtable \
-e ROUNDTABLE_AGENTS_DIR=/absolute/path/to/.claude/agents \
-- node /absolute/path/to/agent-mcp/dist/index.js(b) claude mcp add-json:
claude mcp add-json agent-roundtable '{"type":"stdio","command":"node","args":["/absolute/path/to/agent-mcp/dist/index.js"],"env":{"ROUNDTABLE_AGENTS_DIR":"/absolute/path/to/.claude/agents"}}'(c) A project .mcp.json:
{
"mcpServers": {
"agent-roundtable": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/agent-mcp/dist/index.js"],
"env": {
"ROUNDTABLE_AGENTS_DIR": "${ROUNDTABLE_AGENTS_DIR:-.claude/agents}"
}
}
}
}Tools then appear as mcp__agent-roundtable__<tool>. After a rebuild, reload with /mcp → Reconnect.
Any other MCP client: run node dist/index.js over stdio.
Once the server is registered you do not call the tools yourself: you ask for what you want in plain language and the model calls them. Claude Code lists them as mcp__agent-roundtable__<tool>, so naming the server ("via agent-roundtable", "using the roundtable") is enough to steer the model to it when several MCP servers are connected. Persona names are file names in ROUNDTABLE_AGENTS_DIR — the shipped examples/ give you cfo, product-lead and skeptic — and a file path works too.
Meetings — one persona, back and forth. Each prompt is one message in the chat:
Start a meeting via agent-roundtable with the cfo agent. Agenda: Q3 budget review. Use Anthropic Sonnet.
Tell the CFO that runway is 14 months at current burn and ask what they would cut first.
End the meeting and give me the summary.
Local meetings — the same conversation on your own claude CLI, no API spend:
Start a local meeting with the product-lead agent about the onboarding redesign. Context: the spec in docs/onboarding.md.
Ask them what they would cut to ship two weeks earlier, then end the meeting with a summary.
Collaborations — two or more personas take turns on a topic:
Run a collaboration on agent-roundtable between cfo and skeptic on "Should we raise now?", three rounds max, and run the first round immediately.
Continue the collaboration for two more rounds.
Nudge the collaboration: assume the round closes at a flat valuation. Then run one more round.
Give me the full transcript of that collaboration.
Direct completions — any provider, no persona:
Using the together provider on agent-roundtable, summarize the tradeoffs of a four-day work week in three bullets.
Send this to the replicate provider with model https://replicate.com/qwen/qwen3-235b-a22b-instruct-2507: "Explain CRDTs to a product manager."
Use the openai_compatible provider with base URL http://localhost:1234/v1 and model local-model to answer: what is the capital of Australia?
Diagnostics:
Run debug_env on agent-roundtable and tell me which providers are configured.
What to expect: every start_* call returns a session id together with the first reply, and the model keeps that id for the follow-ups, so "tell the CFO…" and "end the meeting" need nothing from you. Sessions live in the server's memory and end when it restarts. Claude Code asks before each tool call unless you allow the server in its permission settings: the rule mcp__agent-roundtable allows every tool on it, mcp__agent-roundtable__start_meeting allows one.
A meeting with one persona on Anthropic Sonnet:
start_meeting { "agent": "cfo", "agenda": "Q3 budget review", "provider": "anthropic", "model": "sonnet" }
say { "meeting_id": "<id>", "message": "Runway is 14 months at current burn. What would you cut first?" }
end_meeting { "meeting_id": "<id>", "request_summary": true }A collaboration between two personas, one round run immediately, then continued:
start_collaboration { "agents": ["cfo", "skeptic"], "topic": "Should we raise now?", "max_rounds": 3, "auto_run_rounds": 1 }
continue_collaboration { "collaboration_id": "<id>", "rounds": 2 }A direct completion on Replicate, addressing the model by its page URL:
chat_completion {
"provider": "replicate",
"model": "https://replicate.com/qwen/qwen3-235b-a22b-instruct-2507",
"messages": [{ "role": "user", "content": "Summarize the tradeoffs of a four-day work week in three bullets." }]
}A direct completion against a local OpenAI-compatible server (LM Studio on its default port):
chat_completion {
"provider": "openai_compatible",
"base_url": "http://localhost:1234/v1",
"model": "local-model",
"messages": [{ "role": "user", "content": "Hello." }]
}State is in memory. A rebuild + reconnect drops every meeting and collaboration.
Local meetings require the claude CLI on PATH.
The smoke test assumes .env sets neither OLLAMA_URL nor OPENAI_COMPATIBLE_BASE_URL (.env is loaded with override: true, so it beats the values the harness pins): it points Ollama at an unreachable port on purpose to exercise the unreachable path, and the "openai_compatible without a base URL" check would otherwise send a request to your configured server.
Provider errors (missing key, empty reply, timeout, unknown model) surface as tool errors with the reason; they never abort the server.
npm test must pass before a pull request. CI runs the build and tests on Node 20 and 22 and enforces that no absolute user paths are committed.
MIT — see LICENSE.
Call an LLM for text completion. Providers: anthropic (claude-opus-5 / claude-sonnet-5), openai (gpt-5.6-luna), together (Together AI), replicate (any Replicate text model), ollama (local, optional), openai_compatible (any /v1/chat/completions server).
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id. Defaults: claude-opus-5 (anthropic), gpt-5.6-luna (openai), zai-org/GLM-5.3 (together), qwen/qwen3-235b-a22b-instruct-2507 (replicate), qwen3:14b (ollama), default (openai_compatible). Anthropic also accepts the aliases "opus" (claude-opus-5) and "sonnet" (claude-sonnet-5). Replicate accepts owner/name, owner/name:version, or a https://replicate.com/owner/name URL. | |
| base_url | No | Only with provider "openai_compatible": base URL of an OpenAI-compatible /v1 endpoint (e.g. http://localhost:1234/v1). Overrides OPENAI_COMPATIBLE_BASE_URL for this session/call. OPENAI_COMPATIBLE_API_KEY, if set, is sent as the bearer token to whichever base URL is used. | |
| messages | Yes | Array of messages in the conversation. | |
| provider | No | LLM provider to use. Default: openai. Options: anthropic; openai; together (Together AI — any Together model id, e.g. zai-org/GLM-5.3 or Qwen/...); replicate (owner/name, owner/name:version, or https://replicate.com/owner/name); ollama (local, only when reachable); openai_compatible (any /v1/chat/completions server — set OPENAI_COMPATIBLE_BASE_URL or pass base_url). | |
| max_tokens | No | Maximum tokens in the response. Default: ROUNDTABLE_MAX_TOKENS (8192). Thinking/reasoning tokens count against this. | |
| temperature | No | Sampling temperature (0-2). Ignored for anthropic (current Claude models reject it); some OpenAI reasoning models reject it too. Replicate: sent only when the model's schema declares it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions external providers and local ollama, but does not disclose authentication needs, API key requirements, rate limits, cost implications, latency, or the shape of the returned completion. This is a significant gap for a tool that makes external network calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose. The provider list is somewhat redundant with the schema, but it remains compact and scannable without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich and covers all six parameters with descriptions and enums, so the description does not need to repeat those details. However, with no output schema and no annotations, the description omits practical context such as authentication setup and provider-specific environmental requirements, leaving minor gaps for an agent deciding how to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's provider/model list largely duplicates what the schema already documents for 'provider' and 'model'; it adds no meaningful parameter semantics beyond a compact summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair, 'Call an LLM for text completion,' and then enumerates the supported providers. This clearly distinguishes the tool from its siblings (collaboration/meeting/say tools), which operate in a different domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'Call an LLM for text completion,' and the provider list gives some selection context. However, it never states when to prefer this tool over alternatives like 'say' or when not to use it, and it does not name any sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue an active collaboration for additional rounds. Agents take turns responding.
| Name | Required | Description | Default |
|---|---|---|---|
| rounds | No | Number of additional rounds to run. Default: 1 | |
| collaboration_id | Yes | The collaboration ID from start_collaboration. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds some behavioral context by stating 'Agents take turns responding,' which reveals the interaction pattern. However, it does not disclose side effects (e.g., whether the collaboration state is mutated), whether the call blocks, or what the return value is. This is partial transparency, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero unnecessary words. It front-loads the core purpose in the first sentence and adds a behavior detail in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two parameters, no nested objects, and no output schema. The description covers the purpose and the agent turn-taking behavior, and the schema covers parameter meanings. It does not mention the return value, but for a continuation tool it may not be critical. Overall, it is adequately complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because both collaboration_id and rounds have descriptions in the input schema. The description adds no parameter-specific information beyond what the schema already provides, so it provides no extra semantic value. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Continue an active collaboration for additional rounds.' It specifies that it is for an existing collaboration, which distinguishes it from start_collaboration and end_collaboration. However, it does not explicitly differentiate from nudge_collaboration, which might also extend collaboration, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by saying 'active collaboration' and 'additional rounds,' which implies it should be used when a collaboration already exists. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to infer when to use this tool versus starting or ending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Debug tool to check server environment and API key status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'Check' implies a read-only diagnostic operation, which is useful, but it does not disclose whether special permissions are needed, what the response looks like, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. The purpose is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless diagnostic tool, the description is largely sufficient: it names exactly what is checked. It lacks usage context, but that gap is already reflected in the usage guidelines score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The description appropriately focuses on what the tool does rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('check') and specific resources ('server environment' and 'API key status'). It is distinct from the sibling collaboration and meeting tools, though 'debug tool' is slightly generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives, and no context is provided about troubleshooting workflows. The description simply labels it as a debug tool without explaining when an agent should invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a collaboration and optionally get a summary of the discussion.
| Name | Required | Description | Default |
|---|---|---|---|
| request_summary | No | If true, ask an agent to summarize key agreements, disagreements, and action items. | |
| collaboration_id | Yes | The collaboration ID to end. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the behavioral burden. It reveals that ending a collaboration can optionally produce a summary, but does not disclose whether ending is irreversible, what happens to the collaboration state, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action and the optional summary feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is too thin. It omits behavioral effects, usage conditions, and any guidance on what the response might contain, leaving an agent to infer important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description's mention of an optional summary aligns with request_summary but adds no syntax or semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('End') and resource ('a collaboration'), and mentions the optional summary capability. It is distinguishable from sibling tools like list_collaborations and get_collaboration_transcript, though it does not explicitly contrast with pause_collaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus pausing, continuing, or other collaboration lifecycle tools. The description implies the basic use case but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a LOCAL meeting and optionally get a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes | The local meeting ID to close. | |
| request_summary | No | If true, ask the agent for a summary before ending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does communicate the core effect—ending a local meeting—and the optional summary behavior. However, it does not mention reversibility, permissions, or what happens to meeting state afterward, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys both the primary action and the optional behavior, and every word adds distinguishing or functional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description plus fully documented schema is sufficient for an agent to call it correctly. The summary behavior is slightly underspecified, but not enough to prevent correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented with clear descriptions. The description's mention of 'optionally get a summary' echoes the request_summary parameter but adds no additional semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('End') on a clearly specified resource ('LOCAL meeting') and mentions the optional summary behavior. The capitalized 'LOCAL' distinguishes it from the sibling 'end_meeting' tool without requiring the reader to open schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The qualifier 'LOCAL' provides clear context that this tool is for local meetings, in contrast to collaboration or non-local meeting tools like 'end_meeting'. It does not explicitly name alternatives or state when not to use it, but the intended scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a meeting and optionally get a summary.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes | The meeting ID to close. | |
| request_summary | No | If true, ask the agent for a summary before ending. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It mentions the optional summary, but does not disclose whether ending is irreversible, whether a summary is returned in the response, what happens to the meeting transcript, or what side effects occur on related collaboration state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, and the core action is front-loaded. It could be more informative, but it is appropriately short for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should clarify what the agent can expect after calling the tool. The vague 'optionally get a summary' does not explain how the summary is delivered, and the relationship to local meetings/collaborations is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both meeting_id and request_summary clearly. The description only restates the summary option without adding syntax, defaults, or edge-case semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('End a meeting') and the optional summary feature, so an agent can infer the core purpose. However, it does not explicitly distinguish this tool from the sibling 'end_local_meeting' or 'end_collaboration', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like end_local_meeting or end_collaboration. It also does not mention any prerequisites or conditions under which ending a meeting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full transcript of a collaboration without ending it.
| Name | Required | Description | Default |
|---|---|---|---|
| collaboration_id | Yes | The collaboration ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the key side-effect boundary ('without ending it'), which is useful. However, it omits other behavioral context such as whether the collaboration must be active or what the transcript response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no filler. The main purpose is front-loaded and the important behavioral qualifier is appended without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation, the description plus schema is nearly sufficient. Minor missing details, such as prerequisites or the shape of the returned transcript, would improve completeness but are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already supplies 100% coverage for the single collaboration_id parameter with 'The collaboration ID.' The description adds no additional parameter semantics beyond that, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the full transcript of a collaboration. The qualifier 'without ending it' also distinguishes this tool from end_collaboration and signals a read operation rather than a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without ending it' gives clear context: use this when you need the transcript while keeping the collaboration active. It does not explicitly name alternatives, but the sibling list includes end_collaboration and list_collaborations, making the intended use reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active collaborations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It only restates the action and an 'active' filter; it does not explicitly disclose that the operation is read-only/safe, what the response contains, or how 'active' is defined relative to paused, ended, or future collaborations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant phrasing. It is appropriately sized for the tool's trivial parameter surface, though it is terse to the point of omitting useful behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, this is minimally viable: it clearly states what is being listed. However, with no annotations, no output schema, and no guidance about what an 'active collaboration' is or what the returned data looks like, an agent is left with notable gaps that richer context could easily fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so there is no parameter meaning for the description to add; the empty schema already fully covers this. The baseline of 4 applies because no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and specifies the resource ('all active collaborations'), so the core action is evident. However, it does not explicitly distinguish this from sibling collaboration tools such as get_collaboration_transcript or start_collaboration, leaving some differentiation to the agent's inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus sibling tools. The word 'active' implies some filtering, but the description does not explain when listing is appropriate, what preconditions exist, or which alternatives should be preferred in other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active LOCAL meetings (CLI-based).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It conveys that this is a read-only listing operation scoped to active local meetings and notes the CLI context. It does not describe output format, environment prerequisites, or failure modes, which is a moderate gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place by adding scope or context, making it appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description supplies the essential selection criteria: active, local, CLI-based. It does not explicitly contrast with list_meetings or describe output shape, but invocation requires no inputs and the core behavior is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter meaning for the description to add. The 0-parameter baseline of 4 applies; the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('active LOCAL meetings'), and the 'LOCAL'/'CLI-based' qualifiers distinguish it from the sibling tool list_meetings. It is specific, non-tautological, and immediately clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'LOCAL' and 'CLI-based' qualifiers make the intended context clear, implying this is for local/CLI meetings rather than general meetings. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active meetings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('list') with no side effects, which is helpful. However, it doesn't mention any potential auth requirements, return format, pagination, or what qualifies as 'active'. The description is minimal but not misleading, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence with no filler. It front-loads the essential action and resource. Every word earns its place. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description is mostly adequate. However, it doesn't clarify the scope of 'active meetings' or distinguish from 'list_local_meetings', which could lead to misuse. Given the sibling context, a small note about the distinction would greatly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). Per the baseline rule for 0 params, the description doesn't need to add meaning. Nothing is missing here, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('all active meetings'), making the tool's purpose unambiguous. However, it doesn't distinguish between remote and local meetings, which could be confusing given the sibling 'list_local_meetings'. Still, the purpose is clear enough for an agent to know it lists meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_local_meetings' or 'list_collaborations'. There is no mention of context, prerequisites, or why someone would choose this tool over a sibling. This is a significant gap given the number of similar listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inject a message from the orchestrator into the collaboration. Use to redirect discussion, ask clarifying questions, or provide additional context.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Your message to inject into the discussion. Will appear as from ORCHESTRATOR. | |
| collaboration_id | Yes | The collaboration ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does disclose that a message is injected and that it appears as from ORCHESTRATOR (via the schema), but it does not mention side effects, prerequisites like an active collaboration, or whether this is a non-blocking action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence defines the core action and the second adds concrete usage guidance. No unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter string-input tool with no output schema, the description provides enough to select and invoke it correctly. It lacks explicit exclusions or prerequisites, but the action and use cases are sufficiently specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds usage intent but no additional parameter-level semantics beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Inject a message from the orchestrator into the collaboration') with a clear resource. It also gives concrete use cases—'redirect discussion, ask clarifying questions, or provide additional context'—which helps distinguish it from sibling tools like say or end_collaboration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool by listing three relevant scenarios. It does not explicitly mention when not to use it or name alternative tools, but the use cases are clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a running collaboration. Can be resumed with continue_collaboration.
| Name | Required | Description | Default |
|---|---|---|---|
| collaboration_id | Yes | The collaboration ID to pause. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'pause' and that it can be resumed, but does not disclose side effects, state changes, permission requirements, or what happens if the collaboration is not running or already paused. For a state-mutating tool, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, two-sentence definition with zero wasted words. The core action is stated first, followed by a useful note about resumption. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter tool with no output schema. The description adequately covers the core action and the reversibility via continue_collaboration. It does not mention error conditions (e.g., if the collaboration is not running) or prerequisite permissions, but for a basic pause action, it is close to sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (collaboration_id) with 100% description coverage, so the agent already knows what it is. The description adds no additional semantic meaning beyond what the schema provides, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('pause') and resource ('running collaboration'), which directly matches the tool name and distinguishes it from siblings like end_collaboration and continue_collaboration. It unambiguously tells an agent what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: pause a running collaboration, and explicitly mentions that it can be resumed with continue_collaboration. This implies when to prefer pause over end (if resumption is desired), but it does not explicitly list alternatives or conditions to avoid using it. While not exhaustive, it offers clear guidance for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue a conversation in an active meeting.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Your message to the agent. | |
| meeting_id | Yes | The meeting ID from start_meeting. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without detailing side effects, prerequisites beyond an 'active meeting', error behavior (e.g., what happens if the meeting is not active), or whether the tool blocks or returns any data. This is a significant gap for a tool that sends messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and the context, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and the presence of many sibling tools (especially say_local), the description is incomplete. It does not explain how this tool differs from say_local, what an 'active meeting' implies, or what the expected behavior is when called. An agent would need additional context to use it correctly, so the description falls short of being contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (meeting_id and message) fully described. The description adds no additional meaning beyond the schema, but the schema already provides adequate context. Thus, the baseline score of 3 is appropriate; the description neither helps nor harms.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('continue a conversation') with a specific resource ('an active meeting'). It identifies the tool's core function without ambiguity. However, it does not explicitly differentiate from the sibling tool 'say_local', which likely serves a similar purpose for local meetings, so the distinction is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention say_local, start_meeting, or any conditions that would select this tool. The only implicit hint is 'active meeting', but there is no explicit exclusion or comparison, leaving the agent without clear decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Continue a conversation in an active LOCAL meeting (CLI-based).
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Your message to the agent. | |
| meeting_id | Yes | The local meeting ID from start_local_meeting. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does convey that the action continues an ongoing conversation and requires an active local meeting, suggesting a conversational side-effect rather than a purely read-only operation. It omits details like response behavior, error cases, and whether history is modified, but for a simple chat tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The key constraint ('active'), the environment ('LOCAL', 'CLI-based'), and the action are all front-loaded, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema coverage, this is sufficient for basic invocation: provide a meeting_id from start_local_meeting and a message. It is not fully complete because it does not describe output, alternative tool routing, or failure behavior, but the low complexity and clear schema keep it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters already have clear descriptions, so the baseline is 3. The description adds no additional parameter-level meaning, but none is needed because meeting_id and message are straightforwardly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('continue') and resource ('active LOCAL meeting'), and the 'LOCAL' qualifier plus 'CLI-based' parenthetical help separate it from sibling tools like say, start_local_meeting, and continue_collaboration. It does not explicitly name those alternatives or say what 'continue' returns, but the intended scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'active LOCAL meeting' implies the tool should be used only when a local CLI meeting is already running, and the schema ties meeting_id to start_local_meeting. However, the description gives no explicit when-not-to-use guidance or mention of alternatives, such as using say for non-local meetings or start_local_meeting if no meeting exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a collaboration session where multiple agents discuss a topic with each other. Returns a collaboration ID. Agents take turns responding, building on each other's ideas.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id. Defaults: claude-opus-5 (anthropic), gpt-5.6-luna (openai), zai-org/GLM-5.3 (together), qwen/qwen3-235b-a22b-instruct-2507 (replicate), qwen3:14b (ollama), default (openai_compatible). Anthropic also accepts the aliases "opus" (claude-opus-5) and "sonnet" (claude-sonnet-5). Replicate accepts owner/name, owner/name:version, or a https://replicate.com/owner/name URL. | |
| topic | Yes | The topic or question for agents to discuss. | |
| agents | Yes | Array of agent identifiers. Examples: ["cfo", "fpa"], ["product", "engineering", "design"] | |
| context | No | Optional background context or data to share with all agents. | |
| base_url | No | Only with provider "openai_compatible": base URL of an OpenAI-compatible /v1 endpoint (e.g. http://localhost:1234/v1). Overrides OPENAI_COMPATIBLE_BASE_URL for this session/call. OPENAI_COMPATIBLE_API_KEY, if set, is sent as the bearer token to whichever base URL is used. | |
| provider | No | LLM provider to use. Default: anthropic. Options: anthropic; openai; together (Together AI — any Together model id, e.g. zai-org/GLM-5.3 or Qwen/...); replicate (owner/name, owner/name:version, or https://replicate.com/owner/name); ollama (local, only when reachable); openai_compatible (any /v1/chat/completions server — set OPENAI_COMPATIBLE_BASE_URL or pass base_url). | |
| max_rounds | No | Maximum rounds of discussion (each round = each agent speaks once). Default: 5 | |
| auto_run_rounds | No | If set, automatically run this many rounds before returning. Otherwise returns after first agent speaks. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full behavioral burden. It usefully discloses that the tool returns a collaboration ID and that agents take turns building on each other's ideas, but it omits notable behaviors such as the default one-round return behavior, persistence of the session, or side effects beyond starting the collaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, information-dense sentences with no filler. The core action and return value are front-loaded, followed by a concise behavioral note about turn-taking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich 8-parameter schema with full coverage, the description adequately covers the core behavior and return value. It could go further by hinting that subsequent collaboration-management tools like continue_collaboration or nudge_collaboration operate on the returned ID, but this is not critical for a first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema documents all parameters. The tool description adds no parameter-level nuance beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (starting a collaboration session), the resource (a multi-agent discussion), and the outcome (a collaboration ID). However, it does not explicitly differentiate itself from sibling tools like start_meeting or chat_completion, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'where multiple agents discuss a topic with each other' implies the intended use case, but the description gives no explicit guidance about when to prefer this over alternatives, nor any exclusions. It does not mention that chat_completion or start_meeting are better fits for single-agent or meeting-style interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a LOCAL meeting with an agent using the installed Claude CLI. This uses your Claude Pro/Max subscription instead of API credits. Returns a meeting ID for follow-up messages. Ideal for cost-conscious lengthy conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Agent identifier or path to prompt file. Examples: "cfo", "fpa", "product" | |
| agenda | Yes | The topic, question, or task to discuss with the agent. | |
| context | No | Optional additional context, document content, or data to share. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful traits beyond the schema: it is local, uses a Pro/Max subscription, and returns a meeting ID for follow-up messages. It does not mention persistence or cleanup, but key behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary action, and every sentence contributes a distinct piece of information: what, cost model, return value, and ideal use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a start-operation with 3 parameters and no output schema, it covers the purpose, the return value, and the key cost/selection context. Slight gaps remain around prerequisites (CLI must be installed/authenticated) and the lifecycle of the meeting, but the core call is well specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds no param-specific semantics beyond confirming the agenda is the discussion topic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Start a LOCAL meeting with an agent using the installed Claude CLI.' It clearly distinguishes this from the sibling start_meeting by emphasizing 'LOCAL' and by explaining the billing model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete selection criterion: use this for cost-conscious, lengthy conversations because it uses Pro/Max instead of API credits. It does not explicitly name alternatives or exclusion cases, but the local-vs-API distinction provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a meeting with an agent. Returns a meeting ID for follow-up messages. Use this to begin a synchronous conversation with another agent (CFO, FP&A, Product, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes | Agent identifier or path to prompt file. Examples: "cfo", "fpa", "product" | |
| model | No | Model id. Defaults: claude-opus-5 (anthropic), gpt-5.6-luna (openai), zai-org/GLM-5.3 (together), qwen/qwen3-235b-a22b-instruct-2507 (replicate), qwen3:14b (ollama), default (openai_compatible). Anthropic also accepts the aliases "opus" (claude-opus-5) and "sonnet" (claude-sonnet-5). Replicate accepts owner/name, owner/name:version, or a https://replicate.com/owner/name URL. | |
| agenda | Yes | The topic, question, or task to discuss with the agent. | |
| context | No | Optional additional context, document content, or data to share. | |
| base_url | No | Only with provider "openai_compatible": base URL of an OpenAI-compatible /v1 endpoint (e.g. http://localhost:1234/v1). Overrides OPENAI_COMPATIBLE_BASE_URL for this session/call. OPENAI_COMPATIBLE_API_KEY, if set, is sent as the bearer token to whichever base URL is used. | |
| provider | No | LLM provider to use. Default: anthropic. Options: anthropic; openai; together (Together AI — any Together model id, e.g. zai-org/GLM-5.3 or Qwen/...); replicate (owner/name, owner/name:version, or https://replicate.com/owner/name); ollama (local, only when reachable); openai_compatible (any /v1/chat/completions server — set OPENAI_COMPATIBLE_BASE_URL or pass base_url). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does disclose the main behavioral contract: a meeting is started, the conversation is synchronous, and a meeting ID is returned for follow-up. It does not mention side effects, costs, authentication requirements, how long the meeting persists, or how it is terminated, but it is not misleading and provides the most essential behavioral facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states action and return value, and the second gives usage guidance with concrete agent examples. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description gives the critical information: it starts a meeting and returns a meeting ID for follow-up. The schema covers all optional provider/model parameters, and the required parameters (agent, agenda) are intuitive. It does not explain how to continue or end the meeting, but the sibling tools (say, end_meeting, list_meetings) make that discoverable, so nothing essential is missing for invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all 6 parameters with detailed explanations, examples, and defaults, so schema coverage is complete and the baseline is 3. The description adds only a slightly different set of agent examples ('CFO, FP&A, Product') that mostly repeats what the schema gives. It does not materially enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact action ('start a meeting'), the object of that action ('another agent'), and the key outcome ('returns a meeting ID for follow-up messages'). It also gives concrete audience examples (CFO, FP&A, Product), so an agent can tell what this tool operates on. It does not explicitly contrast itself with sibling tools like start_local_meeting or start_collaboration, so it misses the top mark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: 'Use this to begin a synchronous conversation with another agent.' This gives clear context and implies it is the entry point for ongoing meetings rather than one-off calls. However, it offers no exclusions or explicit alternatives, leaving an agent to infer when not to use it relative to collaboration and local-meeting siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0chat_completioncontinue_collaborationdebug_envend_collaborationend_local_meetingend_meetingget_collaboration_transcriptlist_collaborationslist_local_meetingslist_meetingsnudge_collaborationpause_collaborationsaysay_localstart_collaborationstart_local_meetingstart_meetingScored across 17 tools
The collaboration, meeting, and local-meeting families are separated by clear prefixes and distinct lifecycle verbs, so an agent can usually tell which session type a tool operates on. The four parallel meeting/local-meeting pairs are the only real source of confusion, but the 'local' naming and CLI-vs-API descriptions make the distinction recoverable.
Most tools follow an action_noun pattern such as start_collaboration, end_meeting, and list_local_meetings, with the collaboration family especially consistent. The exceptions are 'say', 'say_local', and 'chat_completion', which break the pattern but remain readable and contextually unambiguous.
Seventeen tools is slightly above the ideal 3-15 range, but the server genuinely covers three session modes, direct LLM completion, and environment debugging. The local-meeting variants inflate the count, yet each tool has a distinct operational role.
The collaboration lifecycle is well covered with start, pause, continue, nudge, end, list, and transcript tools, and meetings have start/say/end/list coverage. Minor gaps include no meeting transcript retrieval and no explicit agent-discovery tool, but summaries and orchestration context can work around these.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Real-time chat for AI agents. Claude Code, Cursor, Cline and Codex join channels over MCP.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
