Précis Finance MCP

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

No annotations are provided, so the description carries the full burden. It states the operation is a fetch (implied read-only), but does not disclose any side effects, error behavior, authentication needs, or rate limits. The description is adequate but lacks depth beyond 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?

The description is a single clear sentence with no redundant information. It is appropriately front-loaded with the verb and resource, listing specific elements of the configuration returned.

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

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

For a simple fetch tool with one required parameter and no output schema, the description is fairly complete. It tells what the tool returns. Minor gaps: no mention of return format, error handling, or typical use cases, but overall it suffices.

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

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

With 0% schema description coverage, the description must compensate. It explains the tool's purpose but does not provide any additional meaning for the single parameter 'binding_id' (e.g., format, example, how to obtain it). The value added is minimal beyond what the schema already exposes.

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 'Fetch' and identifies the resource as 'one data feed's full configuration', listing key components (source, target dataset, schedule, extract parameters). This clearly distinguishes it from sibling tools like 'list_bindings' which lists multiple bindings.

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 full configuration of a single binding, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., list_bindings for overviews). No when-not-to-use or precondition information is 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?

The description implies a read-only operation but provides no details on behavior such as authorization needs, error conditions, or response structure. With no annotations to supplement, the description is insufficiently transparent.

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, using a single sentence that immediately conveys the core purpose. It is front-loaded and free of extraneous words, appropriate for a simple 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?

Given the lack of output schema, annotations, and parameter description coverage, the tool definition is incomplete. An agent cannot determine the return format or any constraints without additional information.

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

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

The sole parameter source_key is not explained beyond its schema title. With schema description coverage at 0%, the description should add context like typical values or how to obtain available source keys, but it does not.

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

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

The description clearly states the action (Get), the resource (column schema), and the object (inspection source), distinguishing it from sibling tools like get_binding or get_load_status. However, it does not elaborate on what constitutes an inspection source, which could be clarified.

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

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

There is no guidance on when to use this tool versus alternatives such as inspect_rows or list_inspection_sources. No when-not conditions 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. It clearly states the tool is a fetch operation returning specified fields, implying a read-only, non-destructive behavior. However, it does not explicitly confirm idempotency, rate limits, or authorization needs.

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-structured sentence that front-loads the verb and resource. Every word is informative, with no redundancy or filler.

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

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

For a simple tool with one parameter and no output schema, the description adequately covers the return fields (timestamps, status, rows landed, error message). It could be improved by noting potential error responses or limitations, but overall it 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?

Schema description coverage is 0%, and the description only mentions 'by load_id' without explaining the parameter's format, constraints, or purpose beyond what the schema's type string offers. The description adds minimal semantic value for the 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 uses the specific verb 'Fetch' and identifies the resource as 'data load's full detail', listing included fields (timestamps, status, rows landed, error message). It clearly distinguishes from siblings like list_load_history which list loads rather than fetching one 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?

The description implies usage by load_id but provides no explicit guidance on when to use this tool versus alternatives (e.g., list_load_history for listing loads), nor does it mention any prerequisites 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?

With no annotations, the description carries full burden. It mentions a 'capped sample' and 'grid for the user,' hinting at output behavior, but lacks details on auth, rate limits, or what 'capped' means. Inadequate for a tool with no annotation support.

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 very concise: two sentences, front-loaded with the core purpose. No redundant text, but could include more useful information without being 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?

Despite high parameter count (9) and no output schema, the description provides minimal context. It does not explain input constraints, return structure, or how parameters interact. Incomplete for a tool of this 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 0%, and the description does not explain any of the 9 parameters (including required source_key and scenario_id). It adds no value beyond the schema, which is insufficient given the parameter count and lack of schema descriptions.

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: 'Inspect the row-level detail behind a figure, from an enabled inspection source.' It specifies the verb ('inspect'), the resource ('row-level detail'), and distinguishes from siblings like run_metric or search_hierarchy by focusing on row-level inspection.

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. The description does not mention any exclusion criteria, prerequisites, or comparisons to sibling tools, leaving the agent without contextual decision hints.

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

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

The description implies a read-only list operation but does not explicitly state side effects, auth needs, or pagination. With no annotations, the description partially covers behavioral expectations, but leaves gaps about filtering and limits.

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, focused sentence with a clarifying dash. It is front-loaded with the core action and contains no redundant or irrelevant 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?

Despite low complexity, the description omits details about output format, pagination, and filtering capabilities. With no output schema, the description should provide more context but falls short.

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 'target' and 'source_id' parameters. The description adds no meaning beyond parameter names, failing to compensate for the schema deficiency.

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

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

The description clearly states the tool lists configured data feeds (ingestion bindings) with schedule details, specifying what datasets load, source, and frequency. It is a specific verb+resource and distinguishes from siblings like get_binding or list_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 provides no guidance on when to use this tool versus alternatives like get_binding or list_load_history. There is no mention of appropriate contexts, prerequisites, or exclusions.

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

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

No annotations are provided, but the description fully carries the burden by stating it is a read-only metadata retrieval operation ('Catalogue metadata only'), with no destructive actions implied. It also clarifies what it does not do (list members).

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, with the primary action and key output stated first. Every word adds value, making it highly concise 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?

Given the tool's simplicity (no parameters, no output schema), the description is complete: it explains the output, scope, and distinguishes from related tools. No critical information 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?

With zero parameters, the schema coverage is 100%, and the description does not need to add parameter details. The baseline of 4 is appropriate as no additional parameter information is necessary.

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 defined in the model, specifying what information is returned (keys, labels, kinds). It also distinguishes itself from the sibling tool search_hierarchy, which lists members.

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

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

The description explicitly tells when to use this tool (for dimension metadata) and provides an alternative (search_hierarchy for listing members), guiding the agent on appropriate usage.

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 a list operation, but does not disclose whether it requires authentication, is read-only, has rate limits, or returns any particular 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?

The description is a single, front-loaded sentence with no wasted words. It is highly concise and efficient.

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

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

While the tool is simple with no parameters, the description lacks information about the return format or any contextual details that would help an agent understand what 'row-level sources' are and what the response will contain.

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 no parameters, so the description does not need to add parameter info. The baseline for zero parameters is 4, and the description meets that.

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 'row-level sources available for inspection'. It distinguishes from sibling tools like list_bindings, list_dimensions, etc., by specifying 'inspection sources'.

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 or any prerequisites. With multiple sibling list tools, the description does not help the agent decide which one to call.

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, and the description does not disclose read-only nature, side effects, or required permissions. Although 'browse' implies safe access, transparency is minimal.

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, concise sentence that front-loads the action and content. No unnecessary 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?

Adequately describes what the tool returns (metric keys, formats, domains, dimensions) for a parameterless list operation. No output schema, but coverage is reasonable. Lacks mention of pagination or ordering.

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, so schema coverage is 100%. The description adds no param info, which is acceptable given the absence of 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 uses a specific verb 'Browse' and resource 'metric catalogue', clearly stating the tool lists metric keys, formats, domains, and dimensions per metric. This distinguishes it from sibling tools like list_dimensions or list_bindings.

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?

Implied usage for exploring the metric catalogue, but no explicit when-to-use, when-not-to-use, or alternatives. Sibling tools suggest different scopes, but guidance is lacking.

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 the description must disclose behavioral traits. It mentions listing attempts with status, but fails to detail whether it's read-only, what happens with missing parameters, pagination, or that results may be limited. The description only partially addresses 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 two efficient sentences, front-loaded with the core action, followed by illustrative examples. Every sentence adds value without 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?

With 5 optional parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain the return format, parameter constraints, or default behavior (e.g., default limit of 50). The agent lacks crucial context for effective invocation.

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

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

Schema description coverage is 0%, and the tool description provides no parameter descriptions beyond names. Critical details like the meaning of 'period', accepted 'status' values, and how 'binding_id' filters are completely omitted, 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 tool lists data-load attempts from an ingestion audit trail, with timing and status, and provides concrete example questions. This effectively distinguishes it from siblings like get_load_status (single status) and list_bindings (binding list).

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 checking recent data loads via example questions, but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. Sibling differentiation is implied but not spelled out.

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 full burden for behavioral disclosure. It states the action but does not mention side effects, read-only nature, security requirements, or output behavior beyond listing. This is minimal for a listing 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?

The description is a single, clear sentence that is front-loaded and concise. Every word serves a purpose with 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?

For a simple tool with no parameters and no output schema, the description is adequate but lacks context about what 'scenarios' and 'status' refer to. Could be more complete by briefly explaining the domain. It meets minimum viability.

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

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

The tool has zero parameters, so schema coverage is 100% trivially. The baseline for zero parameters is 4 according to the rules, and the description adds no additional parameter semantics, which is acceptable as there are none to describe.

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 available planning scenarios with their status. It uses specific verb 'list' and resource 'scenarios', and it differentiates from sibling tools which focus on other entities like bindings, dimensions, or inspections.

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 scenario lists but provides no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. Being a simple listing tool with no parameters, usage is straightforward, but explicit context is missing.

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 the description must carry the burden. It only hints at a read operation via 'list', but fails to explicitly state if it is read-only, any side effects, authentication needs, or rate limits. This is insufficient for safe agent invocation.

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 with no wasted words. It is front-loaded. However, it sacrifices valuable detail for brevity.

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 annotations or output schema, the description is incomplete. It does not explain return value format, pagination, error cases, or what constitutes a 'variant'. An agent would have many unanswered questions.

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

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

With 0% schema description coverage, the description must compensate. It mentions 'of a scenario' which loosely ties to scenario_id, but does not explain the parameter format, constraints, or how it is used. The sentence barely adds meaning beyond the schema field name.

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

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

The description clearly states the action (list) and the resource (what-if variants of a scenario). It distinguishes from sibling tools like list_scenarios by focusing on variants. However, the term 'what-if variants' is somewhat domain-specific and could be elaborated.

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

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

No explicit guidance on when to use this tool vs alternatives. The description implies it requires a scenario_id, but does not compare to sibling list tools or provide context for when listing variants 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?

No annotations are provided, so the description carries full burden. It explains what the tool returns (orientation info) and its role. It is clearly a read-only informational tool, though it could explicitly state no 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?

Concise with front-loaded key instruction 'Call this first.' Every sentence adds value, with 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?

Given zero parameters and no output schema, the description fully explains what the tool returns (orientation details about data model, variants, charts). It is 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?

No parameters exist, so baseline is 4. The description does not need to add parameter information.

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 orientation information about using Précis, including data model, variants, and chart building. It distinguishes itself from siblings by being the first call and providing foundational knowledge.

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 instructs 'Call this first' and 'Read it before composing queries,' providing clear guidance on when to use this tool before others.

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 states the tool shows a formatted table, implying a read-only, display-oriented operation. However, it does not clarify whether the operation is destructive, idempotent, or requires specific permissions. The description adds some behavioral context but falls short of full transparency for a tool with moderate side-effect potential.

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, front-loading the core purpose and output format, then adding scenario guidance. Every sentence adds essential information; there is no redundancy or filler. This is an excellent example of concise, structured documentation.

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 insufficiently complete. It captures the high-level output and the scenarios parameter but neglects other critical aspects like filters, layout options, file export behavior, and the meaning of 'scale' or 'target'. The agent would lack guidance for proper invocation in many use cases.

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 description adds meaning beyond the schema for the 'scenarios' parameter (requiring aliases) and explains the output structure. However, with 0% schema description coverage and 13 parameters, the description only minimally addresses parameter semantics. Most parameters (scale, layout, filters, decimals, etc.) remain unexplained, leaving the agent to infer meaning from names alone.

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: breaking down metrics by a dimension. It provides concrete examples (revenue by project, utilisation by employee) and specifies the output format (rows=dimension, columns=metrics×scenarios). This effectively differentiates it from sibling tools like run_metric_data or run_statement, which likely serve different reporting needs.

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 implicitly guides usage by specifying that scenarios must be passed explicitly with aliases, and that the output is a formatted table. However, it does not explicitly state when to use this tool versus alternatives (e.g., run_metric_data for raw data), nor does it provide when-not-to-use guidance or prerequisites.

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 effectively discloses key behaviors: it returns raw figures and a data_ref, is intended for analysis or charting via eval_chart_transform, and does not display results to the user. It could mention that it is a read-only operation, but overall transparency is good.

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

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

The description is concise (three sentences) and front-loads the purpose with examples. It could be better structured by grouping parameter guidance, but it avoids unnecessary verbosity.

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

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

Given the complexity (13 parameters, no output schema, no annotations), the description offers adequate high-level context: it describes the output structure and integration with another tool. However, it omits details for most parameters and does not explain return types or edge cases, leaving gaps 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?

Schema description coverage is 0%, so the description must explain parameters. Only 'scenarios' is partially described (required alias). Other important parameters like metrics, dimensions, filters, periods are not explained. The description names 'data_ref' as output but not as a parameter. This lack of detail is inadequate for a tool with 13 parameters.

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

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

The description clearly states the tool's purpose: breaking down metrics by a dimension with examples like 'revenue by project'. It distinguishes from other tools by specifying the data structure (rows = dimension, columns = metrics x scenarios). However, it does not explicitly differentiate from the sibling 'run_metric', which may have a similar but simpler function.

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 guidance on when to use the tool (for dimension breakdown) and specific instructions like passing scenarios with aliases. It also mentions it does not show a table. However, it does not specify when NOT to use it or compare it to alternatives like 'run_metric'.

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 exist, so description carries full burden. It reveals output as a formatted table, mentions support for dimension breakdown, and describes row/column structure. However, it omits side effects, auth needs, rate limits, or response format details.

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

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

Four sentences total, front-loaded with the core purpose. Each sentence adds value (purpose, structure, alternative, usage tip). Could be slightly tighter but no waste.

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 13 parameters, no output schema, and no annotations, the description covers only the high-level function and two parameter hints. Returns are described only as a formatted table, lacking details like pagination, error handling, or data types.

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% for parameter descriptions, so description must compensate. It explains `dimensions` (e.g., by period or cost centre) and hints at `scenarios` via alias advice, but leaves 11 of 13 parameters (scale, layout, target, filters, decimals, filename, overwrite, period_start, period_end, sheet_name, statement) unexplained.

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 like P&L, variance report, or executive summary. It explains rows and columns and explicitly distinguishes from `full_pnl` for general P&L, aiding sibling differentiation.

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

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

Provides explicit guidance to prefer `full_pnl` for general P&L when listed by precis_orientation, and advises giving each scenario a concise alias. Lacks explicit when-not-to-use but still offers actionable context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool returns raw figures and a data_ref for further analysis, and that it does not show a table to the user. It mentions relation to eval_chart_transform. However, it does not disclose safety traits (read-only vs destructive), auth requirements, error conditions, 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?

The description is concise, consisting of a few sentences that front-load the main purpose and key features. It avoids redundancy and clearly separates what the tool does, returns, and does not do. The structure is logical, moving from purpose to details to caveats.

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 schema descriptions, no annotations, no output schema), the description is incomplete. It explains the core functionality and mentions a sibling preference, but fails to describe many parameters, error handling, prerequisites, or output format beyond a data_ref. Significant information gaps remain 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% for 13 parameters. The description only clarifies a few: scenarios (need alias), dimensions (optional breakdown by period or cost centre), and statement type (implicitly P&L/variance/exec summary). The remaining parameters like scale, layout, target, filters, decimals, filename, overwrite, sheet_name are not explained at all. This is insufficient given the schema's lack of descriptions.

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 returns raw figures. It specifies rows are statement lines and columns scenarios, with optional dimension breakdown. The mention of preferring 'full_pnl' for unspecified general P&L hints at distinction from siblings, but it does not fully differentiate from the similar 'run_statement' tool. Overall purpose is specific and understandable.

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

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

The description provides a specific guideline: prefer 'full_pnl' when a general P&L is needed and listed by precis_orientation. It advises giving scenarios user-facing aliases. However, it lacks explicit when-to-use vs. alternatives like 'run_statement' or 'run_metric', and no when-not-to-use guidance is 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?

No annotations provided, so description bears full burden. Only states it's a search, no details on pagination, error handling, auth requirements, or safety. Minimal behavioral disclosure.

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 concise sentence, front-loaded with action and purpose. No redundant 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 no output schema and minimal parameter info, description is insufficient for an agent to invoke correctly. Missing details on parameter formats, defaults, and behavior.

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

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

Schema has 0% description coverage and no parameter descriptions. Description only mentions hierarchies without explaining the three parameters (limit, query, dimension). Fails to add meaningful semantics beyond parameter names.

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?

Clearly states verb 'search', resource 'dimension hierarchies', and purpose 'to find valid codes and ids before composing a query'. Distinguishes from sibling tools like run_statement 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?

Gives a clear usage context: before composing a query. Does not explicitly mention when not to use or list alternative tools, but the purpose is well-defined.

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