Unquant

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

Annotations declare openWorldHint=true, idempotentHint=true, destructiveHint=false, readOnlyHint=false. The description adds that it's 'human-reviewed' and that the result 'contains a confirmation link' — useful context suggesting async/offline processing. However, it doesn't disclose the human-review delay, that it's non-reversible once requested, or any rate limiting. Given the annotations carry a moderate load, the added 'human-reviewed + confirmation link' context earns a 3.

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, no fluff. The first sentence delivers the primary purpose and key constraint ('human-reviewed', 'after Unquant delivers useful work'), and the second states the return value. Efficient and front-loaded, though slightly terse given the openWorldHint semantics that might merit more guidance.

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?

Has an output schema (confirmation link), full schema param coverage, and clear contextual gating. The description is complete for a request-submission tool: it states the action, the return artifact, and the timing precondition. A more explicit note about human-review latency could help, but this is reasonably complete for its complexity.

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% — all three parameters (request_summary, value_summary, next_step_summary) have descriptions in the input schema. The description adds the 'after useful work' semantic tying value_summary to a prerequisite, which is extra context. Baselines at 3 with full schema coverage, and the description provides marginal added meaning about the value_summary's role in the upgrade flow.

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?

Clear verb+resource: 'Create a human-reviewed Agent Pro request'. Distinguishes from siblings (all other catalog/market/news/data tools are read/list operations). It clearly states the action and the condition ('after Unquant delivers useful work'). Minor gap: doesn't explicitly differentiate from account_upgrade_status sibling, but the purpose is reasonably distinct.

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?

States a clear condition for use: 'after Unquant delivers useful work'. The description communicates the timing/context well. Doesn't explicitly say when NOT to use it or name alternatives, but the 'after useful work' gate provides clear usage context distinguishing it from status-checking (account_upgrade_status). Could be stronger with explicit 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?

Annotations provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description clarifies that the result is scoped to 'Agent Pro' requests specifically, which narrows the tool's domain beyond what annotations state. Given strong annotation coverage, the description adds reasonable additional context about the tool's scoped domain.

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 focused sentence that states the tool's function, source domain (Agent Pro), and required input (upgrade identifier). Zero wasted words and perfectly front-loaded with the key action 'Return the current state.'

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?

This is a simple 1-parameter, read-only, idempotent status-check tool with a full schema, output schema, and comprehensive annotations. The description covers the tool's purpose and scoping adequately. It could name the sibling request tool inline for clarity, but the schema already references account_request_upgrade as the identifier source, and a status tool at this complexity doesn't need extensive behavioral disclosure.

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 single parameter upgrade_id is well-documented in the schema ('The upgrade identifier from account_request_upgrade'). The description adds that the status is queried 'by upgrade identifier,' reinforcing the parameter's purpose but not adding new semantic detail beyond the schema already provides. Baseline 3 is appropriate.

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

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

The description states it returns the current state of an Agent Pro request by upgrade identifier. It has a clear verb (return) and resource (state of an Agent Pro request), but it doesn't differentiate from siblings like account_request_upgrade, which is its direct counterpart. The purpose is reasonably clear for a status-check 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 implies it's used to check the status of a previously made upgrade request ('by upgrade identifier'), referencing account_request_upgrade as the source of the identifier. This indirectly connects to the request tool but doesn't explicitly state when to use it vs. alternatives or what conditions warrant checking 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe-read profile is covered. The description adds useful context about what is returned (purpose, access state, inputs, next action), which is behaviorally informative. Annotations carry much of the safety burden, and the description complements them well.

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, compact sentence that front-loads the core purpose and lists the key return fields. Zero filler, every clause earns its place. The output is immediately scannable.

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 is simple: one parameter, read-only, single-entry scope. The description covers what it returns and the schema covers the ID. An output schema exists, so return-value explanation is unnecessary. Minor gap: no explicit mention of error behavior for invalid/nonexistent entry IDs, but this is a minimal omission for such a simple 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% with a single required parameter. The schema itself describes entry_id as 'the catalog entry identifier from catalog.list or catalog.describe', which is self-documenting. The description confirms the tool operates on 'one catalog entry,' reinforcing the singularity. With a single fully-documented parameter, baseline is high.

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+resource ('Return the purpose, access state, inputs, and next action for one catalog entry'). It distinguishes from siblings like catalog_list (listing all entries) and catalog_request/catalog_preview (different actions on a catalog entry). However, it doesn't explicitly contrast with these siblings, so it doesn't reach 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?

The description implies use case: to get details about a single catalog entry. The parameter doc points to catalog.list or catalog.describe as sources for the ID, which provides some contextual guidance. But there's no explicit statement of when to use this vs catalog_list/catalog_preview/catalog_request, and no exclusions for alternative tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is well covered. The description adds the filtering scope (job, theme, item type, status, geography) and the fact that it lists multiple item categories (data, signals, tools, workflows). This contextual value goes beyond what annotations provide. However, it doesn't describe pagination behavior or return format, though the output schema exists.

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, zero waste. First sentence states what's listed, second sentence states the filtering dimensions. Efficiently front-loaded with the core purpose.

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 filtered-list tool with an output schema, the description covers the essential purpose and all filter dimensions. With readOnly and idempotent annotations, plus an output schema, the description satisfies most needs. Minor gap: no explicit mention of pagination (cursor/limit) but these are schema-documented. It's reasonably complete for this tool type.

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 low at 13%, so the description should compensate. The description names the filtering dimensions (agent job, theme, item type, status, geography) which maps to job_id, theme, item_type, status, geo_archetype parameters. However, it doesn't explain semantics like exact-match requirement for filter values or the query text-matching behavior beyond what partial schema text hints at. It adds baseline value but not rich detail.

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 it lists data, signals, tools, and workflows with clear filterable dimensions (agent job, theme, item type, status, geography). It clearly identifies the resource (catalog) and the action (list/browse). However, it doesn't explicitly contrast with sibling tools like catalog_describe or catalog_preview, though the verb 'list' implies browsing vs describing.

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 mentions filtering capabilities which implies when this is useful (browsing by filters), but it doesn't explicitly state when NOT to use it versus alternatives like catalog_describe (for single-item detail) or catalog_request (for requesting items). The heavy overlap with catalog_describe and catalog_preview among siblings isn't clarified.

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 provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, which set a clear safety profile. The description adds that it returns a 'labeled preview' and supports 'optional symbols, dates, and filters,' which is some extra context. However, no info about error behavior, page size, or what happens with invalid entry IDs. With annotations covering safety, a mid score is appropriate.

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?

Single sentence, concise, front-loaded with the primary purpose. Every word earns its place, though the trailing 'optional symbols, dates, and filters' could be seen as slightly vague. No wasted prose or redundant restating of the title.

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 an output schema present, so return values don't need full description. The complexity is moderate (2 params, one nested inputs object). The description covers the essentials but leaves the 'inputs' format and behavior of 'symbols/dates/filters' unclear, and given the open-ended inputs param, more detail on expected structure would improve 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 50%, with only entry_id documented in the schema (from catalog.list or catalog.describe). The description adds 'symbols, dates, and filters' which hints at the inputs parameter meaning but doesn't specify format, key names, or semantics. The inputs param is an open additionalProperties object with no schema-level detail, so the description partially compensates but leaves significant ambiguity.

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 'Return a labeled preview for one catalog entry with optional symbols, dates, and filters.' This uses a specific verb (return preview) with a resource (catalog entry) and mentions optional modifiers (symbols, dates, filters). It's clear enough, though it doesn't explicitly differentiate itself from siblings like catalog_describe, which could be ambiguous.

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

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

No guidance on when to use this vs catalog_describe, catalog_list, or catalog_request. The 'preview' concept implies a lightweight look before a request/upgrade, but this isn't stated. The entry_id description references 'from catalog.list or catalog.describe' which implies a prerequisite, but the main description gives no usage context 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?

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description's phrase 'Save demand' indicates this creates a persistent record (a write operation), which aligns with readOnlyHint=false. However, the description doesn't disclose whether this initiates an actual access-request workflow, what happens after submission, or any auth/prerequisite requirements. With annotations carrying the safety profile, the marginal value added by the description is modest.

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 concise sentence that conveys context (post-preview) and key semantics (save demand, user goal, preview action). No wasted words. It's appropriately brief, though it could front-load more of the 'what it does' nature slightly better.

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 7 parameters with only 43% schema description coverage, and it's a write/mutation operation. The description is quite thin for a tool with this complexity. There's an output schema, which reduces the need to describe return values, and annotations cover the safety profile. But for a save/request operation with 7 parameters including optional contact/org/volume fields, a bit more context about the workflow would strengthen completeness. It's minimally adequate but not rich.

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 43%, meaning 3 of 7 parameters (entry_id, action, use_case) have descriptions in the schema; the other 4 (inputs, contact, organization, expected_volume) have partial descriptions. The description adds context by framing that it captures 'the user goal and the preview action' — which maps to use_case and action. But it doesn't elaborate on contact, organization, expected_volume, or inputs beyond the schema descriptions. Baseline 3 is appropriate given moderate coverage.

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 says 'Save demand for a catalog entry after a preview, with the user goal and the preview action.' It identifies a specific verb+resource (save demand for catalog entry) and names key context (after a preview), but doesn't clearly distinguish from siblings like account_request_upgrade or catalog_preview. It's clear enough but lacks the sharpness to differentiate from 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?

The description implies usage happens 'after a preview', which gives some temporal context. However, it doesn't explicitly state when NOT to use this tool, how it relates to sibling tools (e.g., catalog_preview, catalog_describe, account_request_upgrade), or what the workflow sequence is. The guidance is implied rather than explicit.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile well. The description adds that it returns metadata (schema, filters, limits, freshness, access details) but doesn't disclose rate limits, pagination, or error behavior. With strong annotations carrying the safety burden, the modest addition is acceptable.

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 clear sentence that front-loads the primary function and enumerates the return fields. There is zero waste, and every word earns its place. Efficient and readable.

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 an output schema provided, so the need to document return values is reduced. The tool has only one parameter fully covered by the schema, and annotations fully cover the safety profile. The description is complete for a simple metadata-lookup tool given the richness of structured fields available.

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 the dataset_id parameter fully documented in the schema (pattern, constraints, and origin: "from datasets_list or datasets_search"). The description adds the notion that this is the identifier being described, which is largely handled by context. With baseline 3 at 100% coverage, the description's clarity about what the parameter refers to bumps it slightly.

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 clear verb ("Return") with a specific resource (schema, filters, limits, freshness, and access details) for one dataset identifier. It's clear what the tool does, though it doesn't explicitly differentiate from sibling tools like catalog_describe or datasets_list, which could be confused with it. The title and name are also clear.

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

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

The description states the single input (dataset identifier) and the return content (schema, filters, limits, freshness, access details). It implies this tool is the metadata-lookup counterpart to datasets_list and datasets_search, but it doesn't explicitly state when to use it vs those siblings or provide exclusions. Usage context is implied rather than stated.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds the 'access, freshness, and coverage details' context which enriches what the agent knows about the returned content. However, it doesn't describe pagination, limits, or return format beyond what the annotations/schema already implicitly convey. With good annotations, a 3 is appropriate.

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?

Single sentence, zero waste. Every clause earns its place: the verb 'list', the resource 'datasets', the content dimensions (access, freshness, coverage), and the purpose (selection). Very efficiently packed.

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?

This is a simple parameterless list tool with strong annotations (readOnly, idempotent, non-destructive) and an output schema. The description adequately conveys the three data dimensions returned (access, freshness, coverage). It's complete for a simple enumeration tool. Could potentially mention where this fits in the workflow (e.g., before datasets_describe), but for a list tool this is sufficient.

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?

This tool has 0 parameters and schema coverage is 100% (trivially, since there are no params to document). Per the rubric, 0 params receives a baseline of 4. The description appropriately focuses on output characteristics rather than parameter semantics, which is correct for a parameterless list endpoint.

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 clear purpose: list available datasets with access, freshness, and coverage details, specifically for dataset selection. It uses a specific verb (list) plus resource (datasets) and adds the contextual purpose of selection. It doesn't explicitly distinguish from siblings like datasets_describe or datasets_search, but the 'list' vs 'describe'/'search' distinction is fairly clear from the verb use.

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 usage context ('for dataset selection') which gives a hint about when to use it. However, it doesn't explicitly say when NOT to use it or point to alternatives like datasets_describe for detailed info on a single dataset or datasets_search for filtered lookups. The usage guidance is implied rather than explicit.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that it searches identifiers, names, and descriptions — useful scoping detail beyond the annotations, though it doesn't disclose result limits, ranking behavior, or match semantics.

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 concise sentence that efficiently conveys what is searched and in what form. No wasted words, no redundancy with the schema or annotations.

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

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

With a single well-documented parameter, an output schema present, and read-only annotations, the tool is simple enough that the description is adequate. It doesn't disclose result-count limits or match behavior, but given the tool's simplicity, the completeness is satisfactory.

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 single parameter 'query' has 100% schema description coverage ('Plain words that describe the required financial data'), and the description reinforces this by specifying it should be a plain-language financial-data query, adding the financial-data domain constraint beyond the schema's generic phrasing.

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 clear verb ('Search') and resource ('dataset identifiers, names, and descriptions') with a plain-language query approach. It doesn't explicitly distinguish from datasets_list/datasets_describe, though the free-text 'search' nature is implied and differentiates from list/describe siblings.

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 conveys it accepts plain-language financial-data queries, implying use for discovery. It doesn't explicitly state when to use it versus datasets_list (enumerate) or datasets_describe (inspect one), leaving the alternative-selection guidance implicit rather than explicit.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description clarifies this is a non-destructive submission (saving a request), which aligns with annotations and adds context about intent (improving coverage). However, it doesn't disclose whether the request is reversible, requires auth, or what happens after submission beyond basic intent.

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 and front-loaded with purpose, followed by examples and rationale. Every sentence adds value with minimal waste. Could be slightly tighter, but it's efficient given the examples aid comprehension.

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 feedback-submission tool with annotations covering the safety profile and an output schema present, the description is reasonably complete. The category enum in the schema covers the 'type of missing capability' distinction. With low-side effects (non-destructive submission) and clear parameters, the description adequately supports invocation, though it could mention the optional use_case field.

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 67%, meaning the description covers category and request semantics in its text ('missing tool, dataset, or feature', 'concise description of the missing capability'). The use_case parameter is not mentioned in the description at all, though its schema description is clear. The description adds a small amount beyond the schema via examples but doesn't fully compensate for the undocumented use_case 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?

The description states a clear verb+resource ('submit product feedback', 'Save a product request') for missing tools/datasets/features, with concrete examples (backtesting, options pricing). It distinguishes from siblings like catalog_request and account_request_upgrade through the 'missing capability' framing, though it doesn't 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?

The description implies usage via the category field ('missing tool, dataset, or feature') and examples, but doesn't explicitly state when to use this vs alternatives like catalog_request or news tools. The 'helps improve coverage' phrasing implies a product-feedback context but no exclusions or comparisons to sibling tools are 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the chronological ordering behavior and filter semantics, which is useful beyond annotations. However, it doesn't disclose pagination behavior, timezone handling, or whether both start/end days are inclusive, which would be relevant for a date-range query tool.

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?

Single sentence, front-loaded with the primary function (return economic events), then scope (chronological, date range) and features (filters). No wasted words and reasonably structured, though it could enumerate the filter options more explicitly.

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?

This is a moderate-complexity list/query tool with a good output schema and strong annotations. For a filtered calendar listing, the description covers the essential purpose and filters. Given the output schema exists and annotations are comprehensive, the description is adequate. Minor gaps around limit semantics and default behavior don't significantly impair usability.

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 60%, and the required parameters (start_day, end_day) have schema descriptions mentioning YYYY-MM-DD format. The description adds the semantic of chronological ordering but doesn't clarify parameter semantics beyond what the schema provides. The impact and country filters are well-described in the schema with enum/pattern constraints. The limit parameter is documented in schema. Baseline 3 is appropriate since the description doesn't meaningfully extend schema explanations.

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+resource (return economic events) with clear scope (chronological order, date range) and mentions optional filters (country, impact). It clearly distinguishes from sibling tools like macro_indicator and macro_current_conditions which focus on single data points rather than calendar events. Purpose is clear though it doesn't explicitly name an alternative.

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 usage for retrieving economic events in a date range but gives no explicit when/when-not guidance or exclusion criteria. Sibling tools like macro_indicator and macro_current_conditions suggest alternative tools exist for specific indicators, but the description doesn't clarify when to choose this over those alternatives. Context is implied but not stated explicitly.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the 'time and method version' disclosure, which is useful behavioral context indicating the output is versioned and time-stamped. However, it doesn't describe freshness cadence or what 'open world' means for this tool's results.

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

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

Two sentences, zero wasted words. States the core action, scope, and output contents. Perfectly sized for a zero-parameter 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 zero-parameter, read-only tool with an output schema present, the description is nearly complete. It discloses the result includes time and method version, which is helpful. Slight gap: it doesn't indicate how frequently themes are regenerated or what geopolitical scope 'current' covers beyond 'United States.'

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 0 parameters, so schema coverage is trivially 100%. With no parameters, the baseline is 4 per the rubric. The description appropriately notes what the result includes (time and method version), compensating for any ambiguity about the output.

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+resource: 'Return generated themes for current United States macroeconomic conditions.' It's clear what the tool does and distinguishes from siblings like macro_calendar and macro_indicator, which are calendar/indicator tools rather than theme-generation tools. It could be slightly more specific about what 'themes' means, but the purpose is clear.

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 usage (when you need current US macroeconomic themes), but provides no explicit when-to-use guidance or exclusions. It doesn't name alternatives like macro_indicator for numeric data. However, 'generated themes' subtly signals a distinct use case from data-oriented siblings.

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, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds the date-range scoping and return-type context (observations). It doesn't disclose pagination behavior, error handling, or whether data is daily/monthly frequency, but with strong annotations the bar is lower.

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, tightly-written sentence that conveys the core action (return observations), the object (one economic indicator), and the key option (optional dates). Zero waste, appropriately front-loaded.

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?

This is a simple data-retrieval tool with strong annotations (readOnly, idempotent) and an output schema. For this complexity level, the description adequately covers the main behavior. It could mention return format or frequency but the output schema covers returns. Minor gap: no mention of how limit interacts with date ranges or max date range size.

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 50%. The 'name' parameter has an example (CPI) in the schema. The description mentions 'optional dates for the observation period' which aligns with start_day/end_day. However, it doesn't clarify the relationship between limit and date filtering, or default behavior when no dates are provided, leaving the other 50% of parameters partially undocumented.

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

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

The description clearly states it returns observations for one economic indicator, with optional date filtering. The verb+resource ('Return observations...') is specific. However, it doesn't explicitly distinguish from siblings like macro_calendar or macro_current_conditions, which could be confused with this tool, so it's not 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?

The description implies usage for fetching historical indicator observations with date ranges, but provides no explicit when/when-not guidance or alternatives. Siblings like macro_current_conditions exist but aren't referenced, leaving the agent to infer which tool fits current-vs-historical data 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?

Annotations provide readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, which already cover the safety profile. The description adds the 'third-party opinions' framing, which is useful context indicating the data's provenance. No contradictions with annotations. However, it doesn't detail limit behavior or pagination beyond schema defaults, so it adds modest but not rich 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?

Two sentences with zero waste - states what it returns and the data provenance. Front-loaded with the key purpose. Slightly terse but appropriately minimal for a read-only lookup tool.

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

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

An output schema exists, and the 2-parameter schema is fully documented. The description covers the purpose and data provenance adequately. However, given the large sibling set and the open-world annotation, brief guidance on use cases or what 'rating changes' entails would improve completeness, though nothing critical 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%, with both parameters (symbol, limit) having descriptive text including an example. The description adds nothing parameter-specific beyond what the schema already covers. Baseline 3 applies since the schema fully documents both 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 it returns 'analyst rating consensus and recent rating changes for one ticker' - a specific verb+resource+scope. It distinguishes from siblings by specifying 'one ticker' (vs market_quote or news_* which serve different purposes). Could be slightly sharper on what distinguishes it, but it's clear enough about 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 notes results are 'third-party opinions' but provides no guidance on when to use this tool vs alternatives like market_quote, market_fundamentals, or market_earnings. With 27 sibling tools in the market/news space, an agent gets no direction on which to pick for analyst-specific data versus fundamental or price data.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the value of listing which specific profile fields are returned and confirms the single-ticker scope, providing useful context beyond the annotations. No contradiction with 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?

A single efficient sentence that names the tool's output fields and scope with zero wasted words. Every element contributes 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 one simple parameter, an output schema, and strong annotations (readOnly, idempotent, non-destructive), the description is largely complete for a lookup tool. It names the return fields and is scoped to a single ticker. Slightly more detail on the 'basic profile fields' could help, but this is adequate given the rich structured metadata.

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% (the symbol parameter is fully documented with pattern, length constraints, and example). The description references the profile fields but doesn't add syntax details for the parameter beyond what schemas already provide, 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 clearly states the verb ('Return') and resource ('company profile'), and lists the specific fields delivered (name, industry, exchange, market value, basic profile fields) for one ticker. It's defined at a single-ticker scope which differentiates it from market_symbol_search and market_quote, though it doesn't explicitly name sibling 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?

The description clearly applies to a single ticker (usage context implied), and the single-parameter symbol requirement implicitly signals this is a per-symbol lookup. However, it doesn't explicitly state when to prefer this over market_quote, market_fundamentals, or market_analyst_ratings, nor any exclusion conditions.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered by structured data. The description adds that it returns 'reported or scheduled' events, which is useful context. However, it doesn't disclose pagination behavior, ordering of results, or whether both reported and scheduled events are mixed in the same response—modest added value beyond 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?

One efficient sentence, zero filler, appropriately front-loaded with the core purpose. It earns its single sentence. Minor deduction: it could have added a usage note about when to prefer this over market_fundamentals without hurting conciseness.

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 strong annotations (read-only, idempotent, open-world) and an output schema, the description is reasonably complete. It identifies the core inputs (date range + ticker) and the data returned (earnings events). Given the availability of an output schema, this is adequate 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?

Schema description coverage is only 25% (only symbol has a meaningful description per the coverage calculation, though limit/date params have inline descriptions too). The description compensates by naming which params matter (date range, ticker filter) and their roles. It clarifies that dates are a range and the symbol is optional, adding meaning beyond the bare schema. Slight gap: it doesn't explain the interplay between start/end defaults when one is omitted.

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 earnings events (reported or scheduled) in a date range with an optional ticker filter. It uses a specific verb+resource and distinguishes it from siblings like market_quote and market_fundamentals. It's clear but doesn't explicitly contrast with the news or macro siblings, though the earnings focus is self-evident.

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 date-range and optional ticker filter are described, giving a clear idea of what inputs are expected. However, there is no 'when to use vs. alternatives' guidance, no mention of defaults (like if start_day defaults to something), and no note of whether reported vs scheduled events can be distinguished or filtered independently.

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 strong: readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. These already convey the safety profile fully. The description adds the 'threshold' filtering behavior (minimum weight filter) which is genuinely beyond annotations. However, it does not disclose return format specifics, whether partial results are returned when symbol is invalid, or that 'largest reported holdings' implies a sorting/truncation behavior. With such comprehensive annotations, the description's added value is modest, making a 3 appropriate.

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 well-formed sentence that front-loads the core purpose and appends the optional filter parameter. Zero wasted words, no redundancy with the title or schema. Exemplary conciseness.

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 data retrieval tool with 3 params, strong annotations, and an output schema present, the description is reasonably complete. It covers the core function (return largest holdings), the optional filter (min weight), and combines cleanly with schema documentation. A slight gap: it doesn't mention what happens with no results or invalid symbols, but given the output schema and openWorldHint annotation, this is acceptable. Not quite a 5 because it could briefly note the 'largest reported' semantics (e.g., sorted by weight descending).

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 67% — symbol and limit are documented, but min_weight_percent is described in schema as 'minimum portfolio weight' without noting that it's a FILTER on the returned holdings (the description clarifies this is a filter, adding value). The description explains the semantic relationship between min_weight_percent and the 'largest reported holdings' selection, which isn't obvious from the schema alone. This bridges the gap created by the 33% undocumented parameter meaning in context.

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 ('Return the largest reported holdings for one ETF') and clearly identifies what the tool does. It distinguishes from siblings like market_quote, market_price_history, and market_company_profile by focusing on ETF holdings rather than individual stocks, though it doesn't explicitly name a sibling alternative. The 'largest reported holdings' qualifier adds useful specificity.

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 this is for ETF holdings data (use when you need fund constituents), and the sibling list has no other holdings-focused tool, so differentiation is implicit. However, there's no explicit guidance on when to use this vs alternative market tools, no mention of prerequisites (e.g., knowing the ETF symbol already, or whether the tool works for non-ETF tickers), and no mention of the openWorldHint behavior that indicates the answer might be 'no data available'.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, giving the agent a strong safety profile. The description adds that it returns 'reported financial statements' (implying historical/actual data rather than projections) and supports quarterly/annual periods. However, it doesn't disclose output volume limits beyond the schema 'limit' param or describe pagination/response format 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 a single efficient sentence that communicates the core purpose. It's appropriately concise without wasted words, though it could slightly expand on scope or usage guidance without becoming verbose.

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 an output schema present and full schema parameter coverage, so much of the context is handled structurally. The description covers the core intent (financial statements by period). However, given the existence of many market_* sibling tools, it could better situate itself—e.g., noting it reports fundamental/accounting data as opposed to market prices or analyst views, which would improve 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%, so the schema already documents all three parameters (symbol, period, limit) with descriptions and enums. The description doesn't add meaningful semantics beyond what's already in the schema. Baseline 3 is appropriate since the schema carries the burden well.

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: 'Return reported financial statements, ratios, and metrics for one company by quarterly or annual period.' It clearly specifies what is returned and the periodicity. It's a solid purpose statement, though it could better distinguish itself from siblings like market_company_profile or market_earnings.

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 no guidance on when to use this tool versus alternatives like market_quote, market_earnings, or market_price_history. It doesn't mention prerequisites, whether ratings/analyst data is included (which market_analyst_ratings handles), or how it relates to its siblings. No when/when-not guidance given.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, reproducible read operation. The description adds the pagination cursor context (via the cursor param) and the date-range-or-latest-count scoping. It doesn't disclose rate limiting or any other behavioral caveats, but with strong annotations the burden is lower; a 3 is appropriate.

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 single-sentence description is tight and front-loaded with the core purpose. It covers both invocation modes (date range, latest count) efficiently with zero filler. Slightly more structural clarity around cursor/pagination could help, but for a purpose statement it's well-sized.

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 presence of an output schema means the description needn't document return structure. With 6 params (only 1 required), a two-mode invocation, an output schema, and strong read-only annotations, the description covers the essential input semantics and invocation modes. It's reasonably complete for a medium-complexity historical-data retrieval tool; minor gaps around pagination behavior remain but are acceptable.

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 50% and each parameter already has inline descriptions (symbol, limit, order, cursor, start_day, end_day, plus patterns and defaults). The description adds the meaning that the tool is the source of the 'latest trading-session count' semantics tied to limit, which adds some value. With 50% coverage and moderately documented params, the description partially compensates but doesn't fully carry param meaning, so baseline 3 fits.

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 (return) plus resource (daily prices and volume) and scoping (one ticker by date range or latest trading-session count). It's specific about the primary use case. However, it doesn't explicitly distinguish from sibling market_quote (real-time single quote) or market_fundamentals, though 'daily prices and volume' vs 'quote' is implicitly differentiated.

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 conveys the tool fetches historical price data by either date range (start_day/end_day) or a count of trailing trading sessions (limit), which is reasonable usage context. But it doesn't explicitly state when NOT to use it or point to alternatives like market_quote for real-time prices, so the when-versus-alternatives guidance is implied rather than explicit.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond those: that the data is 'end-of-day' (stale) and specifically that it is NOT real-time — which is a crucial behavioral caveat for agents expecting current prices. This is valuable addition beyond what annotations state.

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, zero wasted words. The first sentence states what the tool does; the second sentence delivers the crucial caveat. Every word earns its place, and the key limitation is front-loaded in the second sentence.

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 is simple — a single required parameter, and an output schema exists. The description covers the key limitation (end-of-day, not real-time) that an agent would need to know. With the output schema present, return-format explanation is unnecessary. The only minor gap is not mentioning volume alongside price more explicitly in the caveat, but this is adequately complete for a simple read-only quote 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% — the single 'symbol' parameter is fully documented with pattern, length constraints, and an example (AAPL). The description mentions 'one ticker,' reinforcing that a single symbol is expected. Since there's only one parameter and it's fully specified in the schema, the description doesn't need to add much; the baseline of 3 is slightly exceeded by the 'one ticker' clarification which reinforces single-input semantics.

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's function: 'Return the latest available end-of-day price and volume for one ticker.' The verb 'Return' plus the specific resource (end-of-day price and volume) plus the scope ('for one ticker') make it precise. It also distinguishes itself by explicitly noting it does not return a real-time quote, which helps differentiate from potential price-related siblings.

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 'This tool does not return a real-time quote,' which sets expectations and tells the agent when NOT to use this tool (i.e., when real-time pricing is needed). However, it doesn't explicitly name alternative tools for real-time quotes or for historical data, though market_price_history is a nearby sibling. The single-ticker scope is implied as a usage constraint.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which fully establishes the safe read-only nature. The description adds that results are for 'security identification' — a forward-looking context suggesting this is a lookup/precursor step. With comprehensive annotations in place, the description's additional behavioral context is reasonable and non-contradictory.

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, compact sentence that states purpose, input modality, and intent with zero filler. Every word earns its place, and the sentence is front-loaded with the primary action verb. Among the evaluated examples, this is near-optimal conciseness.

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 search tool with 100% schema coverage, full annotations, and an output schema present, the description is sufficiently complete. The agent can safely invoke it knowing it is non-destructive and idempotent, and can parse results via the output schema. The only minor gap is lack of explicit guidance on how results are ordered or what happens with an unmatched query, but the annotations and schema carry the burden well.

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%: both 'query' (a company name or ticker fragment) and 'limit' (max results) have descriptions in the schema. The description usefully frames the primary parameter as enabling search by either ticker text or company name, confirming it accepts fuzzy/incomplete input. It adds value by clarifying the semantic flexibility of 'query' beyond the schema's minimal wording.

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 ('Find') plus a clear resource and scope ('ticker symbols by company name or ticker text for security identification'). It clearly distinguishes this search-type tool from sibling market tools like market_quote, market_company_profile, and market_price_history, which retrieve specific data rather than resolving identifiers. The word 'search' in the name is fully expanded with the what/how/why.

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 usage context ('for security identification') indicating this resolves names to tickers, which is a prerequisite step before querying quote/profile/price tools. However, it does not explicitly state when NOT to use it or name alternative tools. Given the large sibling set, the guidance is adequate but falls short of explicit exclusions or alternative pointers.

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, idempotentHint=true, and destructiveHint=false, so safety profile is covered. The description adds value beyond annotations by disclosing that the tool returns processed/summarized content and explicitly excludes full article text and external links — useful behavioral context the agent wouldn't get from annotations alone.

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

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

Two tight sentences with zero waste. The first states the core action, the second adds the key exclusion constraint. Could arguably include sibling differentiation, but for what it contains, it's efficient and front-loaded.

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 read-only tool with full schema coverage, a robust output schema, and strong annotations (readOnly, openWorld, idempotent), the description is largely complete. It adds the key boundary (summary-only, no full text/links). Minor gap: it doesn't hint at what fields the summary contains, though the output schema presumably covers that.

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 single parameter story_id has a regex pattern and description ('The story identifier from a news result'). The description references the story identifier but adds no new semantic detail beyond what the schema already documents, so baseline 3 is appropriate.

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

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

The description states clearly 'Return one processed news summary by story identifier' — a specific verb (return) plus resource (news summary) with scoping by identifier. It also distinguishes itself by explicitly noting it does not return full article text or external links, though it doesn't name sibling alternatives like news_general or news_stock.

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 usage by story identifier and indicates the tool is scoped to summaries versus full text, giving a sense of when it applies. However, it doesn't explicitly name alternatives like news_general or news_stock or provide when-not-to-use guidance. The 'from a news result' phrasing in the schema hints at upstream sourcing but that's not in the description itself.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety/read profile is fully covered. The description adds the 'cross-market' scoping and cursor pagination behavior, which is useful context beyond annotations. It doesn't disclose response format, but with an output schema present, that burden is reduced. Overall the description adds modest context on top of strong 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?

A single efficient sentence that captures the core action, scope, and pagination mechanism. Zero wasted words, front-loaded with the primary purpose. This is exemplary conciseness.

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?

This is a simple read-only list tool with 3 self-documenting parameters, a complete output schema, and strong annotations confirming safety. The description communicates the cross-market scope and pagination. Given the abundance of supporting structured data, the description is adequately complete — slightly shy of 5 only because it doesn't contrast with sibling news tools, which sibling disambiguation would require.

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 67% — the hours, limit, and cursor parameters are each described in the schema. The tool description itself adds essentially no parameter-specific meaning (it merely mentions cursor pagination generally). With moderate (67%) coverage, the description doesn't heavily compensate beyond what schema already documents, landing at baseline 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 states 'Return recent cross-market news summaries' with a specific verb (return), resource (news summaries), and scoping ('cross-market', 'recent', pagination). It's clear about what it does. However, it doesn't explicitly distinguish from siblings like news_stock (per-stock news) or news_article, which would benefit from a brief contrast.

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 usage for fetching broad market news via the phrase 'cross-market', which hints it's the general option vs. news_stock being stock-specific. However, it never explicitly states when to use this vs. alternatives, nor mentions the cursor for pagination across multiple pages. No exclusions or 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is well-covered. The description adds the useful caveat that 'These scores do not establish causality' — a meaningful behavioral disambiguation. However, it doesn't explain pagination (cursor) behavior, which is a notable operational trait, but the output schema likely covers return structure.

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 concise sentences with zero filler. The causality caveat earns its place as a behavioral guardrail. It's appropriately sized for a read-only scoring tool. Could arguably add a brief note about pagination but isn't bloated.

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

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

With an output schema present, strong annotations (readOnly, idempotent), and a single required parameter, the description covers the essential context. The causality disclaimer adds important nuance. For a tool whose schema and annotations already carry substantial structured information, this is adequately complete. The only minor gap is absence of guidance on how scores relate to the news feed tools.

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

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

Schema description coverage is 75%. The description adds no parameter-specific meaning beyond what exists in the schema — the key term 'scores' for symbols is in the schema. Cursor behavior ('Omit it for the first page') is documented in the schema. The description contributes nothing beyond the schema's parameter documentation, aligning with the baseline 3 for high coverage.

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 ('Return') with a clear resource ('generated direction, importance, and confidence scores for recent news about selected tickers'). It distinguishes itself from news article lookups (news_article, news_stock) by focusing on computed impact scores rather than articles themselves. The 'generated' qualifier is useful. However, it doesn't explicitly name an alternative tool for comparison, and 'recent news' is somewhat vague.

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 usage context (querying news impact scores for tickers) but gives no explicit when-to-use vs alternatives guidance. Among siblings, news_stock and news_article likely return the underlying news, while this tool returns derived scores, but the description doesn't state this distinction. No exclusions or prerequisites are mentioned, and the lookback window (hours) is only in the schema.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that it returns summaries rather than full article text — useful behavioral context. It doesn't mention pagination via cursor or result limits, but with strong annotations covering the safety profile, a 3 is appropriate.

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 concise sentences, zero waste. The description front-loads the core purpose and immediately flags the key limitation (summaries only, not full text). Every word 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 read-only news-fetching tool with a rich output schema and good annotations, the description covers the essentials: what it returns, the scope (one ticker). It could mention the cursor-based pagination pattern or hours/limit defaults, but the output schema and input schema supply much of the remaining context. Adequate but not exhaustive.

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 75%, with symbol having a clear description (Example: AAPL), and hours/limit having self-explanatory descriptions. The cursor parameter is well-documented in the schema ('Omit it for the first page'). The description adds limited param value but the schema already does substantial work for 3 of 4 params. Cursor lacks description-level explanation of pagination semantics, hence 4 rather than 5.

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 'Return recent news summaries for one ticker' — a specific verb+resource+scope. It clearly differentiates from siblings like news_general (general news) and news_article (full articles), and explicitly notes it returns summaries, not full text. Slight deduction because it doesn't explicitly name sibling alternatives, though the 'one ticker' scoping distinguishes it.

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 notes it returns summaries and not full article text, which implicitly guides against using this for full articles. However, it doesn't explicitly state when to use this vs alternative tools like news_article or news_general, nor does it mention required parameters. The 'one ticker' constraint is implied but no explicit exclusions are given.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's burden is lower. The description adds the specific purpose (availability check) but doesn't describe what the response contains beyond what the output schema would provide. No contradiction with 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 a single concise sentence with zero wasted words. It could arguably benefit from a tiny bit more detail about what 'status' means (e.g., returns ok or version info), but for a ping tool it's appropriately minimal.

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 zero params, an output schema, and full annotation coverage, the description is mostly complete for this simple tool. However, it doesn't clarify what a successful vs. failed response looks like or what 'status' returns specifically. For a health-check tool this is a minor gap, but given its simplicity, the description 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?

The tool has 0 parameters, and schema coverage is 100%. Per the rubric, 0 params = baseline 4. No parameter documentation is needed since there are no parameters to document.

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 it returns the Unquant MCP server status for an availability check, which is a clear verb+resource+intent. It distinguishes from siblings since it's a health/availability endpoint unlike the data retrieval tools. However, 'Return the Unquant MCP server status' is slightly awkward phrasing that could be clearer.

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 usage is for checking server availability/health, which is a clear context. But it doesn't explicitly differentiate from alternatives or state when not to use it, though given it has no parameters and is a ping-style tool, the usage context is fairly self-evident.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers safety. The description adds the important caveat that totals do not show current holdings or intent, which is valuable context. It doesn't disclose pagination behavior or that data represents reported (potentially delayed) transactions.

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, both informative and waste-free. The first sentence states the core function; the second adds an important limitation caveat. It's appropriately sized for the tool complexity.

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 an output schema (so return format is covered) and good annotations. However, given it's an aggregation/normalization tool with 4 parameters including pagination, the description could mention that results are sorted/deduped, or note the lookback default behavior. The caveat about holdings/intent partially compensates but pagination behavior and data recency are left implicit.

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 50%, and the description doesn't add anything about parameters beyond what the schema provides. The 'days' lookback, 'limit', 'cursor' pagination, and 'symbols' filter are all documented in the schema itself. With moderate coverage, the description adds no extra parameter meaning, meeting the 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 description states 'Return ticker-level totals from reported United States congressional transactions' with a specific verb+resource+scope. It distinguishes the aggregate view from the sibling 'politics_us_congress_trades' tool by using 'totals' vs. individual trades. However, it doesn't explicitly name the sibling alternative or contrast 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?

The description implies this is a summary/aggregate tool by using 'totals,' and the sibling name 'politics_us_congress_trades' suggests a distinction, but no explicit when-to-use/when-not-to-use guidance is given. The line 'The totals do not show current holdings or intent' adds a usage caution but no direction toward 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 already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the read-only/safe nature is covered. The description adds value by clarifying this returns 'reported' transactions (data source) and specifying filter dimensions. It doesn't describe pagination via cursor beyond the schema, but with rich annotations the bar is appropriately lower.

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 compact sentence that names the resource, the action, and the key filter dimensions. Zero filler or repetition. Ideal front-loaded structure for a query 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?

This is a moderately complex read-only query tool with 8 parameters, a solid schema, and clear annotations plus an output schema. The description covers the primary use case and filter dimensions. It could add how 'days' interacts with explicit date windows and mention pagination patterns, but given the strong schema and annotations, the description is reasonably complete for its purpose.

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 only 25%, meaning most of the 8 parameters aren't documented in the description. The description mentions ticker, member, asset owner, and transaction dates as filter options, which loosely maps to symbols, member_names, asset_owner, and start_day/end_day. However, it doesn't explain the relationship between 'days' and 'start_day/end_day', nor that 'cursor' is for pagination (though the schema covers that). With 25% coverage, the description partially compensates but doesn't fully bridge the 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?

The description uses a specific verb-resource structure ('Return reported United States congressional transactions') and lists concrete filters (ticker, member, asset owner, dates). It clearly identifies what the tool returns. It's distinguished from 'politics_us_congress_aggregate' by implying this returns individual transactions rather than aggregated data, though it doesn't explicitly contrast with that 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 states filters that can be applied, implying usage for looking up transactions by ticker, member, owner, or dates. However, it doesn't explicitly state when to use this vs. politics_us_congress_aggregate, nor give examples or mention the days lookback default. The usage context is implied but no explicit when-not guidance is given.

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