Server Quality Checklist

Tool Scores

• a2a_get_taskA
  4.6/5.0
  Behavior5/5

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

  Even though annotations already mark the tool as readOnly and idempotent, the description adds meaningful behavioral detail: the full set of task statuses, the shape of artifacts, conversation messages, created/updated timestamps, and concrete error strings. This goes well beyond the annotation hints.

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

  Conciseness4/5

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

  The description is well-organized with clear sections (Args, Returns, Examples, Error Handling) and front-loads the core purpose. It is somewhat long, but the extra detail is justified because there is no output schema and the error-handling information is genuinely useful.

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

  Completeness5/5

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

  Given the absence of an output schema, the description compensates fully by documenting the response structure, status states, error cases, and typical invocation examples. It also explains where to obtain the taskId, leaving little ambiguity for an agent selecting or calling this tool.

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

  Parameters3/5

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

  The input schema already documents both parameters fully, including types and descriptions. The description mostly restates these in the Args section, but it does add illustrative example parameter values, which is helpful but not a major semantic addition beyond the schema.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Retrieve the status and details of an A2A task by its ID.' It clearly states what the tool does and covers the key returned data (status, progress, artifacts), making it easy to distinguish from the sibling tools.

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

  Usage Guidelines5/5

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

  The description provides explicit use cases with 'Use when' examples and a direct exclusion: 'Don't use when: You want to send a new message (use a2a_send_message instead)'. This gives an agent clear routing guidance relative to a sibling tool.

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

• a2a_get_agent_cardA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate readOnlyHint, idempotentHint, and non-destructiveness. The description goes further by documenting error messages for unreachable URLs, invalid formats, and 404 responses, as well as the expected return structure and A2A protocol context. This is meaningful behavioral disclosure beyond 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.

  Conciseness4/5

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

  The description is well-structured with clear sections for Args, Returns, Examples, and Error Handling, and it front-loads the core purpose. The three usage examples are somewhat repetitive, but they are concise and reinforce the intended invocation pattern.

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

  Completeness5/5

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

  The tool has one simple parameter, no output schema, and comprehensive annotations. The description fully compensates for the missing output schema by enumerating the expected response fields, and it covers errors, protocol context, and practical usage. Nothing essential is missing for an agent to call this tool correctly.

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

  Parameters4/5

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

  The schema already fully documents agentCardUrl with 100% coverage, so the baseline is 3. The description adds value by explaining that the endpoint is 'typically at /.well-known/agent-card.json' and providing concrete example URLs, which helps the agent construct valid parameter values.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Retrieve an agent's card containing metadata and capability information.' It also names the sibling alternative for sending messages, so the tool is clearly distinguished from a2a_send_message and the other siblings.

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

  Usage Guidelines5/5

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

  Usage guidance is explicit with 'Use when' examples such as 'What can this agent do?' and a 'Don't use when' clause that routes to a2a_send_message instead. This gives an agent clear decision criteria for selecting this tool versus its siblings.

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

• a2a_cancel_taskA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations, the description discloses important behavioral nuances: cancellation may not be immediate, the agent 'attempts' to stop gracefully, and task status transitions asynchronously. It also enumerates failure modes including 'Task not found', 'Task already completed', and 'Cancellation not supported'. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is well structured with clear sections for Args, Returns, Examples, and Error Handling, and the main purpose is front-loaded. While it is longer than minimal, every section adds useful operational information rather than filler.

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

  Completeness5/5

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

  With no output schema, the description compensates by documenting the exact return shape, error responses, async cancellation behavior, and the follow-up verification tool. It is sufficiently complete for an agent to understand expected behavior, know what inputs to supply, and handle failures correctly.

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

  Parameters4/5

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

  The schema already covers both parameters at 100%, so the baseline is 3. The description adds value with concrete usage examples mapping natural-language requests to parameter values, and clarifies that taskId should identify the active task to cancel. It doesn't add much beyond the schema, but the examples and error context make it slightly stronger.

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

  Purpose5/5

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

  The description opens with 'Cancel a running A2A task' and clearly specifies the action, resource, and expected effect ('attempt to gracefully stop the task execution and update its status to canceled'). This distinguishes it from sibling tools like a2a_get_task, a2a_send_message, and a2a_get_agent_card, which all involve different actions.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use examples ('Cancel the long-running task abc-123'), a don't-use-when exclusion ('Task has already completed'), and an explicit post-cancellation verification step ('use a2a_get_task to verify'). This gives an agent clear guidance for choosing and following up on this tool.

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

• a2a_send_messageA
  4.9/5.0
  Behavior5/5

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

  Annotations already set readOnlyHint=false and idempotentHint=false, but the description adds significant behavioral context: the tool may return an immediate message or an async task object, responses can contain multiple parts, and specific error strings are documented. This goes well beyond the structured annotations.

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

  Conciseness5/5

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

  Although longer than average, the description is well-structured with dedicated Arg, Returns, Examples, and Error Handling sections. Every sentence contributes either parameter semantics, usage guidance, async behavior, or error troubleshooting—no filler or redundancy.

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

  Completeness5/5

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

  With no output schema, the description thoroughly documents the possible return shapes (message vs. task), async workflow, error strings, and follow-up polling behavior. It also covers all three parameters and names sibling tools where relevant, making it complete 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.

  Parameters4/5

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

  Schema coverage is 100% with descriptions for all three parameters, so the baseline is 3. The description adds value by explaining the taskId continues a conversation thread, specifying message length in the Args section, and providing realistic example parameter values that illustrate correct usage.

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

  Purpose5/5

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

  The description begins with a specific verb and resource: 'Send a message to an Agent-to-Agent (A2A) protocol compliant agent.' This cleanly distinguishes it from sibling tools like a2a_get_task, a2a_cancel_task, and a2a_get_agent_card, all of which have obviously different purposes.

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

  Usage Guidelines5/5

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

  The description provides explicit 'Use when' and 'Don't use when' guidance with concrete examples, directly naming sibling alternatives for cancellation and status checks. It also advises using a2a_get_task for polling when a task object is returned, giving the agent clear decision criteria.

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