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 says 'check' (a read operation) but does not disclose whether this requires authentication, what the return format is, or whether transactions are paginated.

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 efficient sentence that front-loads the primary action (balance check) and appends the optional capability. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one well-documented parameter and no output schema, the description is adequate. However, with no annotations, it should at least state the read-only nature and possibly the return basics to be fully 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%, so the single parameter 'includeTransactions' is fully documented in the schema. The description mirrors this ('optionally view recent transactions') but adds no syntax or format details beyond what the schema provides.

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

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

States a specific verb and resource: 'Check current credit balance' with an optional transaction view. Distinguishable from siblings like 'usage' and 'research', though no explicit sibling differentiation is given.

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 like 'usage'. The description implies a read context but provides no explicit conditions or exclusions.

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 full behavioral burden. It mentions the same-thread constraint but does not disclose that this likely spawns a new (cost-bearing) job, whether the call is synchronous or returns a job ID to poll, or what authorization/cost implications the budgetTier carries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight sentence with the action and its two modes front-loaded; no wasted words. It could be slightly more explicit about the completed-job precondition, but there is no padding.

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 four-parameter tool with no annotations and no output schema, the description leaves meaningful gaps: it does not explain what the call returns (job handle?), whether the follow-up runs asynchronously, or how it relates to `research_status`/`get_results`. Adequate but not 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 description coverage is 100%, so the schema already documents all four parameters, including the topicIndex/customQuery precedence rule. The description adds only the 'same thread' framing and confirms the suggestions-vs-custom duality, which is a marginal increment over the schema.

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

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

States a specific verb (pursue/ask) and resource (a follow-on research question from a completed job, in the same thread). It distinguishes itself from the sibling `research` by tying the action to a completed job's suggestions or an existing thread, so an agent can tell them apart.

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 the precondition (a completed job that generated suggestions) and offers two modes — pursuing a suggested topic versus asking a custom question. However, it never states explicitly when to use this instead of `research` or what state the parent job must be in beyond 'completed'.

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 carries the full behavioral burden and does partially meet it by describing what is returned (sources, URLs, snippets, history). However it omits permissions, error/not-found behavior, and pagination or size limits. It also implies history is always included while the schema's includeHistory defaults to false, a tension an agent could be misled by.

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 front-loaded sentence that names the resource first and then the payload. It is efficient, though the trailing clause chain is slightly dense.

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 usefully enumerates the returned fields, which is the main thing an agent needs. It falls short only on the includeHistory default nuance and absence of any error or limit behavior.

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 both parameters are already documented in the schema, making the 3 baseline appropriate. The description's phrase 'history of events' loosely maps to includeHistory but adds no format or scope detail beyond the schema.

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

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

States a specific verb+resource ('Get the full evidence chain for a specific claim') and enumerates the returned content (sources, URLs, snippets, event history). It is clearly distinguishable from generic siblings like search_claims, though it never names an alternative explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer search_claims or get_results instead. Usage is left entirely to inference from the tool name.

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 carries the behavioral burden and does so well for return content: it names the unified report, inline [src_N] citations, sourceRegistry, follow-on suggestions, and cost breakdown. It also explains the includeClaimsJson parameter effect, though it omits auth, error, and readiness behaviors.

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 tightly written sentences with no filler. The core purpose and return shape are front-loaded, followed by the optional parameter hint.

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 and annotations, the description compensates by explaining the main return payload and its components. It gives enough context for an agent to understand what will come back from a completed job.

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 mentions includeClaimsJson but only reiterates a subset of what the schema already documents and says nothing about includeProviderReports.

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

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

The description states a specific verb (Get) and resource (synthesized results of a completed research job), clearly scoping it to the post-completion retrieval phase. It differentiates from siblings like research and research_status by output type and job state, though it does not explicitly name those alternatives.

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

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

Usage is implied by 'completed research job,' but the description does not explicitly say when to use this tool versus research_status, follow_up, or search_claims. It provides no exclusions, prerequisites, or alternative 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?

No annotations are provided, so the description carries the full burden. It does usefully disclose the return contents (messages, jobs, results), which is meaningful given the absence of an output schema, but 'Get' only weakly implies read-only behavior and nothing is said about permissions, missing-thread errors, or response size.

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?

One sentence, zero filler, and the resource being fetched is front-loaded along with the payload it contains. Nothing could be removed without losing 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?

For a one-parameter read tool with no output schema, the description compensates by enumerating the returned contents, which is the main thing the schema cannot convey. The remaining gap is the total absence of annotation-equivalent detail (safety, error behavior) that a no-annotation tool would ideally mention.

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 is a single parameter with 100% schema description coverage, so the schema already documents threadId. The description adds no syntax, format, or sourcing detail beyond what is structured, making the baseline 3 correct.

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

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

States a clear verb+resource ('Get a specific research thread') and enumerates the nested payload (messages, jobs, results), so the agent knows exactly what it receives. It implicitly distinguishes itself from the sibling 'list_threads', but never names an alternative explicitly, so it stops short of a 5.

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

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

Usage is only implied: the required threadId makes clear this is the 'I already have an ID, fetch that one thread' path versus 'list_threads'. There is no explicit when-to-use guidance, no mention of prerequisites, and no comparison against siblings like get_results or research_status.

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 and no output schema, the description carries the full disclosure burden. It does disclose the categories of returned data (providers, models, capabilities, tier defaults), which is genuinely useful behavior context, but it says nothing about whether the call is read-only, whether it needs auth, or whether the list is cached/static.

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 front-loaded sentence that names the resource first and then the returned content, with no filler or restated title boilerplate. Every clause 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 zero-required-parameter, read-only listing tool with no output schema, the description adequately conveys what comes back and how budgetTier narrows it. It lacks only a note on when the tool is worth calling versus the other research family tools, which is a minor gap given the tool's simplicity.

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% and the single budgetTier parameter already has an enum and its own description ('If provided, show only the defaults for this tier'). The description corroborates the tier-scoping semantics ('default provider assignments per budget tier') but adds no syntax or behavior beyond the schema, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('List available research providers') and additionally enumerates what the listing contains (models, capabilities, default provider assignments per budget tier). This is far more specific than the title alone, though it never distinguishes itself from sibling discovery tools like research or usage.

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 when-to-use, prerequisites, or named alternatives are given, so guidance is only implied — the mention of 'default provider assignments per budget tier' hints that this is a discovery/metadata call made before configuring a research request. An agent can infer intent but is not told when to prefer this over, say, research_status.

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 carries the full behavioral burden and mostly fails it. 'Recent' is undefined (no time window or ordering), and it says nothing about pagination behavior, default page size, or result ordering, even though offset/limit imply paging.

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 short sentence that is front-loaded with the verb+resource and contains no filler. Its brevity is appropriate for a simple list operation, though it leaves important detail unstated.

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?

There is no output schema, so the description should say what a thread record contains or how to obtain further detail, and it does not. Combined with the undefined 'recent' window, the definition is only minimally sufficient for calling 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?

Schema description coverage is 100%, and the schema documents both limit (max 100, default 20) and offset, so the baseline of 3 applies. The description adds no meaning beyond the schema — 'recent' arguably relates to ordering but is never tied to any parameter.

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

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

States a specific verb and resource ('List recent research threads') and scopes it to the authenticated user, which cleanly separates it from the singular sibling get_thread. It does not, however, explicitly name how it differs from siblings like research or research_status.

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 no when-to-use guidance, no prerequisites, and never mentions the obvious alternative get_thread for fetching a single thread's details. An agent must infer the routing decision entirely from the name.

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 carries the full burden, and it discloses the key side effect (always creates a new thread) plus the multi-provider fan-out and synthesis behavior. It does not mention latency or cost implications in the description, though the schema covers those for mode and budgetTier.

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?

Four tight sentences, front-loaded with the action and the routing rule, then the behavior. Nothing is redundant, though the final sentence on synthesis is somewhat expansive relative to its 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?

With no output schema and no annotations, the description does describe the return shape ('unified report with cross-referenced citations and conflict resolution') and the thread-creation side effect. It is largely complete, with only auth/rate-limit style details left unaddressed.

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%, with mode, providers, and budgetTier each documented in the schema itself, so the baseline is 3. The description adds no parameter meaning beyond what the structured schema already 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?

States a specific verb and resource ('Submit a deep research query') and immediately distinguishes itself from the sibling follow_up tool. An agent can tell this is the entry point for new research without opening 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?

Explicitly names the alternative ('To follow up on existing research, use the follow_up tool instead') along with the condition that selects it. It also flags the always-new-thread behavior, which is exactly the routing information an agent needs.

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 carries the full behavioral burden, and it does disclose the response shape (per-provider progress plus overall status). However it omits relevant traits for a status tool: whether the call is read-only, polling/rate-limit expectations, and whether jobs can reach terminal or failed states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with zero waste; the purpose is front-loaded and the return contents follow immediately. Nothing redundant or padded.

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 status tool with no output schema, the description covers what the tool does and roughly what it returns, which is enough to call it correctly. Minor gaps remain around polling behavior and terminal states that an agent managing an async job would benefit from.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents jobId (including its origin from the research tool). The description adds no syntax, format, or validation detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb+resource ('check the status of a research job') and clarifies output scope ('progress for each provider and overall job status'). It is distinguishable from siblings like research and get_results, but never names them explicitly, so it stops short of a 5.

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

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

Usage is only implied: the 'job ID returned by the research tool' phrasing subtly ties it to a prior research call, suggesting a poll-after-submit workflow. No explicit when-to-use, when-not, or guidance about transitioning to get_results once complete, so it stays at the minimum-viable level.

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 behavioral burden. It does not state that this is a read-only operation, how results are paginated or ordered, what happens when no filter is supplied, or the default/limit behavior (limit defaults to 20, max 100 per schema but unexplained).

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 front-loaded sentence with no filler, listing the available modes compactly. Slightly under-specified rather than verbose, but nothing is wasted.

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 annotations and no output schema, the description covers the main search axes but omits pagination, default behavior, filter-combination rules, and return shape. Adequate as a minimum viable definition but with clear gaps.

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 all five parameters are already documented in the schema, which sets the baseline at 3. The description maps loosely onto query, confidenceLevel, and threadId but adds no format, combination, or ordering semantics beyond what the schema 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?

States a specific verb and resource ('Search for claims') plus the scope ('across research jobs'). It distinguishes the three search modes but does not differentiate itself from siblings like get_claim_evidence or get_results, which an agent could easily confuse with a claims-search 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 three modes imply usage ('search by text content, filter by confidence level, or list all claims for a thread'), so an agent can infer intent from each mode. However, there is no explicit when-to-use guidance, no statement about combining filters, and no routing to the alternative claim/evidence tools.

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

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

No annotations are provided, so the description carries the full burden; it does disclose what the response contains (spend, job count, average cost), implying a read-only analytics operation. However, it says nothing about permissions, rate limits, or how the period scoping affects results, which is thin for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single efficient sentence that front-loads the verb and lists the payload without padding. It is appropriately sized for a one-parameter read tool, though it could trade a few words for usage routing.

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-optional-parameter read tool with no output schema, the metric enumeration is reasonably complete. It still omits when to prefer this over sibling cost tools and how the 'all' period behaves, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has full description coverage for the single 'period' parameter including its enum and default, so the schema does the heavy lifting. The description adds no period syntax or scoping detail beyond the schema, making the baseline 3 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?

States a specific verb (Get) and resource (usage analytics) and enumerates the concrete metrics returned: spend by provider, job count, average cost per query. It is distinguishable from siblings like balance, though it never explicitly contrasts itself with them.

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

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

No guidance on when to use this versus the related cost/account tools (balance, list_providers), and no mention of prerequisites or the default 30d period. The context is only implied by the word 'usage'.

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