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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the server never merges/ranks/picks a winner, every model receives the brief byte-for-byte identically, and the output is verbatim and attributed. It also warns that naming a preferred answer primes the panel and destroys the signal. This goes beyond the annotations and helps the agent understand the tool's non-obvious 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 compact and front-loaded: the first sentence states the core behavior, the second gives usage guidance, the third explains the value, and the final sentence clarifies what the tool does NOT do. Every sentence earns its place, and the structure is 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 tool with 6 parameters, no output schema, and no nested objects, the description covers the essential behavioral contract: what it sends, what it returns, when to use it, and what it never does. The only minor gap is that it doesn't describe the exact response format (e.g., JSON structure), but since there is no output schema, an agent might benefit from knowing the response shape. However, the description's explicit 'verbatim, attributed, unranked and unsynthesized' gives enough for most use cases.

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 50%, so the schema documents brief, models, and system but not max_tokens, timeout_ms, or temperature. The description compensates by explaining the brief's purpose in detail ('Include the goal, hard constraints, current situation, decisions already taken, what was rejected and why, and what is still unknown') and warning against naming a preferred answer. The remaining parameters (max_tokens, timeout_ms, temperature) are standard LLM parameters with clear names and schema constraints, so the gap is minor.

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 ('Send'), a specific resource ('ONE identical brief to several LLMs in parallel'), and the exact output behavior ('every answer back verbatim, attributed, unranked and unsynthesized'). It also explicitly distinguishes itself from any merging/ranking tool by saying 'This server never merges, ranks or picks a winner.' This is a clear, specific definition that an agent can act on.

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 guidance: 'when a decision is consequential or hard to reverse, when you want your own reasoning stress-tested by models that did not see it, or when the user asks for other opinions or approaches.' It also explains the value of the spread and what a split means. It doesn't name sibling alternatives, but the siblings (get_status, list_models, get_debug_logs) are clearly different operations, so no exclusion is needed.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: newest-first ordering, cursor pagination, filterability by correlationId/level/event/operation/time, and the fact that credentials are redacted before persistence. This is meaningful additional context that helps the agent understand what to expect.

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 earning its place. The first sentence front-loads the core behavior (newest-first, filterable, paginated). The second sentence gives the primary use case (correlationId from consult). The third sentence adds a security-relevant detail (credential redaction). 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 read-only, idempotent, non-destructive tool with no output schema, the description covers the essential context: what events are, how to filter, how pagination works, and the key use case. The only minor gap is that it doesn't explicitly state the return format (e.g., JSON array of event objects), but with no output schema and a clear description of the event types, this is a small omission. The description is complete enough 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 only 14%, so the description must compensate. It does: it names the filterable fields (correlationId, level, event, operation, time) and explains the correlationId's purpose ('pass it here to see exactly what happened per model'). It also mentions cursor pagination, which maps to the cursor parameter. However, it doesn't explain the 'since' parameter's format beyond what the schema says, and it doesn't detail the 'limit' parameter's behavior. Still, the description adds significant meaning beyond the sparse schema.

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

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

The description states a specific verb ('Read'), a resource ('persisted structured debug events'), and the exact content ('dispatches, per-model failures and validation errors'). It also names the sibling it is not (consult) by explaining that consult results carry a correlationId that can be passed here. This clearly distinguishes it 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.

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

The description explicitly tells the agent when to use this tool: after a consult result, pass the correlationId to see exactly what happened per model. It also implies the alternative (consult) by saying 'Every consult result carries a correlationId: pass it here...' This is clear context with an explicit routing condition.

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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds a valuable behavioral guarantee, 'Never returns the key itself,' which goes beyond structured hints and addresses a security-relevant concern.

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 no filler. The main reporting scope is front-loaded, followed by a direct usage instruction and a security note. 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 no-parameter read-only status tool, the description enumerates all reported fields, gives a clear usage condition, and clarifies the key-handling behavior. There is no output schema, so enumerating the contents is sufficient for correct invocation and interpretation.

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 description fully covers parameter semantics trivially. The description adds no param details, but none are needed; baseline 4 for zero parameters 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 uses a specific verb ('Report') with a clear resource (server/configuration/status) and enumerates exactly what is reported: server version, API key configuration status, remaining credit, default panel, and limits. This distinguishes it from siblings like list_models and get_debug_logs.

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

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

It gives an explicit trigger: 'Call this first when consult fails with an authentication error.' This clearly tells the agent when to prefer this tool and implicitly frames the alternative (consult). No ambiguity remains about 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 establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds genuinely useful behavioral context beyond the annotations: the catalog is 'live', results may change over time, and the tool supports substring search, a free-only filter, and cursor pagination. 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?

Three sentences with no filler: the first gives the primary purpose, the second summarizes key capabilities compactly, and the third explains why the tool should be used now before consulting. The most decision-relevant detail 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?

The description is sufficient for a read-only listing tool with no required parameters. It explains the dynamic nature of the resource, mentions the main filtering and pagination controls, and orients the agent toward its downstream use with consult. No output schema exists, but the tool's return shape is inferable from the catalog-listing purpose.

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 only 40%, so the description carries extra weight. It compensates by describing the behaviors that map to query (substring search), free_only, and cursor, and the sort enum is self-documenting via its option names. Only limit gets no added semantic context, but its schema min/max constraints partially cover that.

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 and resource ('Browse the live OpenRouter model catalog') with a clear purpose ('pick an exact panel for consult'). It differentiates itself from the sibling tools by being catalog-specific: consult performs a consultation, get_status and get_debug_logs concern system state, not model listing.

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: this is the tool to use for resolving model ids before a consult, and the warning that 'Model ids change over time' implies using it instead of hardcoding. It does not explicitly name an alternative or provide when-not-to-use guidance, but the context is unambiguous given the sibling set.

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