Server Quality Checklist

Tool Scores

• bridge_stopA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by disclosing side effects: the session handle stops working, conversation history remains intact, the thread is not deleted, and double-calling is harmless. It aligns with idempotentHint and refines destructiveHint by clarifying that the session state is destroyed but not the underlying data, so there is no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact, well-ordered paragraph that front-loads the primary action, then explains effects, data safety, idempotency, and usage guidelines. Every sentence adds value with no repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple stop tool with one parameter and no output schema, it thoroughly covers behavior, side effects, data preservation, and when not to use it. The only minor gap is that it does not state the return value of bridge_stop itself, though it explains the asynchronous return of bridge_await, leaving the invocation context sufficiently clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter 'session' is fully documented in the input schema with a detailed description about routing and isolating conversations. The tool description references 'session handle' but adds no new semantic detail beyond the schema, meeting the baseline for 100% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with 'Ends remote chat mode for THIS conversation' – a specific verb and resource, clearly distinguishing it from siblings like bridge_start, bridge_send, and bridge_await. It also details concrete effects (daemon stops polling, in-flight waits return 'stopped'), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Use it when the user says they are done' and a clear negative case: 'not in response to a timeout from bridge_await'. It also points to bridge_start for resuming, offering a direct alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bridge_awaitA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds significant behavioral context beyond annotations: replies are consumed exactly once, a 'timeout' is normal and not an error, and 'stopped' indicates the user ended remote chat mode. These details help the agent anticipate non-obvious behaviors.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Four sentences, each earning its place: the first states the core function, the second gives usage guidance, the third explains consumption behavior, and the fourth clarifies status semantics. Front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description thoroughly explains return values and all possible statuses, including edge cases (timeout is normal, stopped means stop calling). Covers usage prerequisites and post-conditions, making it complete for an agent to operate correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema fully documents both parameters with detailed descriptions (session routing/concurrency, maxBlockMs default/cap). The description does not add additional parameter-level semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Blocks') and resource ('this conversation's chat thread'), and specifies the exact return statuses ('message', 'timeout', 'stopped'). It clearly distinguishes itself from the sibling bridge_send_and_await by stating when each should be used.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool ('when you already posted with bridge_send and only need the answer'), names the alternative ('prefer bridge_send_and_await'), and gives post-condition guidance ('stop calling bridge_* tools until a new bridge_start' after 'stopped').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bridge_send_and_awaitA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses blocking behavior, the fact that the message is posted before waiting, and the timeout side effect (user already saw the message). It also names the return envelope values. This goes beyond the annotations and adds critical behavioral context, with no contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is information-dense yet concise, with every sentence earning its place: action, default status, alternatives, return envelope, and a practical caveat. Well-front-loaded and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (send + wait) and lack of an output schema, the description covers return values, timeout side effects, relationship to sibling tools, and the end-of-turn pattern. It provides enough context for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all four parameters, so the baseline is 3. The description does not add parameter-level details beyond the schema, though it does reinforce the timeout behavior related to maxBlockMs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool posts a message and blocks for the reply in one round trip, using a specific verb and resource. It distinguishes itself from siblings by positioning as the default and explaining equivalence to bridge_send + bridge_await.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly labels this as 'the tool to reach for by default' and advises using bridge_send/bridge_await separately only when posting and waiting at different moments. This provides clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bridge_startA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly=false and openWorld=true, but the description adds crucial behavioral details: every call without session opens a new thread, returns onboarding instructions when no channel is configured, and fails closed on ambiguous conversation identification. These go beyond the annotations without contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is 5 sentences, each packed with essential information: main purpose, when to call, threading caution, failure mode, and safety behavior. No fluff; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (3 optional params, no output schema, sibling tools), the description fully covers intent, usage, side effects, failure modes, and integration with other bridge_* tools. It is complete and self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is well-documented. The description does not add new parameter meaning beyond the schema; it reiterates session reuse and adapter override, which are already in the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'Opens a dedicated thread... and returns the session handle that every other bridge_* tool requires.' This specific verb+resource distinguishes it from sibling tools like bridge_send or bridge_await, making its role clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says when to use: 'Call it when the user asks — in any language — to start remote chat, bridge, or Telegram mode.' It also provides exclusions: 'Call it once per conversation' and warns against re-starting without session, advising to re-arm instead.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bridge_statusA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by disclosing that it posts nothing, does not consume a pending reply, and answers from local daemon state without contacting the chat provider. This is valuable behavioral context not captured by readOnlyHint or idempotentHint.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense yet concise, with three sentences each adding distinct value: output format, safety/diagnostics, and local-state nature. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a diagnostic tool with no output schema, the description fully explains the return value (JSON with specific fields, null session), side effects (none), and context (local state, no provider contact). It is complete for the agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the schema already explains the session parameter thoroughly. The description adds no new parameter-level details beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reports the bridge's record for the conversation as JSON, listing specific fields (adapter, thread, session active status). It distinguishes from siblings by explicitly contrasting with bridge_await and noting it is diagnostics-only.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says when to use: 'Diagnostics only' and 'unlike bridge_await it is safe to call at any point, including while deciding whether a bridge_start is still needed.' This provides clear context and an alternative, making it easy to decide between tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bridge_sendA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable context: 'returns immediately without waiting for a reply,' 'Each call appends a new message and never edits or replaces an earlier one,' and 'a retry after a failure leaves a duplicate in the thread.' This exceeds what annotations convey, clarifying side effects and non-idempotency explicitly. No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, all informative. Front-loaded with the core action, then usage guidance, then side-effect warning. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Tool is simple (3 params, no output schema). Description covers the action, return behavior, use case, alternative, and side effects (duplicate on retry). Given the sibling tools and annotations, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% because every parameter has a description. The description adds nuance: for `text` it warns 'Keep credentials and secrets out of it: whoever can read the chat thread can read this,' which isn't in the schema. For `session` it explains routing and concurrency safety. It elevates beyond schema basics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states it 'Posts one message to this conversation's chat thread and returns immediately without waiting for a reply,' using a specific verb (posts) and resource (chat thread). It clearly distinguishes from sibling bridge_send_and_await, which waits for a reply.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to use: 'for a progress note or a closing remark that needs no answer.' It also gives an alternative: 'when you need the user to respond, use bridge_send_and_await instead.' This is direct when/when-not guidance naming an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.