Conductor Relay MCP

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

The description goes well beyond annotations. It explains exactly what happens on fresh enrollment, on repeated identical claims, and on same-owner/different-name requests. It also clarifies that the name is not identity proof or delivery authority, and that listing is opt-in. The idempotentHint annotation is backed by concrete behavioral details, and 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.

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

The description is long but densely packed with essential information. It front-loads the core action (creation of mailbox) and then explains edge cases and semantics. While a bit verbose, every sentence adds substance; no filler. It could be trimmed slightly but remains efficient.

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 tool with 5 parameters, an output schema, and complex behavior (idempotency, route preservation, error codes), the description covers all necessary aspects: purpose, behavior, parameter semantics, and side effects like 'Free — no offer, price, CPTM hold or Direct Session participates.' It is complete enough for an agent to call it correctly without further clarification.

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 baseline is 3. The description adds meaningful interpretation: it specifies that 'name' is case-insensitively unique, that 'public_listing' defaults to false and omitting it leaves settings unchanged, and that the enrollment name maps to discovery mailbox_name, not the display name. This adds value 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 states a specific action: 'Fresh tool enrollment creates a relay-hosted mailbox' and details the uniqueness and idempotency of the name. It clearly distinguishes this from sibling tools like a2a_find_agents and a2a_send_message by focusing on the enrollment/mailbox creation aspect.

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 clear context for when to use the tool (enrollment, establishing a mailbox) and explains idempotent behavior and error conditions like a2a_already_enrolled. It does not explicitly name alternative tools or say 'use this when...', but the purpose is unambiguous and distinct from siblings.

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

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

Annotations already declare the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful behavioral guarantees beyond that: 'A missing route returns no result' sets failure expectations, and 'Discovery does not change the connection identity or bypass recipient admission and blocks' confirms side-effect-free discovery. The clarification that name is a self-declared label while mailBox identity is immutable provides semantics not visible in annotations.

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 short sentences, each earning its place: purpose, exclusivity constraint, no-result behavior, and identity semantics. The purpose and constraint are front-loaded ahead of the parameter clarification, and there is zero 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?

For a 2-parameter, 0-required, read-only discovery tool with an output schema present, the description covers invocation modes, filter constraints, failure behavior, and side-effect guarantees. Nothing an agent needs to call it correctly is missing.

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?

With 100% schema description coverage, the baseline is 3 because the schema already documents both parameters. The description adds value by distinguishing the name parameter from the immutable mailBox_name claim and by reinforcing the exclusivity rule ('Supply at most one filter'). The minor wrinkle is that mailBox_name is referenced in prose but is not actually a schema property, which creates slight ambiguity.

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 pairing: 'Recover your own mailbox and tenant with no arguments, or resolve one recipient by exact mailbox name or agent_id.' It names two distinct operating modes (self-recovery vs. targeted resolution), which separates it from the bulk-listing sibling a2a_list_public_agents. An agent can tell this tool from its siblings without inspecting any other schema.

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 concrete invocation conditions: no arguments for the caller's own route, exactly one filter for recipient resolution, and 'Supply at most one filter' as an explicit constraint. It falls short of a 5 because it never names the bulk-discovery alternative (a2a_list_public_agents) or states when to prefer it, so exclusions are implied rather than explicit.

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

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

The description adds valuable behavioral context beyond annotations: it clarifies that this is a pull/claim operation requiring authentication, and that results are strictly scoped to the caller's credential. It explains why readOnlyHint=false (claiming has side effects) and idempotentHint=false (claim may not be repeatable), without contradicting any annotations. The lack of detail about what happens after claiming is a minor gap.

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 three sentences, each serving a distinct purpose: core action, unique advantage, and a security constraint. It is front-loaded and free of filler, making it highly efficient and 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 simple one-parameter tool with a known output schema, the description conveys the essential purpose, the specific use case (no public endpoint), the authentication requirement, and the credential scoping. It provides enough context for an agent to correctly invoke it without further clarification.

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 schema already provides comprehensive documentation for the single 'limit' parameter (range, default, purpose). The description does not mention or enhance this parameter, so it adds no value beyond the schema. With 100% schema coverage, the baseline of 3 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 tool's function: 'Collect A2A work addressed to you.' It distinguishes from sibling tools by explaining the unique pull model for agents without a public endpoint, and specifically notes that only tasks addressed to the caller's credential are returned, making it 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?

Explicitly specifies when to use this tool: 'This is how an agent with no public endpoint participates.' It also describes the usage pattern (authenticate and pull) and warns that the responder is derived from the key and cannot be supplied, effectively saying this tool is for receiving your own tasks only. This provides clear guidance on when not to use alternative endpoints.

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

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

Annotations already carry readOnly, idempotent, and non-destructive hints. The description adds useful behavioral context beyond that: the read does not claim inbox work, access is restricted by mailbox policy and blocks, and pending tasks have no response yet. No contradiction with annotations.

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 short sentences, each carrying distinct information: operation, scope, access constraint, parameter source, and a behavioral note about pending tasks. 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 simple one-parameter read tool with a full output schema and safety annotations, the description covers everything an agent needs: what it reads, authorization limits, side-effect-free behavior, and the no-response-yet edge case. No important gap remains.

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%, and the description essentially repeats the schema's task_id provenance ('returned by send or inbox collection') rather than adding new parameter meaning. This is the expected baseline when the schema fully documents the only parameter.

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 and resource ('Read an existing task and its completed reply') and immediately differentiates from work-claiming siblings by noting it does not claim inbox work. This makes the tool's purpose unambiguous even without inspecting the schema.

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 provides clear context: when to use the tool, prerequisites (task ID from send or inbox collection), and access constraints (only requester/responder, subject to policy/blocks). It does not explicitly name sibling tools or state exclusions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond these: 'Neither surface guarantees delivery', provenance is 'exactly as recorded' and 'self_declared never means verified', and the tool operates on the 'Communication plane only'. These clarify the reliability and scope of results, which annotations do not cover. No contradiction exists.

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 yet dense, with the core purpose front-loaded in the first clause. Every sentence contributes: differentiation, credential requirement, delivery caveat, provenance clarification, and plane scope. No filler or 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?

Given the low complexity (browse tool with optional params), the output schema exists to explain return shape, and annotations cover safety and idempotence, the description fully informs an agent on when to use, what to expect, and what not to assume (delivery, verification). No relevant missing 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?

The input schema provides 100% coverage, describing limit, cursor, and capability with clear descriptions including defaults and an example. The description adds no additional parameter details, but the schema already handles this dimension. Baseline of 3 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 states a specific verb ('browse') and resource ('opt-in surface for agents that explicitly published an A2A profile'), and distinguishes it from a2a_find_agents by contrasting 'browse' with 'resolves one already-known mailbox name exactly'. An agent can immediately tell which tool fits its task.

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 explicitly names the sibling a2a_find_agents and explains the difference in purpose, implying when to use this tool (browse public agents) versus the alternative (resolve a known mailbox). It also notes 'No credential required', which is a practical usage signal. This is clear and directly actionable.

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

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

Beyond the annotations (which only indicate a mutating operation), the description adds critical behavioral context: authorization is based on ownership, not task ID possession, and replying completes the task with a non-repeatable guarantee. These details significantly enhance the agent's understanding of side effects and security semantics.

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 three concise sentences, each delivering essential information: purpose, authorization constraint, and idempotency. There is no redundancy or filler, and the most critical 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 simple tool with only two required parameters and an existing output schema, the description covers all essential aspects: purpose, authorization, completion behavior, and repeat-reply prohibition. It is fully sufficient for an agent to determine 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?

The schema already provides complete descriptions for all three parameters (task_id, text, message_id) with 100% coverage. The description reiterates that task_id comes from a2a_get_messages and is an identifier, but this adds no new meaning beyond the schema. Baseline of 3 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 tool's purpose: to answer and complete a task retrieved via a2a_get_messages. It distinguishes from sibling tools like a2a_send_message by specifying that it is for replying to tasks specifically pulled with that retrieval tool.

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 explicit when-to-use conditions (tasks pulled with a2a_get_messages) and when-not constraints (task not addressed to you results in not found; completed tasks cannot be answered twice). However, it does not explicitly name alternative tools, such as a2a_send_message, so it lacks direct alternative guidance.

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

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

Beyond the annotations, the description adds real behavioral context: self-hosted targets may return a reply inline, relay-hosted targets require saving a task ID and polling a2a_get_task, the credential determines the sender, and the operation is free. These are non-obvious behaviors that materially affect how an agent should handle the response and next actions.

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 every sentence earns its place. It leads with the core action, then covers target-type differences, sibling misuses, sender identification, and cost semantics without redundancy. It is dense but highly informative.

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 output schema exists and the input schema is fully documented, the description covers the remaining critical operational context: what to do after sending depending on hosting type, which tools are not appropriate for replies, and when to switch to paid direct sessions. Nothing essential is missing for an agent to invoke this tool 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?

The input schema already covers 100% of the parameters with clear descriptions, so the baseline is 3. The tool description does not add new parameter-level meaning; its extra guidance is about follow-up behavior rather than the meaning of text, tenant, context_id, or message_id. This is acceptable because the schema is already strong.

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 and resource: 'Send an A2A message to another agent.' It explicitly distinguishes itself from a2a_get_messages, a2a_get_task, and open_direct_session, making it clear this is the tool for sending free A2A communication rather than retrieving replies or doing paid work.

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 explicit when-to-use and when-not-to-use guidance: for relay-hosted targets, save the task ID and use a2a_get_task; a2a_get_messages is only for claiming incoming work and will not retrieve replies; paid work should use open_direct_session. This gives an agent clear routing logic among closely related tools.

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

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

Annotations already declare the tool as a mutation (readOnlyHint=false), idempotent, and non-destructive. The description adds the need for an Authorization: Bearer header, which is useful, but it does not disclose side effects or what the approval entails.

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 extremely short, which is concise, but the first sentence is largely redundant with the tool name. The second sentence adds value by noting the auth header requirement.

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 description lacks essential context: what a direct session is, when approval is appropriate, and what effects it has on the session. The output schema exists but does not compensate for the missing behavioral 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 descriptions cover both parameters (session_id and idempotency_key) with clear meanings, so the baseline is 3. The description does not add further clarification, but it is not needed given schema coverage.

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 restates the tool name ('approve_direct_session operation') without explaining what approving a direct session does. It does not distinguish this from sibling tools like reject_direct_session or open_direct_session.

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 on when to use this tool versus alternatives. The only additional information is the Bearer header requirement, which is an authentication detail, not a usage context.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds useful context about using the calling agent's bearer token and the safety of retrying with the same idempotency_key, which goes beyond the annotations and clarifies expected behavior.

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 resource, and contains no extraneous information. Every word contributes to clarity.

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 tool's low complexity, the presence of an output schema, and clear annotations, the description covers the essential context. It does not explicitly describe failure cases or what happens if the job is already claimed, but such details are likely in the output schema and are not critical for basic 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%, meaning both job_id and idempotency_key already have clear descriptions. The description reinforces the role of idempotency_key in retries but does not add significant new parameter information beyond what the schema provides, so the baseline score of 3 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 (claim), the resource (open Conductor Relay job), and the identifier (by id). It also specifies authentication via bearer token, distinguishing it from sibling tools like list_jobs or submit_job_result.

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 when to use the tool: when you need to claim an open job by id. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent can infer the appropriate use case.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is known. The description adds the useful Authorization: Bearer header requirement, but discloses nothing beyond that and does not contradict annotations.

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 short, but the first sentence is tautological filler that restates the operation name. The second sentence about auth is useful, making the description compact but not fully purposeful.

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 and annotations cover required parameters, idempotency, and destructiveness, and an output schema exists. However, the description fails to state what closing a direct session does or when it is appropriate, leaving the agent to infer from the name and sibling tools.

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%, and both parameters are documented with examples such as idempotency_key being 'shared across REST, MCP, and A2A'. The description adds no extra parameter semantics, so the baseline 3 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 'Execute the canonical Direct Session close_direct_session operation' merely restates the tool's name/title without explaining what closing a direct session does or how it differs from siblings like open_direct_session. The auth requirement does not clarify purpose.

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 on when to use this tool versus alternatives, such as get_direct_session or open_direct_session. The description only mentions the Authorization header requirement, not usage context or exclusions.

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

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

The description adds the requirement for an Authorization: Bearer header, which is useful context beyond the annotations. Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the added auth detail fills a gap.

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 short, but the first sentence is filler that merely restates the tool name. The second sentence about the auth header is useful. It is concise but not optimally structured because the first sentence doesn't earn 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?

The description lacks the core purpose and context needed to understand when or why to invoke this tool. Even with an output schema and good parameter schema, the missing functional description leaves the tool incomplete for an agent to use 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 coverage is 100% and both parameters have descriptive JSON schema entries, so the description adds no additional parameter meaning. The baseline of 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 only says 'Execute the canonical Direct Session create_direct_provider_verification_challenge operation,' which tautologically restates the tool name without explaining what the operation does functionally. No information about creating a challenge or its role in the direct session lifecycle is provided.

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 on when to use this tool versus alternatives like create_direct_signing_key_challenge or open_direct_session. The only usage hint is the auth header requirement, which is not enough to guide tool selection.

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

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

Annotations already declare the operation as not read-only, idempotent, and non-destructive. The description adds the requirement for an Authorization: Bearer header, which is useful behavioral context beyond what annotations provide. However, it does not disclose what the challenge creation entails or what side effects it has.

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 short and 2 sentences long, but the first sentence is a tautology that does not earn its place. The second sentence provides actionable info (auth requirement), but the overall structure wastes a sentence on redundant wording.

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?

Despite having an output schema and annotations, the description is too minimal for an agent to understand what this tool does in the direct session context. It fails to explain what a 'direct signing key challenge' is, what prerequisites exist, or how it relates to sibling tools like register_direct_signing_key. The auth requirement is the only concrete operational detail.

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 fully documents the single parameter (idempotency_key) with a clear description, achieving 100% schema coverage. The description adds no additional information about parameters, so the baseline of 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 only restates the operation name ('Execute the canonical Direct Session create_direct_signing_key_challenge operation') without explaining what creating a direct signing key challenge actually does. The verb 'Execute' is generic and the resource is simply the tool name itself, providing no meaningful purpose clarification.

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 about when to use this tool versus alternatives such as register_direct_signing_key or approve_direct_session. The only contextual hint is the required Authorization header, which is a prerequisite rather than usage guidance.

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

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

Beyond the annotations, the description discloses critical behavioral traits: the quote is 'immutable', the URL is 'short-lived', and 'Opening or returning from Checkout does not prove payment; only the verified Stripe webhook can fulfill the quote and credit CPTM.' This is significant context that alerts the agent to the asynchronous fulfillment model.

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, each serving a distinct purpose: main action, prerequisites, and a critical caveat. No redundant words. The description is front-loaded with the primary function and structured for easy parsing.

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 description covers the essential context for a payment-creating tool: the object created, the output (URL), required headers, idempotency key, and the payment verification caveat. Combined with the existing output schema and annotations, the description is comprehensive for an agent to understand and invoke the tool 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%, so the parameters are already fully documented. The description adds no extra parameter-level semantics beyond mentioning idempotency_key, which is 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.

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

The description clearly states the tool's function: 'Create an immutable USD-to-CPTM quote... then return a short-lived Stripe Checkout URL'. It identifies the specific resource (quote/checkout) and distinguishes it from sibling tools like get_funding_status or request_sandbox_funds by emphasizing the Stripe Checkout flow.

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 clear context on when to use this tool: for funding a parent agent or gift target via Stripe Checkout. It mentions prerequisites (Authorization header and idempotency_key) but does not explicitly contrast with alternatives like request_sandbox_funds, which would warrant a 5.

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

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

Annotations already indicate a non-read-only operation (readOnlyHint=false), and the description adds the requirement for a Bearer token. However, it does not disclose what the operation does behaviorally, such as side effects, idempotency implications, or what a created delegation entails. The added value over annotations is minimal.

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 wasted words, making it concise and front-loaded. However, its extreme brevity comes at the cost of missing critical purpose and usage information, so it is not ideal but structurally efficient.

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 tool with 12 parameters and 9 required fields, the description is grossly incomplete. It does not explain what a worker delegation is, when to use it, or how it relates to sibling tools like revoke_worker_delegation. Even with an output schema present, the description leaves the agent without sufficient context to invoke the tool 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%, so the baseline is 3. The description itself adds no parameter semantics, but the schema fully lists all parameters. However, most schema descriptions are formulaic ('Canonical ... argument') and add little real meaning, yet the tool description does not compensate for this.

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 restates the tool name ('create_worker_delegation operation') without explaining what a worker delegation is or what creating one accomplishes. It does not distinguish this tool from siblings beyond its name, leaving the purpose vague and tautological.

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 on when to use this tool versus alternatives. The description only mentions the Authorization header requirement, which is a necessary condition but not a usage guideline. No scenarios, exclusions, or comparative context are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a critical behavioral detail—Bearer token required—and clarifies the resource type (managed DB-CPTM) and the three components returned. This goes beyond the annotations without contradicting 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?

Two sentences with the purpose front-loaded and a separate sentence for authentication. There is no redundancy or filler; every word adds 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 zero-parameter getter with an output schema and strong annotations, the description covers all necessary semantics: the scope (calling agent), the resource type, the components of the balance, and the auth requirement. It is complete for an agent to use 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?

The input schema has zero parameters, so schema coverage is 100% and the baseline is 4. The description correctly adds no parameter information since none exist, making it fully appropriate for the context.

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 verb 'Get' and the specific resource: the calling agent's managed DB-CPTM balance, active holds, and available balance. This distinguishes it from sibling tools like get_cptm_price and get_direct_usage, which target different data.

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 clear context that this tool is for retrieving the calling agent's own balance, not other agents, and also specifies the bearer token requirement. However, it does not explicitly mention when to avoid this tool or name alternatives, so it just misses a 5.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these: 'No auth required' clarifies access, and the explanation that planned capabilities are never callable prevents false expectations. This is beyond what the annotations alone convey, so the description earns credit for 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 just two sentences, with no filler. The first sentence uses a colon to efficiently enumerate the directory contents, the second clarifies the two essential behavioral constraints (no auth and planned capabilities). Every phrase adds value, making it concise yet complete.

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 tool's simplicity (no parameters) and the presence of an output schema, the description covers all necessary operational knowledge: what the directory includes, how to use it, auth requirements, and the special handling of planned capabilities. The mention of /openapi.json for deeper REST action details fills any potential gap, so the description is fully complete for enabling correct invocation.

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 confirms this with an empty properties object and additionalProperties=false. The description mentions no parameter details because none exist, and with 100% schema coverage from the empty schema, there is nothing to add. The baseline of 4 for zero-parameter tools 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 tool's function with a specific verb ('Get') and resource ('complete Conductor Relay capability directory'), then enumerates exactly what is included: 'every live, gated, and planned capability' with 'status, audiences, use cases, human/machine documentation links, and public REST actions.' This level of detail distinguishes it from sibling tools like get_status or get_balance.

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 explicit guidance on when to use the tool: 'Use this to discover the full platform,' and notes an important boundary condition—'Planned capabilities are returned with status "planned" and are never callable.' It also notes that REST-only actions are listed here and detailed in /openapi.json, which directs the user to complementary resources. It does not explicitly name alternative tools to use instead, but the intent is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds useful behavior context: it clarifies that the data is a managed internal reference series, that aggregates are fixed 24h, and that no authentication is needed. This goes beyond the annotations without contradicting 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, packs in the purpose, key details, and limitations, and is front-loaded with the action. 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 simple read-only price series tool with a single optional parameter and an output schema, the description covers the essential context: what it returns, its limitations, and auth requirements. It is complete enough 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.

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

The schema already provides 100% coverage for the single optional parameter, including the range and the fact that 24h aggregates are unaffected by the lookback window. The tool description doesn't add new parameter-specific meaning; it merely reinforces what the schema states. Baseline 3 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 identifies a read operation ('Read') targeting a specific resource (DB-CPTM reference rate series) and lists the data elements (high/low/change/volume). It also distinguishes the tool from potential siblings by noting it's a 'closed-economy reference figure only,' which sets it apart from transactional or external settlement tools.

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 clear context for when to use this tool: to access internal CPTM reference rates. It also states exclusions ('no external redemption, withdrawal, or chain settlement') and notes that no auth is required. However, it does not explicitly name alternative tools, 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.

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

Beyond the annotations (readOnlyHint=true, idempotentHint=true, etc.), the description adds important behavioral context: the execution_enabled field is authoritative and discovery does not authorize session execution. It also discloses the required auth header. These are critical nuances not conveyed by annotations alone.

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 only two sentences and front-loads the purpose immediately. Each sentence earns its place: the first details what is read, the second adds a critical caveat and the auth requirement. 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 zero-parameter, read-only tool with an output schema, the description is complete: it lists the specific data points returned, clarifies the authoritative field, and states the auth requirement. There is no ambiguity about what the tool does or how to invoke it.

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 are no parameter semantics to explain. The schema coverage is 100% vacuously. The description focuses on return data rather than parameters, which is appropriate. A score of 4 reflects the baseline for no-parameter tools.

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 ('Read') and clearly identifies the resource: the registered parent agent's effective Direct Session limits (concurrency, spend, duration, request, byte) plus platform availability. It distinguishes itself from sibling tools like get_direct_usage and get_capabilities by focusing on limits rather than usage or capabilities.

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: it reads limits and requires an Authorization: Bearer header. It also implies that this is for discovery, not authorization, but it does not explicitly name alternatives or say 'use this instead of X.' Still, the purpose and prerequisites are clear enough for an agent to decide when to call it.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds the requirement for an Authorization: Bearer header, which is useful context, but it does not describe any other behavioral traits such as error conditions or response handling. This adds some value beyond annotations.

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 only two sentences and appropriately short, but the first sentence—'Execute the canonical Direct Session get_direct_session operation'—merely repeats the tool name and does not earn its place. The second sentence provides the auth requirement, but the overall structure is not well-focused.

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?

Despite having a simple schema, output schema, and rich annotations, the description fails to explain what a direct session is or what the operation returns or is used for. With multiple sibling tools, the lack of context makes it insufficient for an agent to understand when and why to invoke 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?

Schema coverage for the single parameter session_id is 100%, and the description does not add any further meaning. The schema says 'Canonical session id argument for the get_direct_session Direct Session operation,' which is tautological but still names the parameter. Baseline score of 3 is appropriate since the description does not compensate with additional detail.

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 'Execute the canonical Direct Session get_direct_session operation,' which restates the tool name and does not explain what the operation does (e.g., retrieves session details). It fails to specify a verb+resource beyond the name itself, making it tautological.

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 on when to use this tool versus sibling tools like list_direct_sessions, open_direct_session, or close_direct_session. The only additional note is the Authorization header requirement, which is a prerequisite, not a usage guideline.

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

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

Beyond the annotations (readOnlyHint, destructiveHint), the description adds specific behavioral context: it explicitly states the tool does not open, charge, or settle a session, and it discloses the Authorization: Bearer header requirement. This adds meaningful transparency beyond the structured hints.

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 sentences, front-loaded with the core purpose, followed by essential clarifications. No wasted words; the description is compact and well-organized.

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 tool's simplicity (no parameters) and the presence of an output schema, the description is complete. It covers the purpose, time window, side-effect guarantees, and authentication requirement, leaving no significant gaps.

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?

With zero parameters, the schema fully covers parameter semantics. The description doesn't need to explain parameters, and it adds the important context that the usage data is for the current 24-hour window, which serves as a semantic constraint.

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 (Read), the resource (aggregate Direct Session usage), and the scope (current 24-hour window). It distinguishes itself from sibling get_ tools by naming the specific data type being retrieved.

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 clear context for when to use the tool: it is a read-only, gated-discovery view for checking usage without opening or charging a session. It does not explicitly name alternatives, but the 'does not open, charge, or settle a session' clause gives a strong negative guideline.

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

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

The description adds significant context beyond the annotations: it requires an Authorization header, explicitly lists what the read does NOT return, and clarifies that only verified webhook fulfillment credits a quote. This gives the agent a clear picture of the tool's behavior and limitations.

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 concise yet informative: three sentences, each adding value. It front-loads the core purpose, then covers authentication and response limitations without unnecessary fluff.

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 that an output schema exists, the description need not explain return structure. However, it compensates by clarifying important behavioral nuances (auth requirement, excluded fields, credit condition), making the tool's usage safe and unambiguous.

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 fully documents the sole parameter (quote_id) with a clear description and reference to create_funding_checkout. The tool description does not add additional semantic value for the parameter beyond what the schema already provides, so a baseline score 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 tool's function: reading the lifecycle status of an MCP funding quote. It specifies the resource (funding quote) and the operation (read), and distinguishes it from siblings like get_balance and get_status by focusing on quote status.

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 the primary use case (checking funding quote lifecycle status) and states a prerequisite (Authorization header). It does not explicitly mention alternatives or when not to use, but the context is clear enough to infer proper usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful context beyond annotations: it reinforces aggregate-only nature, guarantees absence of sensitive data, and clarifies auth requirements ('No auth required'). This is extra value without contradicting annotations.

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 concise sentences, front-loaded with the core purpose and followed by essential constraints (aggregate-only, no sensitive data, no auth). Every clause earns its place with no 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?

With an output schema present and no parameters, the description covers purpose, behavioral expectations, privacy, and authentication in a compact form. It is complete for a simple read-only stats tool, and the 60-minute freshness detail adds useful operational 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?

There are zero parameters, so the schema fully covers any input requirements. The description implicitly confirms no inputs are needed, and the absence of additional parameter details is acceptable because there are none to document.

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 ('Get') and resource ('Conductor Relay marketplace and 60-minute live-network traffic stats'), clearly distinguishing it from sibling tools like get_status or get_balance. It adds scope qualifiers ('aggregate-only', 'no agent identifiers or wallet data') that further differentiate it.

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 clear context on when to use: when aggregate marketplace and live traffic stats are needed, with no auth. It does not explicitly exclude alternatives or mention when not to use, but the specificity of statistics collection makes the use case evident.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond these: 'No auth required' and the specific data points returned (counts and median seconds), which are not in the annotations.

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 short sentences with no filler, front-loads the action, and includes only essential details (purpose and auth requirement). 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?

For a parameterless health-check tool, the description covers purpose, auth, and return metrics. An output schema exists (per signal), annotations cover safety, and there are no nested objects or complex inputs. The description is fully sufficient for an agent.

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 the description doesn't need to explain parameter meaning. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool returns, which is more valuable.

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 the verb 'Get' and explicitly names the resource 'Conductor Relay exchange health' along with the specific metrics (24h job created/completed counts and median completion seconds). This clearly differentiates it from sibling tools like get_network_stats, which covers network-level statistics.

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 clear context by labeling the tool as 'public' and stating 'No auth required', which indicates when it should be used. However, it doesn't explicitly mention alternatives or when not to use it, stopping short of a 5.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description adds strong behavioral guarantees: provider endpoint references, credentials, allowlists, prompts, responses, private memory, shells, filesystems, and administrative APIs are never returned. It also discloses the gated execution state and auth requirement, giving a fuller picture than annotations alone.

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 concise and well-structured: the first sentence states the core purpose, the second lists exclusions compactly, and the third adds two critical constraints (gated execution and auth). Every sentence earns its place 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 zero-parameter, discovery-only tool with an output schema, the description fully covers purpose, safety boundaries, auth requirements, and execution state. The output schema handles return value details, so no additional specification is needed. It is complete for an AI agent to select and invoke 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?

The tool takes zero parameters, and schema description coverage is 100% (trivially). With no parameters to document, the baseline of 4 applies, and the description correctly refrains from adding unnecessary 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 clearly states the tool lists active governed inference offers visible to the requesting agent, using the specific verb 'list' and resource 'direct offers'. It distinguishes from execution by noting 'Discovery only' and enumerating what is never returned, making it distinct from sibling tools.

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 clear context: it is for discovery only, requires an Authorization: Bearer header, and notes that Direct Session execution is currently gated. It implies when to use (for discovering offers) and what not to expect (sensitive data), though it does not explicitly name alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the authorization requirement, which is useful context. However, it does not disclose any other behavioral aspects such as pagination, default sorting, or what 'direct session requests' specifically refers to.

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 states the operation and the auth requirement, then stops. There is no 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?

Given the tool has no parameters and a provided output schema, the description does not need to explain return values. However, it is extremely sparse: it does not explain what a 'direct session request' is, what the opposite operation might be, or any domain context. The description is minimally viable but relies heavily on the tool name and annotations for meaning.

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 the baseline is 4. There is no parameter information to add, and the description correctly avoids inventing any. The schema is trivially covered at 100%.

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 'Execute the canonical Direct Session list_direct_session_requests operation' essentially restates the tool name as a command, providing no new information about what the operation does or returns. It is a tautology rather than a clear functional definition, though it does at least reference the resource domain (Direct Session).

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 only guidance offered is the authentication requirement ('Requires an Authorization: Bearer header'), which is a prerequisite but not usage context. There is no indication of when to use this tool versus alternatives like get_direct_session or list_direct_offers, and no mention of typical scenarios or exclusions.

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

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

Annotations already mark the operation as read-only and idempotent. The description adds the auth requirement ('Bearer token required') and clarifies the agent-specific scope ('the calling agent can claim'), providing context beyond the annotations. 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.

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

Two concise, front-loaded sentences with no filler. Every word contributes meaning: action, resource, scope, and authentication requirement.

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 list tool with one optional parameter, an output schema, and safety annotations, the description covers the essential context: what is listed, who can claim, and authentication. Missing details like pagination defaults are minor and likely covered by the output schema.

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 schema already documents the lone limit parameter with min/max and a description (100% coverage). The description does not need to add more, so the 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 uses a specific verb 'List' and resource 'open Conductor Relay jobs the calling agent can claim', clearly distinguishing it from sibling tools like claim_job and submit_job_result. It states both the action and the scope precisely.

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 when to use the tool: to see jobs the calling agent can claim. It provides clear context, though it does not explicitly name alternatives or exclusionary scenarios, which would elevate it to a 5.

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

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

Annotations already indicate this is a mutation (readOnlyHint=false) and idempotent (idempotentHint=true). The description adds the useful auth requirement ('Requires an Authorization: Bearer header'), which is extra context. However, it does not disclose side effects or what constituting an 'open' operation entails, so it only partially compensates.

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 short but not effective. The sentence 'Execute the canonical Direct Session open_direct_session operation' is wasteful repetition of the tool name; only the auth header clause is useful. It fails the principle that every sentence should earn 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?

With 6 parameters, 5 of them required, and an output schema present, this complex mutation tool needs a proper explanation of what the operation does and what the return value represents. The description provides none of that. An agent has virtually no context to decide when or how to invoke 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?

Although schema_description_coverage is 100%, every parameter description is a circular placeholder ('Canonical X argument for the open_direct_session Direct Session operation'). The tool description itself provides no additional meaning for parameters like offer_id, max_spend_cptm, or duration_seconds, leaving the agent without real semantic 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?

The description is a tautology: 'Execute the canonical Direct Session open_direct_session operation' merely restates the tool name without explaining what opening a direct session actually does. It fails to distinguish this from siblings like get_direct_session or close_direct_session.

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 about when to use this tool versus alternatives such as approve_direct_session or claim_job. The description provides no context, prerequisites, or exclusions.

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

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

The description adds only an auth requirement. Annotations already indicate non-read-only and idempotent behavior. The description does not disclose side effects (e.g., whether this supersedes existing offers, how visibility/access is affected) or any return semantics.

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 short, but the first clause is redundant filler ('Execute the canonical ... operation'). The auth note is the only concrete piece of information. It is not well-structured to convey purpose quickly.

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 mutation with 10 required parameters, this description is severely under-specified. It lacks any explanation of what the offer is used for, how parameters interrelate, or what the response contains. The tool cannot be safely invoked based on this description alone.

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?

Although schema coverage is 100%, every parameter description is simply 'Canonical X argument for the publish_direct_offer Direct Session operation' — a tautology. The description itself does not define key concepts like access_mode valid values or request_price_cptm format. Twelve parameters remain conceptually opaque.

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 restates the tool name ('publish_direct_offer operation') without explaining what actually happens when an offer is published. The verb 'execute' is generic and provides no domain content. It distinguishes nothing from sibling tools like verify_direct_offer or set_direct_offer_status.

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 about when to use this tool instead of alternatives. The only added note is the Authorization header requirement, but there is no mention of prerequisites, lifecycle position, or relationships to other direct-session operations.

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

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

Annotations mark readOnlyHint=false (a write) and destructiveHint=false, but the description adds substantial context beyond that: the key is 'one-time', 'returned once — store it securely', and the naming behavior ('an agent registered without one is stored named after its own id...'). This reveals side effects and security implications not captured in annotations, so it earns 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?

The description is two sentences with no filler. It front-loads the core purpose (create agent + issue key) and then delivers the critical caveat about naming. Every phrase contributes meaning, and the structure is easy to scan in one pass.

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 tool has an output schema (stated in context), so return values need not be described. With one parameter, clear annotations, and a description covering purpose, security, and naming pitfalls, nothing essential is missing for an agent to call 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%, so the 'name' parameter is fully documented. The description goes further by explaining the consequences of omission ('stored named after its own id... nothing can rename you later') and provides a naming convention ('acme-code-review'), adding value beyond the schema's basic type and length constraints. Baseline 3 is elevated to 4 because of this extra semantic 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?

The description clearly states 'Create a new trial Conductor Relay agent' and 'issue a one-time bearer API key', giving a specific verb and resource. It distinguishes the tool from siblings by highlighting 'trial' and 'Relay agent', so an agent can tell it from a2a_enroll or others without inspecting 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 description mentions 'No auth required' as a condition but provides no explicit when-to-use guidance or contrast with sibling tools. It doesn't say 'use this for X, not Y' or outline any exclusion criteria, leaving the agent to infer when this tool is appropriate relative to a2a_enroll or register_direct_signing_key.

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

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

Annotations already cover read-only, destructive, and idempotent hints. The description adds one meaningful behavioral requirement: 'Requires an Authorization: Bearer header.' However, it does not disclose side effects or what is destroyed, and the 'canonical' wording adds no transparency. With the annotations present, adding the auth requirement warrants a 3.

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 short, but the phrase 'Execute the canonical Direct Session register_direct_signing_key operation' is redundant filler that merely restates the name. The auth header clause is useful. Overall, it is concise but not well-structured; it leads with a tautology instead of valuable 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?

For a destructive mutation with four required parameters, the description lacks essential operational context: no mention of the intended use case, how it relates to the challenge flow, or any side effects. Having an output schema does not compensate for missing purpose and prerequisites. The description is far from 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%, so the baseline is 3. The schema descriptions are largely repetitive ('Canonical ... argument for the operation'), but the idempotency_key description provides some extra context. The tool description itself adds no parameter semantics beyond what the schema already contains.

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 restates the tool name as an 'operation' without explaining what registering a direct signing key actually does. It provides no verb or resource beyond the name itself, making it a tautology. The only extra detail is the Authorization header, which does not clarify purpose.

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 on when to use this tool, prerequisites, or how it compares to sibling tools such as create_direct_signing_key_challenge or approve_direct_session. The description offers zero situational context.

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

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

The description adds only the authentication requirement ('Requires an Authorization: Bearer header'), which is not covered by annotations. However, it fails to disclose any behavioral consequences of rejecting a session, such as whether it is reversible or what occurs to the session state. Annotations already indicate destructive and idempotent, but the description does not enrich this with specific side effects or context.

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 short but under-specified. It repeats the tool name and adds one auth note, providing no substantive content. This is not concise expression of important information; it is a placeholder-level description.

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?

Despite having an output schema and complete parameter schema, the description omits essential context for a destructive operation. It does not explain what a Direct Session is, when rejection is appropriate, or any consequences. For a tool in a family of session-management operations, this is insufficient.

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 no new parameter semantics beyond the auth header, but the baseline of 3 applies because the schema carries the burden successfully.

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 'Execute the canonical Direct Session reject_direct_session operation' merely restates the tool name without explaining what 'reject_direct_session' does. It does not specify a verb+resource or distinguish this from sibling operations like approve_direct_session or close_direct_session.

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 alternatives. The description lacks any context on when rejection is appropriate or what distinguishes it from approve/close operations.

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

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

Goes beyond annotations by disclosing that it credits only the managed Conductor Relay DB balance, is not connected to any chain or external wallet, has no external withdrawal, enforces one grant per agent per 24h, and requires a bearer token. These details are not derivable from the annotation flags.

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?

Every sentence earns its place: purpose, scope, side effects, exclusions, and policy reference. It is front-loaded with the core action and remains dense without unnecessary 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 description covers all necessary context: what, when, limitations, side effects, and authentication. It points to the policy for additional details, and the output schema handles return values, so nothing is left unresolved.

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?

With zero parameters and a schema showing an empty object, the description doesn't need to explain inputs. The baseline of 4 applies because the description adds context about what the request entails without needing 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 clearly states the tool's purpose: 'request the capped trial sandbox faucet for test CPTM' with 'SANDBOX/ONBOARDING ONLY' scope. It explicitly distinguishes itself from earnings and treasury tools, making it unambiguous among sibling tools.

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?

Provides explicit when-to-use ('SANDBOX/ONBOARDING ONLY') and when-not-to-use ('NOT agent earnings', 'NOT Agent Treasury / Catalog earned commission'), along with a clear alternative clarification for earned commission. This effectively prevents misuse.

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

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

The description discloses critical behavioral details beyond annotations: route_card structure (approved_copy, required disclosure_text, forbidden_claims, version), commission crediting condition (verified conversion + Treasury finalization), DB-CPTM-only restriction with no cash-out/withdrawal/bridge/redemption, and mandatory compliance obligations. It also mentions bearer token requirement, significantly exceeding the basic annotations.

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 structured with the purpose first, followed by return details, commission and restriction context, compliance mandates, and auth. Every sentence adds value and no fluff is present. It is moderately long but proportional to the tool's complexity.

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 an output schema present, the description still adds comprehensive context: the type of result (route_card, commission summary, tracked link), commission conditions, internal-network restriction, and mandatory compliance rules. This makes the tool's behavior clear even without seeing the output schema. The description is complete for the tool's complexity.

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 provides full descriptions for both parameters (intent and surface) with 100% coverage. The description does not add parameter-specific semantics beyond what the schema already states, so it relies on the schema to convey parameter meaning.

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 the specific verb 'resolve' with a clearly defined resource ('buyer-intent signal') and outcome ('eligible approved offers'), distinguishing it from sibling tools like list_direct_offers. It clearly states what the tool does without ambiguity.

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 the tool is for resolving buyer-intent signals to offers, but it does not explicitly explain when to choose this over alternatives like list_direct_offers or claim_job. There are no usage exclusions or comparisons with sibling tools, leaving usage boundaries inferred rather than explicit.

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

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

Annotations already declare destructiveHint: true and idempotentHint: true, so the safety profile is partially known. The description adds the Authorization header requirement, which is useful unfrastructure context. However, it does not disclose what happens to the revoked key, whether revocation is immediate, or any side effects—despite being a destructive operation. It adds some value but remains 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?

The description is very short (one sentence), but the first half is redundant with the tool name ('Execute the canonical Direct Session revoke_direct_signing_key operation'). It is not efficient conciseness—it wastes words on tautology. The second half about the auth header is the only substantive content, making the overall structure slightly padded.

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 destructive operation with an output schema and annotations, the description is under-specified. It fails to communicate the consequences of revocation, the scope of what is affected, or any caveats. The output schema exists, so return values are covered, but the operational context (what makes this different from other revoke tools, what to expect) is missing. This is a notable gap for a mutating 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 provides descriptions for both required parameters (signing_key_id and idempotency_key), achieving 100% coverage. The description does not add any parameter-specific meaning, but with full schema coverage, that is acceptable. Baseline 3 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 simply restates the tool name: 'Execute the canonical Direct Session revoke_direct_signing_key operation.' It does not explain what revoking a signing key entails or how it differs from sibling tools like revoke_worker_delegation. The verb and resource are evident from the name, but the description adds no semantic clarity beyond that.

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 only guidance provided is 'Requires an Authorization: Bearer header.' This is a technical requirement, not usage context. It does not indicate when to use this tool versus alternatives (e.g., register_direct_signing_key, create_direct_signing_key_challenge) or any scenarios to avoid. No exclusions or prerequisites beyond auth are mentioned.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive mutation. The description adds the auth header requirement, which is useful context, but it does not explain consequences like what happens to the revoked delegation or whether the action is reversible.

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, making it concise, but the wording is vague and formulaic ('Execute the canonical ... operation'), which wastes the opportunity to convey real information. It is short but not well-structured for agent understanding.

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?

Despite having annotations and an output schema, the description is inadequate for a destructive mutation tool. It fails to explain the purpose, side effects, or when to use it, leaving the agent to rely entirely on the tool name and schema. This is a dangerous gap for a high-stakes operation.

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% for both parameters (delegation_id and idempotency_key), so the schema fully documents their meaning. The description adds no additional parameter semantics, so the baseline score of 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 'Execute the canonical Direct Session revoke_worker_delegation operation' merely restates the tool name without explaining what revoking a delegation actually does. It does not specify the effect or scope, and while the name suggests a clear verb+resource, the description adds no insight beyond the title.

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 on when to use this tool versus alternatives such as create_worker_delegation or approve_direct_session. The only additional information is the Authorization: Bearer header requirement, which is a prerequisite but not a usage guideline.

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

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

Annotations already indicate that this is a non-read-only, idempotent, non-destructive operation. The description adds the requirement for an Authorization: Bearer header, which is a behavioral detail not captured in annotations. However, it does not describe side effects, return behavior, or any other operational nuances, so the added transparency is minimal but present.

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 very short, with only two sentences, but the first sentence is largely redundant with the tool name and title. The second sentence about the auth header is useful. There is minimal verbosity, but the description is under-specified, making it less effective than a concise, information-rich version could be.

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 mutation tool in a complex domain with many sibling operations, the description is insufficient. It lacks critical context about what a direct message is, whether the session must be active, how it relates to session lifecycle, and potential error conditions. The output schema and annotations provide some structure, but the description is too thin to confidently invoke the tool 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?

The schema has 100% description coverage for all three parameters, though the descriptions are formulaic ('Canonical ... argument'). The tool description itself does not add any parameter-level meaning beyond what the schema provides. Baseline for high schema coverage is 3, and the description fails to elevate it further.

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 'Execute the canonical Direct Session send_direct_message operation,' which essentially restates the tool name and title. It does not explain what sending a direct message does or how it differs from sibling operations like open_direct_session or close_direct_session. This is a tautological description that fails to convey the tool's actual function.

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 any prerequisites, such as having an active direct session, or when not to use it. The only note about requiring an Authorization: Bearer header is a general authentication requirement, not specific usage context.

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

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

Annotations already flag destructiveHint=true, readOnlyHint=false, idempotentHint=true, and the description adds the Authorization: Bearer header requirement, which is useful context not in the annotations. However, it does not describe the state-changing effect or implications beyond what annotations imply, so it adds minimal 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?

The description is short (two sentences), but the first sentence is redundant tautology that adds no value. The second sentence about the auth header is the only useful content. It is concise but not every sentence 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 mutation tool with three required parameters, an output schema, and many siblings, this description is under-specified. It lacks context about when to use the tool, what state changes occur, or how it relates to other direct offer operations. The output schema exists, but the description still fails to provide a complete picture.

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 itself adds no parameter information, and the schema descriptions are generic ('Canonical status argument...'), but the enum and idempotency_key are self-explanatory. The description does nothing to compensate or enrich parameter understanding.

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 'Execute the canonical Direct Session set_direct_offer_status operation' essentially restates the tool name and adds no specific verb+resource detail. It fails to explain that the tool changes the status of a direct offer to active/paused/retired, nor does it distinguish from siblings like publish_direct_offer or verify_direct_offer.

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 on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only added context is the auth header requirement, which is not a usage scenario. An agent cannot determine the appropriate context from the description.

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

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

Annotations already indicate this is a read-write, non-destructive, idempotent operation. The description adds the requirement for an Authorization: Bearer header, which is a concrete behavioral precondition not captured in annotations. However, it does not disclose what state changes occur, what happens to the session, or any side effects, so the added transparency is minimal.

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 unnecessary filler, but it is under-specified. The core statement is tautological and does not convey useful information, so it would have been better to provide substantive details. Brevity without content is not effective 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 tool with six required parameters, an output schema, and nested objects, the description is far too sparse. It lacks any explanation of the domain concept (direct receipt), the expected workflow (e.g., after opening a session), or the meaning of the parameters. The agent is left without enough context to correctly select and invoke this operation.

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 description provides no information about parameters. Although the input schema has a description for every parameter, each description merely repeats the parameter name (e.g., 'Canonical signature argument for the submit_direct_receipt Direct Session operation'), offering no real semantic value. Parameters like canonical_claims remain opaque objects, and the agent gains no insight into expected structure or purpose beyond the names.

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 says 'Execute the canonical Direct Session submit_direct_receipt operation,' which essentially restates the tool name without explaining what submitting a direct receipt accomplishes or what a direct receipt is. It does not distinguish this from sibling operations such as open_direct_session or send_direct_message. The verb 'execute' is generic and the resource is the operation itself, making this a tautology.

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 about when to use this tool versus alternatives like close_direct_session or submit_job_result. The only additional note is the Authorization header requirement, which is a prerequisite rather than usage context. The description does not explain the workflow position or conditions under which this operation should be invoked.

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

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

The description discloses the authentication requirement ('Bearer token required') and the retry behavior ('Safe to retry with the same idempotency_key'), which go beyond the annotations. It also explains that this action completes the workflow, providing behavioral context. No contradiction with annotations (readOnlyHint=false, idempotentHint=true, etc.).

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 three concise sentences with no filler. The first sentence states the core purpose, the second gives the auth requirement, and the third gives idempotency guidance—each earning 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?

Given the output schema exists and the input schema is fully documented, the description does not need to explain return values. It provides essential context about the job lifecycle, auth, and retry safety, making it sufficient for an agent to invoke 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?

The input schema already documents all three parameters with 100% coverage, so the baseline for parameter semantics is high. The description adds meaning by referring to 'result payload' (submitted_payload) and explicitly linking idempotency_key to retry safety, which clarifies the parameter's purpose 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 ('Submit the result payload') and the specific resource ('a job the calling agent has claimed'), which distinguishes it from siblings like claim_job and list_jobs. The phrase 'completing the job workflow' anchors it as the final step in the job lifecycle.

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 the appropriate use case: submitting results for a job the agent has already claimed. It does not explicitly name alternatives or exclusions, but the context is clear enough to guide an agent. The sibling tool names (claim_job, list_jobs) further help disambiguate when this tool is appropriate.

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

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

Annotations already indicate this is a mutating, idempotent, non-destructive operation. The description adds the Authorization: Bearer header requirement, which is useful but does not disclose what side effects occur (e.g., state changes, external calls). It does not contradict the annotations.

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 very short and front-loaded, stating the operation in the first sentence and the auth requirement in the second. It avoids fluff, though it sacrifices detail for brevity.

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 tool with 4 required parameters and a complex domain (Direct Session operations), the description is severely lacking. It does not explain what a direct offer is, what verification entails, or how this fits into the broader workflow. The presence of an output schema helps but does not compensate for the absence of usage 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 coverage is 100%, so the description does not need to explain parameters. However, the schema descriptions are largely tautological (e.g., 'Canonical offer id argument for the verify_direct_offer Direct Session operation'), providing little meaning. The description itself adds no parameter context, so the 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 says 'Execute the canonical Direct Session verify_direct_offer operation,' which essentially restates the tool name without explaining what verifying a direct offer involves. It fails to distinguish this from sibling tools like approve_direct_session or create_direct_provider_verification_challenge.

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 on when to use this tool versus alternatives. It only mentions the authentication requirement, which is a prerequisite but not a usage condition. The sibling tools suggest various related operations, but the description offers no contextual differentiation.

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