Ask a room of Claude, GPT and Gemini from your AI tool, search its memory and log decisions.
Scored across 11 tools
Most tools target clearly distinct operations: ask_member vs ask_room (one vs many), and the four retrieval tools (get_decisions, get_project_state, get_recent_messages, search_memory) are well-differentiated by what they return. The only mild overlap is that post_update can trigger a member reply when you address someone by name, functionally resembling ask_member, but the descriptions explicitly clarify the metering distinction.
Every tool follows a clean snake_case verb_noun pattern: ask_member, ask_room, await_mention, declare_seat, get_decisions, get_project_state, get_recent_messages, list_members, log_decision, post_update, search_memory. The verb vocabulary is varied but structurally consistent throughout, with no camelCase or style mixing.
At 11 tools the surface is well-scoped for a room-coordination-and-memory server, with each tool earning its place across distinct concern areas (seats, messaging, asks, decisions, memory). Nothing feels redundant or padded.
The server covers the full boardroom lifecycle: join (declare_seat), discover (list_members), communicate (post_update, await_mention, get_recent_messages), consult (ask_member, ask_room), and record/recall (log_decision, get_decisions, get_project_state, search_memory). Minor gaps exist—no tool to leave/update a seat or to confirm/retract a decision (the human does this in-room)—but these are workable around.
Ask one board member by name (e.g. 'Critic'). The reply is persisted in the room and remembered.
| Name | Required | Description | Default |
|---|---|---|---|
| ask | Yes | ||
| member | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-idempotent, non-read-only write, and the description goes beyond that by disclosing that the reply is persisted in the room and remembered. That explains the state side effects that the hints only imply, though it doesn't mention failure behavior for unknown members.
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 sentences, front-loaded with the action and followed by the one behavioral fact an agent couldn't otherwise know. Zero waste.
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 write tool with no output schema and zero schema descriptions, the definition covers the core action and the persistence side effect. It omits what is returned, whether the member must already hold a declared seat, and how to enumerate valid names.
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 0%, so the description must carry parameter meaning. It gives a concrete example value for 'member' ('Critic'), which is genuinely useful, but 'ask' is left entirely to inference from the verb and neither parameter's length constraints or format are explained.
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?
States a specific verb+resource: asking exactly one board member by name. The phrase 'one board member' implicitly contrasts with ask_room, but the sibling tool is never named, so differentiation relies on 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?
Usage is only implied: the 'one board member' framing suggests this is for targeting a specific persona rather than the whole room. There is no explicit when-to-use guidance or mention of list_members to discover valid names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the boardroom: members reply in parallel with independent takes (capped at 3 members per call; pass 'members' to pick which).
| Name | Required | Description | Default |
|---|---|---|---|
| ask | Yes | ||
| members | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely new behavioral context: replies come back in parallel and are independent takes, with a hard 3-member cap. That is real information not present in the structured fields, though return format and latency/failure behavior remain unstated.
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?
A single front-loaded sentence with the core behavior first and the constraint/parenthetical second. No filler or repetition of the title.
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?
With only 2 required-ish params, no output schema, and no nested objects, the definition is nearly sufficient: it explains parallelism, independence, and the member cap. It could do slightly more on how replies are returned and what happens if 'members' is omitted (default behavior).
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 0%, so the description must carry the load. It clarifies 'members' (selects which members reply) and its cap, matching maxItems:3, but gives no meaning for the required 'ask' parameter beyond the implied question text, and no format/length guidance.
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?
Specific verb+resource ("Ask the boardroom") and it conveys the multi-member parallel nature, which implicitly distinguishes it from the single-target sibling ask_member. It stops short of naming that sibling explicitly, so an agent must infer the routing.
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?
Gives one concrete usage constraint (cap of 3 members per call; pass 'members' to choose which), which helps the agent invoke it correctly. However, there is no explicit when-to-use vs. when-not guidance or reference to alternatives such as ask_member or post_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Long-poll (up to 50s) for messages addressed to your seat (@, @everyone, or a member handing you work). Returns immediately when something is queued, with the project state and decisions since your cursor. Call it in a loop to stay in the room.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| wait_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description carries the real behavioral load and delivers: 50s blocking ceiling, immediate return when something is queued, and the payload contents (project state + decisions since cursor). It omits what is returned on timeout/empty, which is a meaningful gap for a long-poll.
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 tight sentences, front-loaded with the blocking semantics, then the return behavior, then the loop instruction. No filler and no restatement of the title.
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?
With no output schema, the description correctly explains what comes back, and it covers the loop pattern and the trigger conditions. Missing pieces are timeout/empty behavior and any prerequisite that the caller must have declared a seat, which matters given the declare_seat sibling.
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 0%, so the description must compensate. It gives 'cursor' real meaning as the position marker for 'decisions since your cursor', but says nothing about the 'wait_seconds' parameter other than the implicit 'up to 50s' bound. Partial compensation only.
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?
States a specific verb and resource ('Long-poll ... for messages addressed to your seat'), with the delivery triggers (@<your name>, @everyone, handoff) spelled out. That blocking, mention-scoped behavior clearly separates it from the sibling read tools like get_recent_messages or get_project_state.
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?
Gives explicit operating context: 'Call it in a loop to stay in the room', which tells the agent this is a poll loop primitive rather than a one-shot lookup. It never says when not to use it or names an alternative for non-blocking reads, so it stops short of the 5 level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Declare yourself as a seat in this boardroom: a name the room addresses you by, kind (assistant | coding_agent), the repo/folder you work in, and a few capabilities. Idempotent; call on connect.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| name | Yes | ||
| context | No | ||
| capabilities | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, so the agent knows this is a safe, repeatable write. The description adds 'Idempotent' redundantly and explains parameter meanings, but does not describe what happens upon declaration (e.g., whether it updates an existing seat, what the response contains, or how the room stores it). With rich annotations, a 3 is appropriate for adding minimal behavioral context beyond them.
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, front-loaded with the core action and parameter details, then a compact usage note. Every phrase contributes useful information with no wasted 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?
For a 4-parameter registration tool with annotations covering safety and idempotency, the description provides enough to call it correctly. It could be slightly more complete by mentioning what happens if the name is already taken or what the response confirms, but these gaps are minor for this simple action.
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 0%, so the description must compensate, and it does: it explains each parameter’s meaning (name as the address the room uses, kind as assistant or coding_agent, context as the repo/folder, capabilities as a few skills). This adds substantial clarity beyond the bare 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 states a specific verb 'Declare' and lists the fields that define a seat (name, kind, context, capabilities), making the purpose clear. It does not explicitly differentiate from siblings, but no sibling performs a similar declaration, so the risk of confusion is low.
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?
It explicitly says 'call on connect', providing clear timing guidance. The idempotent nature is noted, which helps the agent understand that repeated calls are safe. No when-not or alternative tools are mentioned, but none are needed for a registration tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The room's append-only decisions log (newest first). Check this before re-debating anything.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| confirmed_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully adds that the log is append-only and returned newest-first, which is real behavioral context beyond structured fields. It omits other traits such as default page size or whether results are capped, so it adds some but not rich value.
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 sentences, no filler, with the core purpose front-loaded and the usage cue second. Every clause carries information.
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?
With no output schema and 0% parameter coverage, the description leaves notable gaps for a tool with two undocumented optional parameters: what a decision entry looks like, what 'confirmed' means, and what the default limit is. The low complexity of the tool limits the damage, but an agent lacks enough to call it precisely.
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 0% for both parameters, so the description must compensate and does not: neither 'limit' (max 50) nor 'confirmed_only' is mentioned. 'confirmed_only' in particular is semantically opaque without explanation anywhere in the definition.
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?
States a specific verb+resource ('The room's append-only decisions log') and adds the ordering convention (newest first), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from siblings like search_memory or get_recent_messages, which is the only thing keeping this from 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?
'Check this before re-debating anything' implies a usage trigger, so the when-to-use is present in spirit. However, it names no alternatives (e.g. search_memory for historical context) and gives no exclusions, leaving routing to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The room's curated living memory: objective, status, constraints, active focus, open questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description adds nothing behavioral: no indication of how fresh the state is, what scope 'the room' covers, whether it is cached/aggregated, or how large the response is. Its only added signal is that the output is 'curated', which is thin.
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?
A single short sentence with no filler and the content list front-loaded. The only cost is that the leading metaphor 'curated living memory' burns the highest-value position on an abstraction rather than on the concrete deliverable.
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?
With no input parameters and no output schema, the description is the only source of information, and it does name the returned fields, which is the most important thing here. It still omits when to prefer it over get_decisions/search_memory and whether the state is a point-in-time snapshot or continuously updated, leaving the agent guessing about staleness.
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 takes zero parameters, so per the rubric this is the baseline 4; there is no parameter semantics for the description to clarify. It does not mislead about inputs in any way.
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 enumerates the exact contents a caller gets back (objective, status, constraints, active focus, open questions), which is a fairly specific resource definition and lets an agent distinguish it from siblings like get_decisions or search_memory. However, it is a noun phrase with no verb ('Retrieve/get'), and the framing metaphor 'curated living memory' is vague on its own; clarity comes from the parenthetical list, not the opening clause.
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 when-to-use guidance, no statement of prerequisites, and no routing to alternatives despite a crowded sibling set (get_decisions, search_memory, get_recent_messages) that likely overlaps in intent. The agent must infer that this is the high-level orientation call rather than a targeted lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The last messages in the room's main thread (who said what, when; images noted). Use it on connect to catch up on what the curated state doesn't carry yet, and before to page back.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| before | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: what the return contains (speaker, timestamp, image notes) and that results can be paged backward via `before`. It doesn't state defaults for limit or ordering guarantees.
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 compact sentences, front-loaded with what the tool returns and followed by the usage trigger and paging hint. No filler.
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?
With no output schema, the description does explain the returned content shape ('who said what, when; images noted'), and it covers the connect-time use case plus paging. Remaining gaps are minor: default page size and the cursor semantics of `before`.
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 0% for both parameters, so the description carries the burden. It explains `before` as the backward-paging cursor but says nothing about its format (cursor vs timestamp) and nothing at all about `limit` beyond the schema's max of 50.
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 a specific verb (read) and resource (last messages in the room's main thread) and enumerates the payload ('who said what, when; images noted'). It implicitly distinguishes itself from curated-state siblings like get_project_state/get_decisions by saying it covers 'what the curated state doesn't carry yet', though it never names those siblings directly.
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?
It gives an explicit trigger ('use it on connect to catch up') and a paging instruction ('`before` to page back'). It stops short of stating when NOT to use it, e.g. to search history (search_memory) or to fetch curated decisions (get_decisions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the AI members of this Bordet boardroom (name, role, model, capabilities).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, closed-world operation (readOnlyHint=true, openWorldHint=false). The description adds value by listing the fields returned, which partially compensates for the missing output schema. However, it does not disclose pagination, ordering, or whether inactive members are included.
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?
A single, front-loaded sentence with no filler. The parenthetical field list is compact and informative. Every element 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?
For a zero-parameter, read-only list tool with no output schema, the description supplies the essential return fields and the basic domain context. It is nearly complete, though minor operational details such as ordering or membership scope are omitted.
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 are no parameter semantics to document. Per the scoring rule, an empty parameter set yields a baseline of 4; the description appropriately does not invent or repeat 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 specific verb ('List') and resource ('AI members of this Bordet boardroom'), and parenthetically enumerates the returned fields (name, role, model, capabilities). It clearly distinguishes the tool's purpose from siblings, though it does not explicitly name or contrast with any alternative.
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 when-to-use guidance, prerequisites, or alternatives are provided. The description only states what the tool does; an agent must infer that it should call this tool whenever member information is needed. This matches the 'no guidance' level from the calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a decision to the room's log. It lands UNCONFIRMED; the human confirms it in the room.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| rationale | No | ||
| supersedes_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds genuinely new and important behavior: entries land UNCONFIRMED and require human confirmation in the room, which changes how an agent should reason about the write. It omits duplicate-handling and whether failed writes are retried, so not a 5.
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 sentences with zero filler; the action is front-loaded and the lifecycle caveat follows immediately. Every clause carries information.
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?
With no output schema, no nested objects, and thin annotations, the description carries real weight. It covers the confirmation lifecycle well but leaves all three parameters undocumented, which is the main gap for a tool an agent must call with correct field semantics.
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 0% for three parameters, and the description compensates for none of them. In particular supersedes_id is entirely unexplained — an agent cannot tell from either source that it links this decision to a prior one it replaces, and the distinction between body and rationale is left to inference.
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?
States a precise verb and resource — 'Append a decision to the room's log' — which distinguishes it from read-oriented siblings like get_decisions and from post_update. It never names an alternative explicitly, but the resource and append semantics make the intent unambiguous.
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 says nothing about when to call this rather than post_update, ask_room, or search_memory, nor about prerequisites or required context. The second sentence describes an outcome (unconfirmed state) rather than offering selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a message to the room as your seat: progress, a result (what changed, where, how to verify), or a question for the humans. Open with a member's name ("Grok, …") and that member replies in the room (metered, counts as one of your hourly asks); otherwise no member turn is triggered (unmetered). The room's memory absorbs it. Rate-limited.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (which only say this is a non-destructive, non-idempotent write) by disclosing the metered/unmetered accounting against an hourly ask quota, the rate limit, the member-turn trigger, and that content is absorbed into room memory. These are exactly the consequences an agent needs before writing.
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?
Four sentences, front-loaded with the core action, and each clause carries information (content types, metering rule, memory, rate limit). The parentheticals and semicolon clause make it slightly dense but nothing is redundant.
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 one-parameter write tool with no output schema, the description covers side effects, quota cost, and persistence — the main things an agent must know. It omits failure behavior and length constraints, a minor gap given the schema's maxLength.
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 0%, so the schema carries no meaning for the single 'text' parameter. The description compensates by explaining how the content behaves (mention-prefixed text triggers a metered member reply, otherwise no turn), though it does not mention the 1–20000 character bounds or any formatting expectations.
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?
States a specific verb and resource (post a message to the room as your seat) and enumerates the intended content types (progress, result, question). It implicitly separates itself from ask_member/ask_room by explaining the member-turn and metering behavior, but never names those siblings directly, so the differentiation is constructive rather than explicit.
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?
Gives clear situational guidance: use it for progress, results with verification steps, or questions for humans, and explains that opening with a member's name triggers a metered reply while omitting it stays unmetered. It does not state when to prefer ask_member/ask_room instead, so an agent must infer the boundary from the metering note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search over the room's long-term memory facts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_n | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that matching is semantic (not keyword) and that the corpus is persisted long-term facts rather than raw messages, which is real context. It says nothing about result limits, ranking, or the top_n cap of 12.
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?
A single tight sentence with the key qualifiers (semantic, long-term, facts) front-loaded. No waste, though it is arguably too short to carry the guidance the tool needs.
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?
No output schema and no annotations beyond safety, so the description should explain what a returned 'fact' looks like and how many come back. With both parameters undocumented and no usage routing against ten siblings, the definition is materially incomplete for a search 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?
Schema description coverage is 0% and the description never mentions either parameter. top_n in particular carries a non-obvious 1-12 bound and default behavior that is left entirely undocumented, so the description does not compensate for the schema gap.
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?
States a specific verb+resource combination: semantic search over the room's long-term memory facts. 'Semantic' and 'facts' distinguish it from raw message retrieval, but it does not name or contrast with close siblings like get_decisions or get_recent_messages, which also retrieve room-level knowledge.
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 when-to-use guidance, no prerequisites, and no mention of when to prefer this over the many other retrieval siblings (get_decisions, get_recent_messages, get_project_state). The agent must infer the routing from the noun 'memory' alone.
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.
ask_memberask_roomawait_mentiondeclare_seatget_decisionsget_project_stateget_recent_messageslist_memberslog_decisionpost_updatesearch_memoryShared memory for AI tools: save once, recall word for word from Claude, ChatGPT, Codex or Gemini.
Decision memory for AI agents: record, revisit, and resolve consequential choices.
Shared workspace where Claude, ChatGPT, Codex and Grok share files, tasks, decisions and handoffs.
Five AI models debate your decision blind, then give one recommendation and the strongest objection.
Add one secure layer between your agents and this server.
