pronto-stream

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

The description reveals conditional output behavior beyond the annotations: it returns a CWF BILL line, a CREDIT line only when a metering balance exists, and a NOTE line when not entitled. It also explains the unauthenticated state and its remedy, which is valuable context beyond readOnlyHint and idempotentHint.

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 core reporting purpose, then adds conditional return behavior and routing guidance. Every sentence adds necessary context, and no filler or redundant restatement of the tool name or annotations is present.

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 no parameters, no output schema, and rich behavioral nuance, the description covers the essential call context: what will be returned, under what conditions, what the different states mean, and what to do next. An agent has enough information to correctly invoke and interpret the result.

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 is empty, so there are no parameter semantics to document. With zero parameters, the baseline is 4, and the description correctly focuses on behavior rather than nonexistent input details.

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 action ('Report') and a specific resource ('who you are resolved as and what your plan grants'), then enumerates exactly what is reported: identity, funded account, plan, call ceiling, row budget, and indicator set. This clearly distinguishes the tool from siblings like get_plans or register_agent.

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 what to do when unauthenticated ('call register_agent next') and then presents the two follow-on paths: buy a plan with open_payment or hand the claim code to the budget holder. It also explains the conditions under which a NOTE line appears, giving clear context for when this tool is useful versus alternatives.

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 annotations (readOnlyHint, openWorldHint, idempotentHint), the description adds significant behavioral context: it truncates the topic tail, stays short enough to read in full, ranks the busiest first, and states structure rather than signal content. This is more than the annotations convey, though it doesn't detail error cases or exact response formatting.

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 well-structured and front-loaded: it states the core purpose first, then usage guidance, then the key distinction from list_facets. Each sentence earns its place; even the final sentence adds the crucial caveat that the manifest is about structure, not content. No fluff or repetition.

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, read-only tool with no output schema, the description is unusually complete. It covers what the output is, how it's ranked, how it is truncated, why it should be used, where it fits in the workflow, and when to use the sibling list_facets. No essential decision-making context is 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 has zero parameters, and the schema already reflects 100% coverage, so parameter explanation is unnecessary. The description does clarify what the output covers ('two facet keys only, domain and topic'), which indirectly explains the absence of filter parameters. With no params, the baseline is 4 and there is no deficiency.

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 and object—'Read the shape of the wire'—and explains exactly what is returned: a two-level tree of domain and topics with signal counts, ranked by busiest. It clearly distinguishes itself from siblings like list_facets by saying it covers only domain and topic, and from scope_signals/search_signals by framing itself as the map to read first.

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 guidance: read the manifest once, choose a scope offline, then make one precise call to scope_signals or search_signals instead of guessing a filter. It also says when to call list_facets instead—when exhaustive vocabulary is needed. This is strong when-to-use versus when-not-to-use 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?

With readOnlyHint, openWorldHint, and idempotentHint already marking the tool as safe, the description goes further by disclosing result provenance, the absence semantics for product values, the NOTE line for plan-related withholding, and the fact that cross-source products are synthetic rather than emitted by an upstream API.

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 substantial but every paragraph earns its place. It is front-loaded with the core compute/citation behavior, then covers parameter omission, alternative catalogue tooling, important use-case caveats, and the plan-withholding NOTE behavior — all without boilerplate.

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 that there is no output schema, the description successfully carries the full behavioral burden: it explains what results contain, how sources are labelled, what absence means, how plan withholding is surfaced, and which sibling tool covers the complete catalogue. This is sufficient for an agent to invoke and interpret the result 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?

Although the schema already documents the product enum well, the description adds key behavioral meaning: omitting the parameter returns everything the current window supports, an absent product means no live inputs, and some indicators may be withheld due to plan restrictions with a NOTE line explaining the omission.

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 opens with a specific verb and resource: 'Compute derived intelligence products from the live wire.' It clearly distinguishes the tool from raw-signal and catalogue-list siblings by emphasizing that each result cites the signals it was computed from and labels uncited rows.

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 explicitly tells the agent to pick one enum value or omit it for everything supported, and directs the reader to list_fusion_products when a window-independent catalogue is needed. It also gives concrete advisory guidance for specific products, such as reading seismic_solution_consensus before acting on a single magnitude and reading both recession products.

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 readOnly, openWorld, and idempotent hints, so no mutation warning is needed. The description then adds valuable non-obvious behavior: the all-collections view enforces caps, anything overflowing is named on a note line, and collection filtering changes the depth/diversification of results. This gives the agent important expectations about response shape beyond the schema.

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 core action is front-loaded in the first sentence, and every subsequent clause earns its place by explaining decision-relevant behavior about diversification, overflow handling, and collection-specific depth. The form is compact despite the colorful phrasing, and no redundant or filler material is included.

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 list tool with no output schema, the description covers the tool's scope, filtering modes, output lineage ('CWF format', note lines), and key behavioral caveats. It does not spell out the full CWF line syntax or explicitly explain parsing after receiving the response, which would deepen completeness, but it is sufficient for correct selection and invocation.

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 100%, so the baseline is 3 because every parameter already has a description. The description adds genuine extra meaning for collection=...: 'full depth' with a single collection versus a diversified all-collections view. This nuance is not present in the schema alone and meaningfully changes invocation choices.

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 a specific verb and resource: 'Fetch the most recent live signals... optionally filtered to one collection.' It conveys the live, time-sensitive nature of the tool, which distinguishes it from sibling tools like get_signal, get_fused_signal, or search_signals. Even without naming siblings explicitly, the resource and freshness framing make its role unambiguous.

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 contextual guidance: the all-collections view is deliberately diversified, while passing collection switches to full-depth/full-volume reading. It tells the agent when each mode is appropriate. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls just short of fully explicit 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 declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-mutating read. The description adds the return structure (CWF PLAN lines and SETTLE line) and the fact it's machine-readable, which is useful. However, it doesn't disclose details like pagination, rate limits, or whether the output is always complete, but given the annotations, the description adds adequate context without 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?

The description is three sentences long, front-loads the core purpose, and each sentence adds distinct value: what it lists, why it's useful, and what it returns. There is no fluff or redundancy; it is appropriately sized and well-structured.

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 zero parameters, no output schema, and annotations covering safety, the description is complete. It covers what the tool does, why the agent would use it, the output format, and downstream actions (open_payment, escalation). An agent can confidently decide when and how to invoke it without missing information.

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, and the schema is empty. The description explains what the output contains, which is the closest to parameter semantics here. Since there are no parameters to document, the description adds value by detailing the return format, making the tool's behavior fully understandable without needing parameter documentation.

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 lists plans, costs, and what each plan raises (call ceiling, row budget, commercial indicator set). It distinguishes itself as a machine-readable alternative to parsing a pricing page, and explicitly mentions the output format (CWF PLAN lines and a SETTLE line). This is specific and unambiguous.

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 strong usage context: it is for deciding what to do about a refusal without parsing a pricing page, and it routes the agent to alternative actions (buy the plan yourself with open_payment, or escalate to whoever holds your budget). This is explicit when-to-use and names related actions, though it doesn't name a sibling tool for comparison; still, the guidance is clear and actionable.

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 mark the operation as read-only, so the description adds valuable behavioral context by defining how traversal works: each edge carries a link reason, and echo/related/cross-domain links have distinct semantics. The example also conveys that linked signals may come from independent providers.

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 core purpose and efficiently defines the three link types. The seismic-record/news-headline example adds helpful intuition but is slightly longer than strictly necessary for invoking the 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?

For a read-only graph traversal tool with two parameters and no output schema, the description gives enough context to select and invoke it. It explains the meaning of link categories and the starting point, though it does not explicitly cover what happens when no related signals exist.

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 already covers both parameters thoroughly: correlation_id accepts full ids, short handles, and aliases, while limit documents its default and maximum. The description adds no parameter-level meaning beyond the schema, so the baseline score of 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 names a specific action, resource, and scope: follow the link graph from one signal to other signals about the same subject. It clearly differentiates from likely siblings like get_signal and get_latest_signals by focusing on traversing semantic links rather than fetching or listing signals.

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 makes clear that this tool is appropriate when you already have a signal correlation id and want other signals about the same subject through link traversal. It does not explicitly name when not to use it or mention alternatives, but the context is strong enough to route an agent toward it.

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, openWorld, and idempotent, so the bar is lower. The description adds behavioral nuance beyond annotations: the live window turns over in about two minutes, recent reads may have aged out, and the error distinguishes staleness from typos. This gives an agent expectations beyond the structured hints.

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 tool's unique ordering and behavioral caveats are front-loaded: purpose is in the first sentence. Though longer than typical, each sentence earns its place — why this tool exists, what id forms are accepted, what temporal edge case to expect, and which sibling to use instead. Nothing is 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?

For a simple one-parameter read tool, the description covers the decision context, the exact input format, the failure mode around the time window, and alternative sibling tools. It also promises the result is exactly that row and nothing else. No critical operational knowledge is 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?

Schema description coverage is 100% for the single parameter, so baseline is 3. The description adds some context about 'cite the handle, pass it back here' and the live-window behavior, but the core meaning — accepts full correlation id or short CWF handle — is already fully captured in the schema. No significant uncompensated gap.

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?

Opens with 'Fetch one signal by its id, when you already know which one you want' — a specific verb, resource, and access pattern. It explicitly contrasts with the other read tools that return bounded sets, so get_signal is clearly distinguished from get_latest_signals, search_signals, and get_related_signals.

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?

Explicitly says when to use this tool: when you already know the id and want exact re-read of one row. It names alternatives and gives routing rules: search_signals or scope_signals to find signals, get_related_signals to get signals about the same subject. It even explains why using other read tools for a single row is problematic (row budget re-query).

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?

With annotations already covering readOnlyHint and idempotentHint, the description adds a behavioral guarantee: exactly one SRC line is returned per source, along with the source fields. This goes beyond the annotations and gives the agent a useful expectation about the result format.

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 capture the action, the resource, the field set, and the return shape. There is no extraneous text, and the core behavior is front-loaded before any context about 'the wire' or 'SRC lines'.

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 listing tool with 0 required parameters and only one optional filter, the description is complete enough to call correctly. The only potential gap is that 'SRC line' and 'feeding the wire' are domain-specific and unexpanded, but plausible enough not to block correct invocation.

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 covers 100% of the parameter docs, including the signal_type filter, examples, and omit-all-sources behavior. The description's mention of signal_type is only as an output field, so it adds no meaningful semantic layer for the input schema beyond what is already there.

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-resource pair ('List the data-source endpoints') and enumerates the distinguishing fields: provider, signal type, country, cadence, and license. This clearly separates it from sibling tools such as get_signal or list_facets, which concern signal content and facets rather than source metadata.

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 makes it clear that this tool is for retrieving overall metadata about source endpoints, and it includes a note on the optional signal-type filter. It does not explicitly name alternatives or give when-not-to-use conditions, but the resource scope and output fields convey enough context for an agent to match an intent to this 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 already set readOnlyHint=true, and the description adds valuable behavioral context beyond that: it warns that the listing is exhaustive and can be a hundred-odd values, guarantees that every returned value is directly acceptable by scope_signals, and explains that place facets are gazetteer IDs with human-readable labels. This sets expectations for length and response content.

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 multi-sentence, but each sentence earns its place: purpose, guarantee of compatibility, length warning, routing to the alternative, and the place-ID caveat. It is front-loaded and free of tautology, making even the lengthy-warning meaningful rather than redundant.

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, read-only tool with no output schema, the description fully compensates: it states exactly what the response contains, how long it can be, how the tool fits into the wider API, and how to use the results with scope_signals. The agent has enough context to invoke the tool correctly and interpret its result confidently.

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 properties and no required fields, so there are no parameters to explain. The baseline for 0 params is 4, and the description rightly does not invent parameter guidance. It further mentions the output structure enough for the absence of parameters to be non-blocking.

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 opens with a specific verb and resource ('List the full filter vocabulary'), explicitly enumerates all covered keys, and describes the exact output shape (flat list with a signal count each, plus a human-readable label for place ids). It also distinguishes itself from get_facet_manifest by naming itself as the exhaustive listing, so an agent can tell them apart without looking at any schema.

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/when-not-to-use guidance: use get_facet_manifest when only a domain and topic are needed to save tokens, and list_facets when the manifest lacks a value or counts are needed. It also instructs how to handle place facets (filter by name via scope_signals, not by raw id), which preempts a likely error.

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?

With no annotations present, the description carries the full behavioral burden and handles it well. It discloses that the tool reads no signals, is stable even while the wire warms up, and is about catalogue existence rather than current availability. It also explains the 'published' versus 'composed' attribution distinction and the plan-gating 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 front-loaded with the core purpose and then adds only high-value details about sibling differentiation, output semantics, row attribution, and plan gating. Each sentence earns its place and is organized into clear, scannable paragraphs.

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 list tool with no output schema, the description is complete: it specifies what is listed, what each row contains, what the values mean, and how to interpret plan-related omissions. It also names the next tool to call when computation is actually needed.

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 there is no argument ambiguity to resolve. The word 'every' reinforces that the tool is unfiltered, and the schema coverage is trivially 100%. Baseline 4 is appropriate because no parameter semantics are needed.

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 opens with a specific verb and resource: 'List every derived intelligence product pronto can compute,' then lists the exact attributes returned. It also differentiates the tool from get_fused_signal, so the agent can distinguish the 'catalogue' tool from the 'compute current window' tool.

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 an explicit routing rule: read this list to discover whether a product exists, then call get_fused_signal to compute it. It also explains why the two tools answer different questions and warns that get_fused_signal's omissions reflect current inputs, not impossible products. Plan-gated rows and NOTE lines are also covered.

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 annotations, the description discloses the binding side effect, why the wallet is bound before payment, the public-transaction-hash risk, and the oracle acceptance rule that only transfers from the named wallet settle. This is substantive behavioral context the annotations do not cover.

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 well-structured and front-loaded with the core action, then prerequisites, then critical binding context, then return value and next step. The security rationale is relatively long but earns its place because it explains a non-obvious and consequential behavior.

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 covers prerequisites, parameter semantics, side effects, return value, and the follow-up call. Even without an output schema, the agent knows exactly what comes back and what to do next. No critical gap remains for this 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?

Schema description coverage is 100%, so the baseline is 3. The description adds real extra meaning for from_address: it explains why the wallet is bound now, what 'binding' means, and the settlement consequence. Plan and cycle are already fully described in the schema, so no more is needed.

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 opens with a specific action—'Buy a plan for yourself'—and sharpens it into the actual step-one behavior: 'quotes the exact amount and binds the purchase to the wallet you will pay from.' This clearly distinguishes open_payment from settle_payment and get_plans.

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 to call register_agent first for identity, get_plans for plan details, and settle_payment after transferring. It also clarifies the self-serve nature by saying 'no human involved' and sets up the exact order of operations.

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 mark this as non-read-only and non-idempotent; the description goes beyond them by disclosing that registration grants no plan, that limits match an unauthenticated caller, that the API key must be sent as an Authorization header, and the rotation/expiration consequence of omitting the Ed25519 public key. No annotation contradiction is present.

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 purpose is front-loaded and each paragraph covers a distinct concern: core identity/API key, plan/limit/billing options, and key-rotation tradeoffs. It is long but not bloated; slight repetition of the no-human theme costs it a perfect score.

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 still names the response elements (API key, claim code, URL), explains the auth header mechanics, states default limits, and lays out both plan-raising paths. An agent has enough to invoke register_agent and know what to do with the result.

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 adds meaningful param context for the public key by explaining why it matters—credential rotation without help and the forced re-registration if omitted—giving agents deeper understanding beyond the raw schema text.

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 action and outcome: 'Create your own identity on pronto and receive an API key'. It is clearly distinct from the sibling get_/list_/payment tools, and the registration purpose is unambiguous.

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 clarifies when to use this tool: when an identity/API key is needed without human involvement. It also provides post-registration branching guidance—get_plans/open_payment for self-funded plans, or sharing the claim code/URL for third-party coverage—and warns when re-registration is required, though it does not explicitly contrast register_agent with a direct alternative.

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 signal read-only, open-world, and idempotent behavior, and the description adds meaningful behavior beyond those: it explains OR-combination within a orig key and AND-across keys, and makes clear that the tool returns the entire slice regardless of words used by member reasing. It covers the key non-obvious semantics of the tool, though the lack of an output schema means some response-shape behavior is still implicit.

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 structure is well front-loaded: a direct verb-first sentence, then usage conditions, then operates behavior and a sample expression. It does repeat some schema content in the prose, so it is slightly longer than the ideal, but no sentence is false or 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?

For a read-only filter tool with complex filter grammer, the description covers when to use it, how to build filters, how it differs from search, and whet sort of slices are supported. The main gap is that hardware it has no output schema and the description does not say what the returned signal objects look like; given the open-world and read-only contexts, however, this doesn't prevent correct intonation.

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 schemas already describes filter thoroughly with grammar, OR/AND rules, examples, and a pointer to list_facets, and it covers limit, cursor, and relate as well. The description repeats the OR/AND explanation in more prose forma but does not add much parameter-level detail beyond the schema; a 3 is the safe baseline.

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 opening line says what the tool does: selects a slice of the signal feed by facet tags, and explicitly clarifies that matching is on structured metadata rather than words in text. It also names the sibling tool search_signals and distinguishes itself from it, so the agent can disambiguate even before reading the schemas.

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 explicitly describes the use case: call this when you can name a slice, and call search_signals when you have a subject word but no category to name. It gives concrete examples of shareable slices — severity, provider, language — and also excludes what a single locale filter can't do, which is duid to 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 mark it read-only, open-world, and idempotent, but the description adds substantial behavior beyond that: which fields are searched, inflection matching, the lack of synonym matching, minimum severity behavior, and the custom relevance ranking. It also does not contradict the provided 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?

Each paragraph has a single job: usage and alternative, field coverage, and matching/ranking behavior. The main action and decision rule are front-loaded, and the text is dense with useful detail and 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?

For a 5-parameter tool with no output schema, this description is unusually complete: it explains scope, matching algorithm, ranking behavior, and severity handling. It does not spell out the shape of the return object, but the parameter schema already covers limit/cursor details and the result can clearly be inferred as a list of matching signals.

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 100%, so the baseline is strong. The description still adds meaningful value by explaining what the query actually matches against, that matching is lexical and not semantic, and that inflection counts but synonyms do not. This helps the agent craft a better keyword and severity context beyond what each schema field alone states.

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 opens with a specific verb and resource: 'Find signals by the words in them', then elaborates with concrete subjects like a storm name, company, or printed phrase. It also directly distinguishes this tool from scope_signals, so an agent can choose between them from the description alone.

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 decision rule: use word-based search when a subject cannot be named as a category, and use scope_signals when it can name country, domain, or severity as a category. It also warns that ranked word-overlap search can miss differently phrased matches, which sets accurate expectations for when this tool should be chosen.

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 annotations, the description reveals concrete verification behavior: reading Base, checking the settlement address, wallet origin, amount, and block depth. It also explains the pending-error scenario and the idempotent reuse of the same hash, plus the success effect on the API key.

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 well structured and appropriately sized: a clear opening, a detailed verification/error paragraph, and a concise success outcome. Every sentence adds functional value without 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?

For a single-parameter tool with no output schema, the description covers the full invocation context: prerequisites, verification rules, retry behavior, and post-success state. An agent has enough information to call the tool correctly and interpret outcomes.

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 already fully documents transaction_hash with format details. The description adds the guidance to reuse the same hash on retry, but it does not need to explain the parameter further because schema coverage is 100%.

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 action: redeem a payment and activate your plan, and identifies its role as 'step two of two' after open_payment and the transfer. This clearly distinguishes it from the related open_payment sibling.

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 frames when to call the tool: after open_payment and the transfer. It also instructs what to do if the payment is real but not deep enough: call again with the same hash rather than paying twice. This is strong practical usage guidance.

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