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

Annotations already indicate readOnlyHint=true. The description adds useful behavioral context: output is pre-reasoned and not for individual value parsing, tier-gating, and authentication. It does not disclose potential errors or rate limits, but 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 front-loaded with the main purpose and then provides additional details on output, tier-gating, and authentication. It is well-structured but includes a full list of briefing IDs that is also in the schema; some repetition could be trimmed, but the tier grouping justifies the length.

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 no output schema, so the description must cover output characteristics. It mentions trend signals, confidence scores, regime classification, and causal narratives, and states that output is decision-ready. This is sufficient for an agent to understand the nature of the response. Authentication and tier constraints are also covered.

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 each parameter is already documented. The description adds value by grouping briefing IDs into tiers (Free, Basic, Pro), which provides semantic grouping not present in the enum descriptions. This helps agents choose appropriate briefings based on access level.

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 it retrieves a pre-reasoned market briefing with specific elements (trend signals, confidence scores, etc.) and lists domains. It distinguishes from sibling tools like get_metric and list_metrics by focusing on composite, reasoning-ready output.

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 explains when to use (for decision-ready briefing), how output should be consumed (not parsed), and authentication/tier requirements. However, it does not explicitly state when NOT to use or mention alternatives like get_metric for specific data points.

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, and the description adds valuable behavioral context: no authentication needed and the specific data returned (status, version, endpoints). This goes beyond the minimal read-only flag without contradicting it.

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 that communicates the purpose, scope, and access requirement with zero filler. Every phrase 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 simple read-only health check tool with one optional parameter and no output schema, the description covers the essential context: what it checks, what it returns, and authentication requirements. This is complete for an agent to select and invoke 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?

The input schema has 100% description coverage for the single parameter 'verbose', which fully documents its effect (detailed endpoint descriptions, pricing tiers, data coverage, default false). The description does not need to add parameter details, and 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 states a specific verb ('Check') and clearly identifies the resource ('API health status, version, and available endpoints'). This distinguishes it from sibling tools like get_context and get_metric, which serve different purposes.

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 (checking API health, version, and endpoints) and adds an important usage note ('No authentication required'). While it does not explicitly name alternatives, the distinct purpose and sibling names make 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?

The description discloses that authentication is required ('Requires API key authentication'), and specifies that the return value is analyzed context, not raw values. Annotations already indicate readOnlyHint=true, which is consistent. No contradictions.

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 due to the exhaustive list of metrics, which could be referenced from the schema enum instead. The core functionality is front-loaded, but the list inflates the length unnecessarily. Still, it is well-structured and 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 tool's complexity (multiple analysis components and a large set of metrics) and the absence of an output schema, the description provides sufficient context about return values (signal, trend direction, momentum, 90d percentile) and usage scenarios. No gaps are apparent.

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% coverage for both parameters, so the baseline is 3. The description adds value by listing all possible metric values (beyond the enum in the schema) and clarifying the default for the format parameter ('markdown (default)'). This is helpful.

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 fetches a single metric with analyzed context (signal, trend, momentum, percentile). The list of available metrics is exhaustive, and the verb 'get' combined with 'metric' clearly distinguishes it from siblings like 'list_metrics' or 'get_context'.

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 advises when to use: 'Use when you need to understand what a metric means for decision-making, not just its number.' It contrasts with raw data retrieval, but doesn't explicitly mention alternative tools (e.g., list_metrics for listing all metrics). This is good but not perfect.

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, and the description adds useful behavioral context about tier distribution and categories without contradicting annotations. No destructive behavior is implied or omitted.

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: purpose, specifics (counts per tier), and categories/auth. Front-loaded and 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?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers what the tool does, what it returns, and key constraints (no auth). Complete for the intended use.

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?

Input schema has one optional parameter 'tier' with enum and description, and schema description coverage is 100%. The description mentions 'tier requirements' but adds little beyond what the schema provides, so 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 verb 'list' and resource 'market briefings', specifies tier requirements, and distinguishes from sibling tools (get_context, get_health, etc.) which perform different operations.

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 context on what the tool returns (18 briefings across tiers, categories) and notes no authentication, implicitly guiding usage. However, it lacks explicit when-to-use vs alternatives, though sibling differentiation 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?

Beyond the readOnlyHint annotation, the description discloses that no authentication is required, lists specific metric categories and examples (Bitcoin price, hash rate, etc.), and clarifies the scope (30 metrics). This adds useful behavioral 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 two sentences with no wasted words. It front-loads the core purpose ('List all available individual metrics') and efficiently provides scope, examples, filter options, and authentication status.

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 (list with optional filters, no output schema), the description covers purpose, scope, filtering, and authentication. It could optionally specify the return format (e.g., array of metric objects) but is largely complete for typical use.

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?

Both parameters (search, category) have clear descriptions in the input schema (100% coverage). The description reiterates filtering capability but adds no new semantic detail about parameter syntax or constraints beyond what the schema 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?

The description uses the specific verb 'list' with the resource 'all available individual metrics' and provides concrete examples (30 metrics across bitcoin, macro, calculated categories). It clearly distinguishes from siblings like get_metric (single metric) and list_briefings (briefings).

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 states the tool lists all metrics and allows optional filtering by category or search term, and notes no authentication required. It implies use for browsing available metrics, but does not explicitly contrast with get_metric for retrieving a specific metric's data.

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