ShadowGraph

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds two useful traits beyond them: it is free to call, and results are limited to 'recent' filings from an official source. It says nothing about latency, coverage window, or empty 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?

Two short sentences, front-loaded with the cost signal and then the core action; no filler. Slightly terse rather than padded, which is appropriate.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. Still missing: what a 'supported' symbol is, the meaning of the limit parameter, and the recency window, which leaves an agent guessing at the edges.

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 50%: 'symbol' is documented with examples, but 'limit' (1-10) has no schema description. The word 'recent' loosely conveys that a limit exists and bounds recency, but neither the default nor the max is stated in prose, so the description only partially compensates.

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 clear verb ('Return'), a specific resource ('recent official SEC EDGAR filings'), and the scoping input ('for a supported company symbol'). It does not differentiate from any sibling, but the siblings are unrelated tools so that is a minor gap.

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 is the cost signal 'Free.' and the vague qualifier 'supported company symbol'. There is no statement of when to use this versus alternatives, nor any prerequisite (e.g., what makes a symbol 'supported' or that data is US-only).

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 the safety profile (readOnly=true, idempotent=true, destructive=false, openWorld=true), lowering the burden. The description adds a genuinely important behavioral fact not in the annotations: the $5.00/call cost, which materially affects invocation decisions, plus the breadth of the returned pack. It stops short of rate limits or output format specifics, so 4 rather than 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?

A single sentence that front-loads the cost and then lists the pack contents; no filler or redundancy. It is efficient, though the feature list is dense and could be structured more scannably.

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 a zero-parameter schema, an existing output schema, and annotations covering the safety profile, the description's main job is to convey scope and cost, both of which it does. The one remaining gap is relative positioning against the twelve sibling tools, which it never addresses.

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 baseline is 4 and there is no schema-level parameter meaning to add or compensate for. The description correctly says nothing about inputs, which is appropriate here.

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 names a concrete deliverable ("Full machine-readable research pack") and enumerates its contents: expanded official evidence, global news, graph relationships, price lags, and commercial opportunity analysis. That is a specific resource description. It does not, however, differentiate this tool from the many similarly named siblings (e.g., shadowgraph_global_brief, shadowgraph_opportunity), so it lands at a clear-but-undifferentiated 4.

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 usage-oriented signal is the price ("Paid ($5.00/call)"), which implies a cost tradeoff but never says when to choose this over shadowgraph_free_preview or the other briefs. No when-to-use, when-not-to-use, or alternative-naming is provided, so this is essentially absent 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: the figure is a fixed, dated benchmark measured outside-in on a 221-service sample rather than live data about the caller, it costs nothing, and it discloses the commercial escalation path (free vendor scan, $50 report, $1,500 assessment). What it doesn't state is freshness cadence or any rate limiting.

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?

It is front-loaded and reasonably tight, opening with 'Free.' and then the question answered. But it is one packed run-on sentence, and the closing clause about a $50 report and a from-$1,500 assessment is promotional rather than tool-selection information, which dilutes the signal an agent needs.

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 benchmark with a full output schema and complete safety annotations, the description covers what is returned, the methodology sample size and the dated nature of the figures. An agent has enough to decide to call it; only data freshness and the exact benchmark reference date are 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?

The tool takes zero parameters and the description correctly implies the single call returns a complete standard benchmark with no inputs to supply. With an empty schema at 100% coverage there is nothing further to clarify, so the baseline of 4 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 names a specific verb and artifact: it returns a dated sector benchmark of cloud/CDN/DNS concentration behind DORA Register of Information ICT third-party services, with concrete contents (HHI per layer, top providers, CTPP hyperscaler share, 221-service sample). An agent can tell this apart from sibling research tools without opening a schema. It stops short of naming any sibling alternative, so it doesn't reach the top band.

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 context is implied well enough by 'how concentrated are the cloud, CDN and DNS providers behind the ICT third-party services a bank or payment institution typically lists in its DORA Register of Information' — it is clearly for DORA concentration questions. However there is no explicit when-to-use/when-not-to-use guidance and no pointer to a sibling tool such as shadowgraph_deep_research for a non-benchmark variant.

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, openWorld and non-destructive, so the safety profile is covered. The description adds only "Free" and the fact that notices are "current", with nothing on rate limits, auth, or result volume despite openWorldHint implying an external live source.

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?

A single tight sentence front-loads the cost cue and the core action with no filler. It is efficient, though its brevity borders on under-specification for a three-parameter search tool.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, with 33% parameter coverage and no routing guidance among many sibling tools, the definition is minimal rather than 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 coverage is only 33%: country is documented in the schema, while keyword and limit have no descriptions. The description restates that keyword and buyer country act as search filters but adds no format, matching behavior, or meaning for limit (capped at 10), so the low-coverage gap is not compensated.

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 (Search) and resource (current EU TED procurement notices) with the filtering dimensions (keyword, buyer country). It is clear on its own, but it never distinguishes itself from the closely related sibling shadowgraph_procurement_opportunity, so an agent must guess which procurement tool to pick.

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 "and/or" phrasing implies the two filters are optional and combinable, and "Free" hints at a cost boundary, but there is no explicit when-to-use, when-not-to-use, or named alternative against shadowgraph_procurement_opportunity. Usage is left to inference.

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, non-destructive, and open-world behavior, so the safety profile is covered. The description still adds real behavioral context: it is free (cost), "live" (freshness), and "compact" (payload size), which the annotations do not convey.

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?

A single sentence with the differentiator ("Free") front-loaded and no filler. Every clause carries content or routing 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?

An output schema exists, so return values need not be spelled out, and the annotations cover safety. The description still tells the agent what the preview contains and what to do next, leaving little an agent needs missing for a zero-param read 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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies parameter-free invocation by describing a fixed preview payload.

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 enumerates concrete contents: global coverage, relationship graph, and top price-lag signal. It also implicitly positions itself as the free entry point versus the paid tools, though it never names a specific sibling, so differentiation is thematic rather than explicit.

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?

"Free" and "plus the paid tools to call next" imply this is a starting point that escalates to paid siblings, which is useful workflow guidance. However, there is no explicit when-to-use/when-not statement and no named alternative, so the agent must infer the routing.

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 the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds a genuinely non-obvious behavioral trait: per-call cost of $2.50, which should make an agent think twice before invoking it. It does not describe latency or pagination, but with an output schema present the remaining burden is low.

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?

A single sentence, front-loaded with the cost signal, that wastes little space while packing in the content domains. The trailing enumeration is slightly list-like but each item earns its place by describing coverage.

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 an output schema to explain the return shape, the description only needs to convey scope and cost, which it does. The one real gap is differentiating this from the many similar shadowgraph siblings, which complexity here does not excuse.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. No syntax, defaults, or format guidance is needed here.

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 names a specific resource (a global intelligence brief) and enumerates the data domains it fuses (official disclosures, EU procurement, news, relationship graph, lead/lag, opportunities), so an agent understands what it returns. However, it does not distinguish itself from close siblings such as shadowgraph_global_snapshot or shadowgraph_deep_research, leaving the 'brief vs snapshot' choice ambiguous.

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 'Paid ($2.50/call)' marker and 'Higher-density' phrasing imply this is a premium, heavier option to be used selectively rather than a default, which is useful implied guidance. But no sibling is named and there is no explicit when-to-use/when-not-to-use rule despite a shadowgraph_free_preview and several overlapping siblings existing.

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 the safety profile (readOnly, idempotent, non-destructive, open-world), so the description earns credit for adding context they cannot: an explicit $0.50/call cost and the MPP/Stripe payment handshake, including the -32042 error and the credential retry path. It does not disclose latency, rate limits, or snapshot freshness/coverage windows, keeping it short of 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?

Two sentences, front-loaded with the cost so an agent sees the billing implication before anything else, and no filler. The payment sentence is dense but every clause (protocol, error code, retry field) carries necessary 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?

An output schema exists, so return values need not be explained, and annotations plus the payment note cover safety and billing. What is missing for a tool in a cluster of nine overlapping intelligence siblings is any routing logic explaining when this snapshot is the right call versus global_brief, deep_research, or free_preview.

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 declared parameters the baseline is 4, but the description instructs the caller to retry with params._meta["org.paymentauth/credential"] while the schema declares an empty properties object and additionalProperties:false. That reference is useful operational detail yet sits in tension with the schema, so the param story is only partially coherent.

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 names a concrete artifact ('global intelligence snapshot') and enumerates its coverage domains — official filings, procurement, infrastructure, markets, evidence-ranked relationships — so an agent knows what it returns. It does not, however, distinguish itself from near-siblings like shadowgraph_global_brief or shadowgraph_deep_research; 'fast' only implicitly contrasts with deep research.

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 choose this tool over the nine siblings, no exclusions, and no mention of alternatives such as shadowgraph_free_preview or shadowgraph_global_brief. The only procedural guidance is the payment retry flow, which is operational rather than a selection criterion.

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, non-destructive, and openWorld, so the safety profile is covered. The description adds 'Free' (cost) and characterizes the returned content, which is genuine extra context, but it omits rate limits, freshness/latency, and depth of coverage.

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 short sentences with the cost tag and the core question front-loaded, then the return content. No filler, though the phrasing is slightly informal ('what moved').

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 need not document return values, and it correctly focuses on what the tool answers and roughly what comes back. The only gap is a missing distinction from the numerous sibling market-summary 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 0% for the single 'limit' parameter, so the description should compensate. 'Returns the largest current company moves' loosely implies limit bounds the number of moves returned, but it never states the parameter's meaning or that it caps results at 10.

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 (answer/return) and resource (global market moves plus thematic news) with a clear temporal scope ('today'). It is distinguishable from siblings like global_snapshot or market_signal, though it never names or contrasts them explicitly.

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?

'Answer the concrete question: what moved in global markets today?' and the 'Free' tag imply the usage context (quick recap, cost-sensitive). There is no explicit when-to-use or when-not-to-use guidance relative to the many sibling brief/snapshot/signal 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, so the safety profile is covered. The description adds genuinely non-obvious behavior that annotations cannot express: it is a paid call ($0.75), payment runs through MPP/Stripe, and a failed call surfaces as JSON-RPC error -32042 that must be retried with a credential in params._meta. That is exactly the kind of operational context the annotations lack.

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 fragments, front-loaded with cost, then capability, then payment mechanics. Nothing is padded, though the payment instruction is dense in quoted identifiers and slightly interrupts the flow of the purpose statement.

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 tool with an output schema and solid annotation coverage, the description covers cost and payment adequately. What it omits is the differentiator against the many similar 'global' siblings and any sense of what the signal actually returns, which matters for a tool an agent must choose among ten options.

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 declared parameters, so the baseline is 4. The description goes slightly beyond by documenting an out-of-schema runtime field, params._meta["org.paymentauth/credential"], which an agent would otherwise have no way to discover from the empty 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 identifies the resource as 'global directional market intelligence' and hints at method ('measured lead/lag evidence', 'invalidation logic'), but it is an abstract noun phrase rather than a concrete verb+output. With siblings like shadowgraph_global_brief, shadowgraph_global_snapshot, and shadowgraph_market_recap, an agent gets no basis for telling this tool apart from them.

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 call this tool versus its nine siblings, nor any stated prerequisites or exclusions. The only procedural advice concerns payment retry mechanics, which is invocation logistics rather than usage 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 declare the safe/idempotent read profile, and the description goes well beyond them: it discloses the $1.00/call cost, the MPP/Stripe payment flow, the specific JSON-RPC error -32042 challenge, and the exact retry path via params._meta. That is exactly the operational context an agent cannot get from 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?

Three tight fragments, cost front-loaded before purpose and payment mechanics. Every clause carries information; no filler. Slightly dense but well ordered.

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?

An output schema exists, so return values need not be explained, and with no input parameters the description's job is mostly operational. It covers cost and the payment handshake; the only real gap is that it never positions this tool against its many siblings.

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 (baseline 4), but the description reveals a required out-of-schema parameter for the payment retry — params._meta['org.paymentauth/credential'] — which the agent would otherwise never discover. That is a genuine semantic addition 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?

States a concrete verb and output object ('Find evidence-backed supplier and second-order commercial opportunities') and enumerates the evidence sources (SEC EDGAR, EU TED, KAP, infrastructure, price-lag). It is clear what it produces, but it does not distinguish itself from siblings that share those same sources, e.g. shadowgraph_company_filings or shadowgraph_eu_tenders.

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 stated when-to-use, when-not-to-use, or alternative routing. With nine sibling shadowgraph tools, an agent gets no help deciding between this and shadowgraph_deep_research, shadowgraph_eu_tenders, or shadowgraph_global_brief; usage must be inferred purely from the source list.

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, destructiveHint=false, and openWorldHint=false, so safety is covered structurally. The description adds genuinely new context: this tool is free and serves as the pricing/discovery surface for the paid tools, which is exactly the kind of cost/role information annotations cannot convey.

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 dense fragments with zero waste. The cost signal ('Free.') is front-loaded before the payload description, which is the most decision-relevant fact for an agent choosing among paid siblings.

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 return values (capabilities, prices, URLs) need not be spelled out in the description, and no parameters require explanation. What remains thin is routing guidance relative to the three sibling tools, which is the only real gap.

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 there is no per-parameter semantics to document and the baseline for a no-param tool is 4. The description does not need to compensate for any schema coverage gap here.

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 enumerates concrete resources: service capabilities, paid-tool prices, and discovery URLs. An agent can tell this is the metadata/discovery entry point, though it doesn't explicitly name the sibling tools it complements.

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 leading 'Free.' plus the mention of 'paid-tool prices' implies this is the discovery call to make before/instead of the paid siblings, but there is no explicit when-to-use or when-not statement naming shadowgraph_alpha or the others.

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