Précis Finance MCP

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

No annotations exist, so description carries full burden. It describes return content but does not disclose read-only nature, side effects, error behavior (e.g., invalid binding_id), or any authorization requirements. Minimal behavioral insight.

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, clear sentence. It efficiently conveys the tool's purpose without extraneous words, and front-loads the action and resource.

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

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

It lists the configuration components, providing some completeness despite no output schema. However, it lacks information on error handling, parameter source (e.g., relying on list_bindings), and any prerequisites. Adequate but with gaps.

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

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

Schema coverage is 0% with a single parameter binding_id. The description does not explain its meaning, how to obtain it, or any constraints (e.g., format). It adds no value beyond the parameter name and type.

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

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

The description clearly states the verb 'Fetch' and resource 'one data feed's full configuration', listing its components (source, target dataset, schedule, extract parameters). It distinguishes from siblings like list_bindings which would return summaries.

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 needing detailed config for a single feed, but provides no explicit when-to-use vs alternatives, such as list_bindings for overviews. No exclusions or conditions are mentioned.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, authentication needs, or rate limits. It only states the basic operation.

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?

Description is a single concise sentence that front-loads the primary purpose. However, it is so brief that it sacrifices completeness.

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

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

Given the lack of output schema and many sibling tools, the description is insufficient. It does not explain what 'column schema' means or what the return format is, leaving the agent with little context.

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 0%, and the description does not explain the 'source_key' parameter at all. The agent gets no guidance on what value to provide.

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

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

Description clearly states 'Get the column schema for an inspection source,' which is a specific verb and resource. It distinguishes from siblings like 'inspect_rows' and 'list_inspection_sources', but could be more explicit.

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

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

No guidance on when to use this tool versus alternatives. No prerequisites or context about when to call it 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?

No annotations provided. Description says 'fetch' which implies a read operation, but does not explicitly state read-only, idempotency, or any side effects. For a simple get, this is acceptable but could be clearer.

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

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

One sentence efficiently conveys the tool's purpose and output fields. No fluff, but could be slightly improved by front-loading 'Fetch full detail of a single data load' while keeping rest as is.

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?

Despite having no output schema, the description lists the return fields (timestamps, status, rows landed, error message), which is sufficient for a simple tool with one parameter. No additional context like rate limits or auth is needed given the simplicity.

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

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

Schema coverage is 0% and the description only mentions 'by load_id' without explaining what load_id represents or how to obtain it. With one parameter, the description should at least specify that load_id is a unique identifier for the data load, e.g., from list_load_history.

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

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

Description clearly states the tool fetches full detail of a single data load by load_id, listing specific fields (timestamps, status, rows landed, error). This distinguishes it from sibling list_load_history which likely lists loads without full detail.

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

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

No explicit when-to-use or when-not-to-use guidance. It's implied that this is for getting detail of a specific load, but no mention of alternatives like list_load_history for listing. A short sentence would improve agent decision-making.

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

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

With no annotations, the description must fully disclose behavioral traits. It mentions returning a 'capped sample' and a 'grid,' but does not describe safety (read-only, mutability), authorization needs, or what happens if the source is not enabled. The information is too sparse for an agent to infer potential side effects or constraints.

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

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

The description is two sentences and front-loaded with the core purpose. Every word adds value; there is no extraneous information.

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

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

Given 9 parameters, no output schema, and many sibling tools, the description is insufficient. It does not explain what a 'figure' or 'enabled inspection source' is, nor does it describe the return structure beyond a vague reference to a 'capped sample' and 'grid.' More context is needed for effective use.

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

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

Schema coverage is 0%, and the description offers no additional meaning for the 9 parameters (e.g., source_key, scenario_id, limit). While baseline for zero parameter coverage is 4, the description fails to compensate by clarifying any parameter semantics, leaving the agent to rely solely on the schema.

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

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

The description clearly states the tool inspects row-level detail behind a figure from an enabled inspection source. It uses a specific verb ('Inspect') and resource ('row-level detail'), which helps distinguish it from sibling tools like get_inspection_schema or list_inspection_sources, though it does not explicitly name 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?

No guidance is provided on when to use this tool versus its siblings. The description does not specify prerequisites, exclusions, or context for when inspect_rows is appropriate over alternatives like run_statement or list_inspection_sources.

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

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as authentication requirements, pagination, rate limits, or any side effects. The tool is a read-only list operation, but the description does not confirm this.

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 sentence that is concise and front-loaded with the primary action. It is well-structured for quick scanning, though it could be slightly more explicit about parameters.

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

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

Given no output schema, the description partially explains return values (datasets, source, frequency). However, it omits parameter guidance and does not fully describe what the tool returns (e.g., list format, pagination). Adequate but incomplete for a simple list tool.

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

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

Schema description coverage is 0%, meaning the description must compensate. However, the description does not mention the two parameters (target, source_id) at all, leaving their meaning unclear. It adds no value beyond the schema.

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

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

Description clearly states the verb 'List', the resource 'configured data feeds (ingestion bindings)', and the scope 'with their schedule — which datasets load, from where, how often.' It distinguishes from sibling tools like get_binding which would return a single binding.

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 listing bindings, but does not explicitly state when to use versus when not to use, nor does it mention alternatives like get_binding for a single binding. No exclusions or prerequisites 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?

With no annotations, the description carries the burden. It clarifies the tool returns catalogue metadata only, avoiding confusion about member listing. No side effects or additional behavioral notes are needed for a simple read-only list.

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: first defines purpose and output, second provides usage guidance. No redundancy.

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 tool with no output schema, the description partially describes return values (keys, labels, kinds) and clarifies scope. Adequate for a simple list operation.

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?

No parameters exist (0 params, 100% schema coverage), so baseline 4 applies. The description adds no param info as none is needed.

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

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

The description clearly states the tool lists dimensions, specifies returned fields (keys, labels, kinds), and distinguishes from sibling search_hierarchy by noting it returns only catalogue metadata.

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

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

Explicitly states when to use this tool (for dimension metadata) and directs to search_hierarchy for listing members, providing clear guidance on 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?

With no annotations provided, the description must fully disclose behavior. It only states the tool lists sources, omitting details on permissions, side effects, or any limitations. This is insufficient for a simple but potentially security-relevant operation.

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, front-loaded sentence with no extraneous words. Every part serves the purpose, making it highly concise.

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

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

Given no output schema and a simple purpose, the description is minimally adequate. However, it does not explain what 'inspection sources' are or how the output is structured, leaving some ambiguity for an AI agent.

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

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

The input schema has zero parameters, so the description needs to add no extra meaning. Schema coverage is 100%, and the description does not conflict or add unnecessary 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 clearly states the tool lists row-level sources for inspection. It uses a specific verb and resource, but does not differentiate from sibling tools like list_bindings or list_dimensions.

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 is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios where listing inspection sources is appropriate.

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

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

With no annotations, the description carries the full burden. The word 'browse' suggests read-only behavior, but it does not explicitly state non-destructive or idempotent nature. For a simple listing tool, this is adequate but could be improved with explicit statements about permissions or side effects.

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

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

Single sentence, no verbose explanations, perfectly concise. 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?

Given zero parameters and no output schema, the description covers all necessary aspects: what the tool does and what it returns. It is complete for its simplicity.

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

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

There are zero parameters, so the baseline is 4. The description adds no parameter info, but none is needed. It correctly prioritizes describing the output content over parameters that don't exist.

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 purpose: browsing a metric catalogue with specific items (metric keys, formats, domains, dimensions). It uses a unique verb 'browse' and resource 'metric catalogue', distinguishing it from sibling tools like 'list_dimensions' or 'get_binding'.

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 exploring available metrics but provides no explicit when-to-use or when-not-to-use guidance. Given the presence of sibling tools, some direction on when to use this instead of more specific listing tools would be helpful.

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

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

No annotations are provided, so the description carries full burden. It states the tool lists loads from the audit trail but does not disclose potential behavioral traits such as read-only nature, required permissions, rate limits, or whether it returns all history or only recent entries. This leaves the agent uncertain about side effects and constraints.

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 extremely concise: two sentences with no extraneous words. It front-loads the core action and resource, then provides relatable example questions. Every word adds value.

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

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

Given five parameters, no output schema, and no annotations, the description is insufficient. It fails to explain return format, pagination, or parameter usage. The agent has little guidance on how to craft a meaningful request or interpret results.

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 0%, meaning no parameter descriptions are present in the schema. The tool description adds no information about the five parameters (limit, period, status, binding_id, dataset_id). The agent cannot infer expected formats, allowed values, or how parameters affect results.

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 lists data-load attempts from the ingestion audit trail with status. It provides concrete example questions ('is April in yet?', 'when was this data last loaded?'), which helps the agent understand the tool's purpose and distinguishes it from siblings like get_load_status (which likely returns a single status) and list_bindings (which lists binding metadata, not load history).

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 example questions but does not explicitly state when to use this tool versus alternatives (e.g., get_load_status for a specific dataset's current load status). No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the full burden of disclosure. It only states the action and output (status), but does not mention any behavioral traits such as authentication requirements, pagination, or potential side effects. For a read-only list tool, more detail on scope or limits would be helpful.

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 no wasted words. It is front-loaded with the key action and resource, making it quick to parse.

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

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

Given the simplicity of the tool (no parameters, no output schema), the description is minimally adequate. However, it does not explain what a 'planning scenario' is or what 'status' entails, nor does it differentiate from sibling list tools. This leaves gaps for an agent needing contextual understanding.

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?

Since there are zero parameters and schema description coverage is 100% (trivially), the description does not need to add parameter meaning. It correctly states that it lists scenarios without requiring inputs, which aligns with the empty input schema.

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

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

The description clearly states the verb 'List' and the resource 'available planning scenarios and their status,' making the tool's purpose evident. However, it does not explicitly differentiate from sibling list tools like list_bindings or list_dimensions, leaving some ambiguity.

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. There is no mention of prerequisites or context where this tool is preferred, leaving the agent to infer usage solely from the name.

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

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

No annotations are provided, and the description does not disclose whether the tool is read-only, has side effects, or requires specific permissions. For a listing operation, read-only is implied but not stated, leaving ambiguity.

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 sentence with no fluff. It is front-loaded and efficient, though it may be too brief to cover all necessary aspects.

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

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

Given no output schema and only one parameter, the description should at least hint at the return format (e.g., list of variant IDs or names). It does not, and it lacks usage context needed for a complete understanding.

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 0%, and the description adds no meaning to the scenario_id parameter beyond its name. The agent cannot infer the format, source, or required properties of the parameter from the description.

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 'List' and the resource 'what-if variants of a scenario'. This distinguishes it from sibling tools like list_scenarios, which lists all scenarios, and list_bindings. However, it could be more specific about what a 'variant' is.

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, nor does it mention prerequisites or exclusions. The agent must infer usage context from the tool name alone.

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

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

No annotations provided, so description carries burden. It discloses that the tool returns informational content (data model, variants, chart instructions), indicating a read-only, non-destructive operation. No mention of auth or rate limits, but sufficient for an orientation 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?

Two sentences, front-loaded with 'Call this first.' Efficiently conveys purpose and usage without wasted words.

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

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

Given no parameters and no output schema, the description fully explains the tool's function—returning orientation information. Complete for its role as an initial guide.

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?

Tool has zero parameters and schema coverage is 100% (empty). Per rules, baseline for 0 parameters is 4. Description explains what the tool returns, so no additional parameter info needed.

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

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

The description clearly states the tool's purpose: 'Returns how to use Précis over this connector: the data model...'. It distinguishes itself by being the first call, with the imperative 'Call this first'.

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

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

Explicitly says 'Call this first' and 'Read it before composing queries,' providing clear when-to-use guidance and implying that other tools are for later steps.

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

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

With no annotations, the description bears the full burden. It reveals that the tool shows a formatted table, but does not disclose whether it is read-only, if it modifies data, or any authentication or rate limit requirements. The behavioral traits beyond output format are unclear.

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 brief and to the point. It starts with the core action, provides examples, and includes specific usage notes, all in a few sentences with no wasted words.

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

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

Given 13 parameters, no schema descriptions, no output schema, and no annotations, the description is insufficient. It only addresses a few parameters and does not cover the full range of inputs, outputs, or behaviors needed to use the tool confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It explains scenarios (including alias requirement) and implies dimensions and metrics, but 9 out of 13 parameters (scale, layout, target, filters, etc.) receive no explanation, leaving significant gaps for correct invocation.

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 what the tool does: breaking metrics down by a dimension with examples like revenue by project or utilisation by employee. It uses a specific verb-resource pair and distinguishes from sibling tools like run_metric_data and run_statement by focusing on dimensioned metric analysis.

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 clear guidance on when to use the tool and gives specific instructions for passing scenarios with aliases. However, it does not explicitly state when not to use it or contrast with alternative sibling tools, missing some usage boundaries.

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

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

With no annotations, the description partly discloses behavior: returns raw figures + data_ref, doesn't show table, requires explicit scenarios with aliases. But it omits side effects, error handling, or permissions needed.

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

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

The description is concise with two sentences, front-loading the core purpose. It is well-structured but could benefit from bullet points for parameter details.

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

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

Given the tool's complexity (13 parameters, no output schema, no annotations), the description lacks completeness. It does not explain output format, error cases, or behavior with missing optional parameters.

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

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

Schema description coverage is 0%, so the description should explain parameters. It only mentions metrics, dimensions, scenarios, and data_ref. Many other parameters (scale, layout, filters, decimals, etc.) are left unexplained, making it hard for an agent to use correctly.

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 breaks metrics down by dimensions, with concrete examples like 'revenue by project'. It distinguishes from siblings implicitly by mentioning downstream use with eval_chart_transform, but does not explicitly differentiate from the similar run_metric 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 gives usage context: 'Does not show the user a table' and suggests passing data_ref to eval_chart_transform. However, it does not specify when to avoid using this tool or explicitly name alternative tools for different use cases.

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

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

No annotations are provided, so the description carries full burden. It mentions the tool shows a formatted table, but does not disclose whether it is read-only, requires authentication, or has rate limits. The behavioral disclosure is adequate but incomplete.

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 five sentences that front-load the main purpose and add essential usage hints. Each sentence adds value without fluff, though slightly more structure could help scanning.

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

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

Given 13 parameters, no output schema, and no annotations, the description explains the output format (formatted table) but leaves many parameters and behavioral aspects unspecified. It is adequate for basic understanding but not thorough.

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 0%, so the description must compensate. It explains the 'scenarios' parameter with alias examples and 'dimensions' with breakdown examples, but 13 parameters exist and most (e.g., scale, layout, filters, decimals, period_start) are not explained. The added meaning is insufficient for the parameter count.

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 runs a financial statement (P&L, variance report, executive summary) and explains row/column structure. It also distinguishes from full_pnl for general P&L, clarifying when to use an alternative. The verb and resource are specific and unambiguous.

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

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

The description provides explicit guidance to prefer full_pnl for a general P&L when available and advises giving scenarios concise aliases. However, it does not contrast with other sibling tools like run_metric or list_scenarios, so coverage of alternatives is partial.

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?

Without annotations, the description carries the burden. It discloses that the tool returns raw figures and a `data_ref`, and instructs to pass the `data_ref` to `eval_chart_transform`. It also says it does not display a table. This covers key behavioral traits, though it omits details on idempotency, side effects, or error conditions.

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 coherent paragraph of 5 sentences, efficient without wasted words. It could benefit from bullet points or clearer separation of purpose, usage, and parameters, but remains concise for a first read.

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

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

Given the tool's complexity (13 parameters, no annotations, no output schema), the description is insufficient. It covers high-level purpose and a few usage hints but fails to document the majority of parameters, return structure beyond raw figures, or behavior under different statements/errors. An agent would struggle to invoke it correctly without additional context.

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

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

Schema coverage is 0%, so the description must compensate but only lightly touches on parameters: it mentions 'optional dimension breakdown' (likely `dimensions`) and hints at scenarios needing an `alias`. The other 11 parameters (scale, layout, target, filters, decimals, filename, overwrite, statement, period_end, sheet_name, period_start) are not explained, leaving the agent guessing.

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 runs financial statements (P&L, variance, exec summary) with rows as statement lines and columns as scenarios. It distinguishes from siblings like `full_pnl` by mentioning preference for that tool when listed by `precis_orientation`, and from `run_statement` implicitly by returning raw data and a `data_ref` for analysis/chart rather than showing a table.

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

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

Provides guidance to prefer `full_pnl` for unspecified general P&L when available, indicating when not to use this tool. Also notes it does not show the user a table, implying it is for data extraction. However, it lacks explicit exclusion of alternatives like `run_statement` or `run_metric_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?

No annotations are provided, so the description must cover behavioral traits. It only states the basic purpose without disclosing aspects like performance, pagination, error handling, or authorization requirements. For a search tool, this is insufficient.

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 sentence that efficiently conveys the core purpose. It is front-loaded with the action and subject. However, it could be more informative without being verbose, so it doesn't earn a 5.

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 3 optional parameters, no output schema, and no annotations. The description only covers the basic purpose but fails to explain how to use parameters, what the output looks like, or how it fits with sibling tools like 'list_dimensions'. This is incomplete for effective use.

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 0%, meaning parameters have no descriptions. The tool description does not explain what 'query', 'dimension', or 'limit' mean or how to use them. It adds no value beyond the parameter names, leaving the agent to guess.

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 'Search' and the resource 'dimension hierarchies' with concrete examples (cost centres, accounts). It also specifies the purpose: to find valid codes and ids before composing a query. This distinguishes it from siblings like 'list_dimensions' which likely lists available dimensions rather than searching within 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 explicitly states when to use this tool: 'before composing a query.' This provides clear context for usage. However, it does not mention when not to use it or list alternatives, so it lacks exclusions.

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