pronto-stream

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

With no annotations provided, the description carries full burden. It details the return structure including CWF BILL, CREDIT, and NOTE lines, and explains what happens when the caller is unauthenticated or unclaimed. It does not explicitly state read-only behavior, but the content implies data retrieval without side effects.

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 long, front-loading the core purpose and then listing the return fields and edge cases. The first sentence is dense but efficiently packs many specifics. Minimal waste, though breaking into shorter sentences could improve readability.

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 no annotations, the description thoroughly covers what the tool returns: identity, account, plan, limits, and special lines for billing, credit, and error states. It addresses conditions like unauthenticated or unclaimed accounts, making it fully self-contained for an agent to understand the tool's output.

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 coverage is 100% (trivially). The description adds no parameter information because none is needed. This is appropriate for a parameterless call, earning a baseline of 4.

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 reports the resolved agent identity, associated funded account, plan details, and usage limits. It uses specific verb 'Report' and resource 'billing profile', and distinguishes itself from siblings like get_plans or get_signal by focusing on the caller's own billing 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?

No guidance on when to use this tool versus alternatives such as get_plans or get_signal. There are no explicit conditions, prerequisites, or exclusions mentioned. The description explains what the tool returns but omits any decision-making context.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool covers only two facet keys, truncates the topic tail, and returns structure, not signal content. It does not mention return format or error behavior, but given the tool's simplicity (no parameters, read-only), the disclosed traits are sufficient.

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 four sentences long, each earning its place. It front-loads the purpose, then provides usage guidance, then clarifies limitations. While dense, it could be slightly more concise by combining the first and second sentences, but overall it is well-structured and efficient.

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 has no parameters, no output schema, and no annotations, the description is quite complete. It explains the output, the intended usage workflow, and limitations. It lacks only minor details like error handling or idempotency, but for a simple read tool, this is adequate.

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 schema is trivially covered. The description compensates by explaining the output structure and usage context, adding value beyond the empty schema. It explains what the two-level tree contains and how to interpret it, which is more than 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 clearly states the tool returns a 'two-level tree of domain and the topics under it, each with a signal count, ranked so the busiest lead.' It specifies the two facet keys covered and contrasts with sibling tools like list_facets, which covers other vocabularies. The verb 'read' and resource 'shape of the wire' make the purpose unmistakable.

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?

Explicit guidance: 'This is the map to read first' — read once, choose scope offline, then call scope_signals or search_signals. Also states when to use list_facets instead for exhaustive vocabulary. This fully differentiates from alternatives and provides a clear workflow.

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 provided, the description fully carries the transparency burden. It excels by disclosing that source rows label missing citations, macro products disagree on purpose (read both), cross-source products exist due to timing alignment, and commercial indicators are plan-restricted. It even explains that withheld results are noted, preventing misinterpretation.

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 verbose and could be more concise. It front-loads the purpose well with the first sentence, but the subsequent detailed lists of products and plan restrictions, while valuable, make the description longer than necessary. Some consolidation would improve structure without losing informational 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?

Given the complexity of the tool (derived intelligence products) and that no output schema is provided, the description covers return value behavior (method used, source signals, missing citations) and plan restrictions comprehensively. It provides enough context for an agent to decide and invoke effectively, though a brief note on pagination or retrieval limits would enhance completeness.

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% and the description adds significant meaning to the 'product' parameter by listing all 27 valid values in detail (space_weather_ops, recession_risk_12m, etc.), which the schema's enum list would supplement. It clarifies that omitting the parameter returns all products, enhancing understanding. However, it doesn't explain the significance of each product choice beyond names, leaving minor gaps.

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 specifies a clear verb 'compute' and resource 'derived intelligence products from the live wire', differentiating it from siblings like get_latest_signals, get_signal, and search_signals. It explicitly states what the tool does and provides a comprehensive list of product categories, making purpose unmistakable.

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 clearly explains when to use this tool (to get derived intelligence products) and provides context about plan limitations, noting macro/energy models require Team plan. However, it doesn't explicitly contrast with sibling tools like get_related_signals or list_fusion_products, leaving some ambiguity about when to choose this over 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?

Annotations are absent, so the description carries the full burden. It discloses the CWF format and token-efficiency, but does not state that the operation is read-only, describe response size limits, or mention any rate limiting. Adequate but not rich.

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, well-front-loaded sentence with no redundant words. Every element (action, resource, format, optional filter) 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 fetcher with three optional parameters and no output schema, the description provides the essential context. It lacks explanation of the 'CWF' acronym and explicit read-only behavior, but the combination of schema and description is mostly 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 100% with good descriptions for all three parameters. The description adds value by explaining the output format (CWF) and overall efficiency, which the schema does not cover. This elevates the score above the baseline of 3.

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 'Fetch', the resource 'most recent live signals', the format 'token-efficient CWF', and an optional filter. It distinguishes from siblings like get_signal (single signal) and search_signals (search vs. latest).

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 implies real-time usage ('from the wire') and token efficiency, but does not explicitly contrast with alternatives like get_related_signals or search_signals. No when-not-to-use guidance is provided.

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 provided, the description fully carries the behavioral transparency burden. It describes the return format ('one CWF PLAN line per plan') and the data fields included (cost, call ceiling, row budget, commercial indicator). There is no mention of side effects, authentication, or rate limits, but as a read-only list operation, the description is adequately transparent about what the tool does.

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 concise (three sentences) and front-loaded with the primary purpose. Every sentence adds value: the first states the action and output, the second provides usage context, and the third clarifies the return format. 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 has no parameters, no output schema, and no annotations, the description is mostly complete. It specifies the key fields returned and the use case. However, it could be more explicit about the exact output structure (e.g., JSON array or tabular format) to fully compensate for the missing output schema. The phrase 'one CWF PLAN line per plan' is helpful but slightly ambiguous.

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 (no parameters), so schema description coverage is 100%. The description adds no parameter information because there are none. However, for a tool with zero parameters, a baseline of 4 is appropriate as the description adds meaning about the output and usage, which is valuable 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?

The description clearly states the tool lists plans and specifies what each plan includes: cost, call ceiling, row budget, and commercial indicator. The verb 'List' combined with resource 'plans' is unambiguous. Among sibling tools, this is the only one focused on plans, so it is well-distinguished.

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 a clear use case: 'decide whether a refusal is worth escalating to your principal instead of parsing a pricing page.' This implies when to use the tool. However, it does not explicitly state when not to use it or name alternative tools, though the context of sibling tools suggests no direct overlap.

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 provided, the description carries the full burden of behavioral disclosure. It explains the tool follows link types (echo, related, cross-domain) and provides an example. However, it does not disclose key behavioral traits such as whether the operation is read-only, error handling for invalid correlation_id, rate limits, or authentication requirements. The description adds value but is incomplete for a transparent specification.

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 paragraph that efficiently conveys the core purpose and link types. It front-loads the main action and includes a concrete example. It could be slightly more structured (e.g., listing link types separately) but remains focused and avoids unnecessary detail. One sentence could be removed without losing key 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?

Given the absence of an output schema, the description should explain the return format more thoroughly. It mentions that each link states the reason, but does not specify the structure (e.g., array of objects, fields), pagination, or how the limit parameter affects results. The example is illustrative but does not fully compensate for missing output details. The description is adequate but has room for improvement.

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% with both parameters clearly described. The description adds context about link types and the relationship model, which enriches the overall understanding but does not significantly enhance the meaning of the individual parameters beyond what the schema already provides. The baseline score of 3 is appropriate as the description does not harm but also does not add substantial param-specific value.

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 follows a link graph from one signal to related signals about the same subject. It distinguishes itself from sibling tools like get_signal (single signal) and search_signals (keyword search) by focusing on relationship traversal. The specific verb 'follow' and resource 'link graph' are precise, and the example of seismic record and news headline concretely illustrates the purpose.

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 implies when to use (exploring connections between signals) but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it (e.g., for direct signal lookup or keyword search) and does not mention prerequisites or context. The example helps but does not replace clear usage boundaries.

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 important behavioral traits beyond what annotations could provide (none given). It explains why this tool is more efficient than re-running a query, mentions that the live window turns over in about two minutes and signals may age out, and notes that the error message distinguishes between a typo and a stale read.

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 purpose in the first sentence. Every sentence adds value—efficiency explanation, parameter format, timeout caveat, and sibling differentiation. It could be slightly tighter (e.g., 're-running a query and hoping the row survives' is slightly verbose) but earns a 4 for clarity and content density.

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 (1 parameter, no output schema), the description is complete. It covers purpose, usage context, parameter semantics, behavioral caveats (timeout, error messages), and how it differs from siblings. There are no gaps given the tool's complexity and the provided context 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?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining what the parameter does beyond the schema: it 'Takes either the full correlation id or the short handle in column 2 of any CWF row' and instructs the agent to 'cite the handle, pass it back here.' This provides practical usage guidance not present in 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?

The description clearly states 'Fetch one signal by its id, when you already know which one you want.' It uses a specific verb (Fetch) and resource (signal by id), and distinguishes itself from siblings like search_signals and get_related_signals by emphasizing that it returns exactly one row.

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 says when to use this tool ('when you already know which one you want') and when not to use it, contrasting with other read tools that 'return a set and bounds it.' It also names specific alternatives: 'To find signals rather than re-read one, use search_signals or scope_signals; to reach the ones about the same subject, use get_related_signals.'

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output format ('one SRC line per source') and lists returned fields, which implies a read-only listing. However, it does not explicitly declare that the operation is read-only, nor does it describe any side effects, rate limits, or authentication needs. This is adequate for a simple list tool but not enriched beyond the minimum.

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 long, each carrying essential information. The first sentence defines the purpose and output fields; the second clarifies the return format. There is no redundancy, fluff, or extraneous detail. Information is front-loaded with the verb and resource.

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 low complexity (one optional parameter, no output schema, no annotations), the description covers core functionality well. It explains what is returned and the optional filter. However, it does not clarify what an 'SRC line' entails beyond the listed fields, nor does it mention whether the list is paginated or complete. Slight ambiguity in the return format prevents a perfect score.

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 provides a complete description for the single optional parameter signal_type ('Filter by signal type, e.g. climate, security, health. Omit for all sources.'). The tool description does not add any additional semantic context or formatting rules for this parameter. Since schema coverage is 100%, a baseline of 3 is appropriate, and the description offers no extra value on parameters.

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 action ('List') and the resource ('data-source endpoints feeding the wire'), then enumerates the fields returned (provider, signal type, country, cadence, license). This verb+resource combination distinguishes the tool from siblings like list_facets, get_signal, and search_signals, which operate on different entities.

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?

No explicit guidance is given about when to use this tool versus alternatives, such as search_signals or get_signal. There is no mention of prerequisites, typical use cases, or situations where filtering by signal_type is beneficial. The purpose implies a general listing use, but the lack of when/when-not context leaves the agent without decision support.

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?

Discloses that the output is a flat list with signal counts, includes human-readable labels for place ids, and that all returned values are valid for scope_signals. Also notes the listing is exhaustive and can be long. No annotations exist, so the description carries the burden; it is mostly transparent, but could explicitly state that the tool is read-only.

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 paragraphs, front-loaded with the primary action. Every sentence adds value: purpose, scope, comparative guidance, and a specific note on place facets. 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 no parameters, no output schema, and no annotations, the description provides all necessary context: what is returned, size, relationship to sibling tools, and how to use place facets. It is complete for an agent to select and invoke the tool 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 zero parameters, so schema coverage is 100%. The description does not need to explain parameters, but it adds value by describing the output structure and behavior. Following the baseline of 4 for zero-parameter tools.

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 the full filter vocabulary across all keys, with a specific verb 'list' and resource 'full filter vocabulary'. It distinguishes from sibling get_facet_manifest by noting that the manifest is a subset for domain and topic, and that this tool is exhaustive.

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 provides when to use this tool vs. get_facet_manifest: 'come here when you need a value the manifest does not carry, or the counts behind one' and advises on place facets to use scope_signals for filtering by name rather than raw id.

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 provided, the description fully discloses behavior: it reads no signals, returns the same answer regardless of state, and explains attribution types (published vs composed) and plan gating (with NOTE lines for gated products). This is thorough and leaves no ambiguity about the tool's side effects or limitations.

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, starting with the primary purpose, then contrasting with the sibling, then detailing attribution and plan gating. Every sentence adds value and none are superfluous. It is front-loaded with the most critical 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?

Given the tool has no parameters and no output schema, the description is remarkably complete. It covers what the tool lists, how to use it in conjunction with the sibling, behavioral invariants, and nuanced details about attribution and plan restrictions. An agent can confidently select and invoke this tool based solely on this description.

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, so schema coverage is 100% and baseline is 4. The description adds no parameter-level details since none exist, but it explains the tool's output structure (rows with attribution and plan notes), which gives context beyond the empty schema and helps the agent understand what the tool returns.

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 every derived intelligence product pronto can compute, including details about the published index or model, signal collections consumed, and whether a plan is needed. It explicitly distinguishes itself from the sibling tool get_fused_signal by stating the different questions they answer.

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 explicit guidance: read this to check if pronto computes a needed product, then call get_fused_signal to compute it. It further clarifies that a product missing from get_fused_signal's output indicates inputs are not currently flowing, not that the product doesn't exist. This clearly differentiates when to use each 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?

Despite no annotations, the description is remarkably transparent: it explains registration is free but grants no plan, limits are what an unauthenticated caller has, response includes a claim code/URL for budget holders, and the public_key parameter enables credential rotation. It also warns that without a public key, the credential cannot be rotated and the user must re-register upon expiry. This is comprehensive for a tool with no 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 well-structured in three concise paragraphs: first the core purpose, then the plan/limits explanation, then the public_key details. Every sentence adds meaningful information without redundancy. It is front-loaded with the most critical 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?

Given the moderate complexity (two optional parameters, no output schema, advanced authentication concept), the description is complete. It explains the authentication flow, plan limitations, claim process, and key rotation. There is no missing context that would leave an agent uncertain about how to use 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 coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the public_key's purpose and consequences (rotation ability vs. re-registration), which goes beyond the schema's bare description. However, it doesn't add much to 'label' beyond what the schema says.

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 that this tool creates an identity and returns an API key. It distinguishes itself from siblings by focusing on authentication and registration, which no other sibling tool does. The mention of 'with no human present' adds precision about the automated nature.

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 explicit when-to-use guidance: use for initial registration or when credential rotation is needed. It also clarifies when not to rely on it alone—by explaining the limitations post-registration (no plan, same limits as unauthenticated) and the need for a funded account to claim the identity. The public_key parameter is explained as optional but with a clear trade-off regarding rotation ability.

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, the description fully discloses key behaviors: facet combination (AND/OR logic), return of the whole slice irrespective of text matching, and the optional relate parameter for link graphs. It also clarifies limitations like 'a locale filter alone cannot answer this question', giving the agent rich 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?

Well-structured with a front-loaded purpose sentence, followed by usage guidance and syntax. It is slightly verbose for a simple tool but every sentence adds value; no wasted words. Could be tighter but still effective for an AI agent.

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?

Explains filter syntax, relate behavior, and the distinction from search, but lacks a clear description of the output structure (e.g., the shape of returned signals) since no output schema exists. This gap reduces completeness for a tool with three parameters.

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 baseline is 3. The description adds little beyond the schema: it repeats the relate explanation verbatim from the schema and illustrates filter syntax with an example, but does not provide new meaning for limit or deeper constraints.

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?

Description clearly states the tool selects a slice of live wire by facet tags, using specific verbs and resources. It immediately distinguishes itself from search_signals by contrasting facet-based selection with word-based search, providing a clear identity.

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 to use this when you can name a slice and to use search_signals when you have a subject word but no category. However, it only compares to one sibling and does not address other relevant tools like get_latest_signals or get_signal.

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, the description fully discloses behavioral traits: coverage of fields (places, observations, summaries, etc.), inflection handling ('flood' reaches 'flooding'), lack of synonym support, ranking by word overlap, exact phrase priority, and error on no match. This is thorough and transparent beyond basic read-only assumptions.

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 purpose and usage, followed by detailed behavioral explanations. It is well-structured in paragraphs but somewhat lengthy. Every sentence adds valuable information, but minor redundancy exists (e.g., restating lexical matching). Still, it is efficient for the complexity covered.

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 partially compensates by noting 'Returns CWF lines' but fails to explain what 'CWF' means or the structure of returned signals. Missing details about output format and pagination behavior force the agent to guess or seek external context. While other aspects are thorough, this gap affects completeness.

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%, providing clear descriptions for both 'query' and 'limit'. The description adds significant context about how the query is interpreted (inflection, no synonyms, ranking), enhancing understanding beyond the schema. However, the 'limit' parameter is already well-described in the schema, and the description adds little new for it, making the improvement moderate.

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 'Find signals by the words in them' and immediately distinguishes this tool from its sibling 'scope_signals' by specifying when to use each ('when you cannot name it as a category' vs. 'when you can'), fulfilling the criteria of specific verb-resource and sibling differentiation.

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?

Provides explicit usage guidance: 'Use this when you are looking for a subject... and cannot name it as a category' and contrasts with 'scope_signals' for exact category matches. It also explains limitations (word overlap, missing differently phrased signals) and error handling for empty results, giving comprehensive when-to and when-not-to information.

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