Toolcard

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the three aggregate findings produced, notes they omit the resource field, and explicitly states 'Does not store the tools,' which is a useful non-persistence guarantee absent from 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?

Three short sentences, front-loaded with the scope, then the return shape, then the side-effect disclaimer. The fragment 'Those three omit resource' is terse to the point of being cryptic, which slightly undercuts an otherwise efficient structure.

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

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

With no output schema, the description does take on return-value disclosure and delivers the main finding categories plus a note about the resource field. Both optional parameters are covered by the schema, and the no-storage guarantee is stated, leaving only minor gaps such as finding severity or ordering.

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 both parameters are fully documented in the schema, giving a baseline of 3. The description restates the tools/list-vs-server-card duality and the omitted-tools fallback but adds no format or syntax detail beyond what the schema already provides.

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

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

States a specific verb ('Check') and a clear resource scope ('every tool in a tools/list result or a server card'), and the aggregate checks it produces are named. It implies but never states the distinction from the sibling check_tool (singular vs. whole-list), so differentiation is left to the reader.

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 explicit when-to-use or when-not guidance, and no alternative is named. The only conditional ('result is used only when tools is omitted') lives in the schema, not the description, so an agent gets no routing help against check_tool.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real value: it discloses the return shape (findings), the chaining contract (a toolcard://answers URI to pass to resources/read), and statelessness ('Does not store the tool'). It stops short of describing severity levels or empty/failure results.

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, front-loaded with purpose, followed by return behavior, the chaining URI, and a non-persistence guarantee. Every sentence carries distinct information with no filler.

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

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

There is no output schema, so the description must carry the return-value burden, and it only partially does — 'Returns findings' and the answer-URI pattern are covered, but finding structure, severity, and counts are not. For a nested-object input with no output schema, this is adequate but not 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 description restates which fields are checked (name, description, inputSchema) but adds no format, validation, or edge-case guidance beyond what the schema properties already 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?

States a specific verb (check) and resource (one MCP tool name, description, and input schema) against 'Toolcard cited rules'. The word 'one' implicitly separates it from the server-scoped sibling check_server, though it never names that sibling outright.

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

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

Usage is implied by the purpose — validate a single tool definition — but there is no explicit when-to-use, when-not-to-use, or pointer to check_server for server-level validation. An agent must infer the scoping distinction between the two check_* 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 readOnly, idempotent, and non-destructive, but the description adds genuinely useful behavior: the data is anonymous, it aggregates 'called versus ignored' reports, and it is explicitly not a representative sample. That sampling-bias disclosure is exactly the kind of trait annotations cannot express; only return format/scale details are missing.

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 tight sentences with zero waste; the core action is front-loaded and the sampling caveat follows immediately after. Nothing could be cut without losing meaning.

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

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

With no parameters and no output schema, the description carries the burden of telling the agent what comes back, and it does ('tally of called versus ignored reports'). It could go slightly further on the shape/scale of the tally (counts, percentages, sampling window), but for a trivial read-only aggregate this is close to sufficient.

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

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

The tool takes zero parameters, so by the rubric the baseline is 4. The description correctly implies a no-argument aggregate read, and there are no parameters whose semantics need explaining.

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

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

States a specific verb ('Return') and resource ('anonymous tally of called versus ignored reports on this server'), so an agent knows exactly what data comes back. It does not explicitly name or contrast with the sibling write tool report_outcome, and the title ('Read the call tally') largely echoes the description rather than sharpening the distinction.

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 statement of when to call this versus report_outcome (the obvious sibling that records outcomes) or check_server/check_tool. The only guidance is an interpretive caveat ('Not a representative sample'), which warns about reading the result but does not route 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 write/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context beyond the annotations: it discloses the privacy-preserving storage model (SHA-256 of the description, raw description not retained), which matters for an agent deciding whether it is safe to pass a description.

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 short sentences, front-loaded with the action and then the storage semantics; no filler or repetition. Every sentence carries information.

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

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

For a simple logging tool with full schema coverage and annotations covering safety and idempotency, the description covers the essentials. Minor gaps: no output-schema exists and the description does not say what is returned or how duplicate report_id values are handled, though idempotentHint partly addresses the latter.

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 all five parameters including the enum on 'result' are already documented. The description's 'stores the name... and the result' and the hashing note duplicate what the schema already says for 'description', so it adds little beyond the structured fields.

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 first sentence names a specific verb and resource ('Record whether an agent called or ignored a tool'), and the second sentence clarifies exactly what is persisted. The purpose is unambiguous, but it never names or contrasts with the siblings (check_tool, outcome_summary), leaving the agent to infer the division of labor.

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 statement of when to call this versus check_tool or outcome_summary, nor any prerequisites or timing guidance. Usage is only faintly implied by the verb 'Record', which is not enough to route an agent reliably.

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