Précis Finance MCP

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them by disclosing that transform_code is a 'bounded JavaScript function', that the transform consumes exactly one result per ref, and that output is flat rows. That is genuine behavioral context not present in the structured fields.

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?

Three sentences, front-loaded with the core action and its inputs, with no filler. The supported-chart-type list is long but earns its place by defining chart_spec's domain. Slightly list-heavy but structurally sound.

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

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

With no output schema, the description carries the return burden and does address it ('returns flat rows'). For a 3-required-param tool with 0% schema coverage it covers the two most opaque parameters and the chart types. Minor gap: chart_spec's own keys and any size/rate limits on the bounded JS are unaddressed.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden. It explains data_refs as 'an array of snapshot IDs' and transform_code as a 'bounded JavaScript function', and the chart-type enumeration effectively documents chart_spec's valid values. It does not describe chart_spec's internal structure, so it is not a full 5.

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

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

States a specific verb+resource ('Create a chart') and enumerates exactly what it is built from (data_refs, a bounded JS function, chart_spec). An agent can distinguish it from dataframe-oriented siblings like run_metric_data or inspect_rows. It stops short of explicitly naming which sibling to use instead, so it does not reach the sibling-differentiating 5.

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

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

'Query first and inspect rows' implies a prior workflow step, and 'the transform takes one result per ref' hints at the input contract. However it never names the concrete alternatives (e.g. inspect_rows, run_statement_data) or states when NOT to use this path, leaving routing to inference.

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 annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the description must, and does, add real behavioral context: the result is a temporary file plus a download link. It does not disclose file lifetime/expiry, permission requirements, or rate limits, so it is not exhaustive. No contradiction with the write-and-create-a-file profile implied by readOnlyHint=false.

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

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

A single sentence that front-loads the action and resource before the constraint and the return, with no filler. Every clause (cached, no rerun, formats, temp file + link) carries 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 two-required-parameter tool with no output schema, the description covers the action, both parameters, the accepted format values, and the return shape (temporary file and download link). Remaining gaps like link expiry and where data_ref originates are minor but not zero.

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% with no enums, so the description carries the full burden. It qualifies data_ref as "cached" (not an arbitrary id) and enumerates the accepted format values json or xlsx, which the bare schema does not provide. It does not describe the shape or provenance of data_ref further.

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

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

States a specific verb (Export), a specific resource (a cached data_ref), and the two output formats, plus the key scoping nuance that it does not rerun the query. It is clearly distinguishable from siblings like run_metric_data or run_statement, though it never names a sibling explicitly.

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

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

"Without rerunning the query" implies the intended use case is reusing an already-computed result, which is useful context. However, it gives no explicit when-not guidance, no prerequisites (where a valid data_ref comes from), and no named alternative such as running the metric fresh instead.

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

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

Annotations already cover read-only, non-destructive, closed-world reads, so the description doesn't need to establish safety. It adds the useful detail about what kind of content comes back, but doesn't cover error behavior when the binding_id is unknown or whether the full extraction config could include secrets/credentials. Adequate with annotations but not rich.

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

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

A single front-loaded sentence with zero waste, leading with the verb and adding just enough scope detail. Every clause earns its place.

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

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

No output schema, low parameter documentation, and no annotations covering return shape beyond safety. For a config-fetch tool an agent needs to know the binding_id format and roughly the response structure. The description lists config areas but leaves the identifier semantics and failure modes unaddressed.

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

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

There is one parameter, binding_id, and schema coverage is 0%: the schema gives no description at all. The description only implies the identifier selects a data feed, but doesn't say whether it's a UUID, name, or slug. It finds some meaning but doesn't compensate for the coverage gap.

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

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

We asks for a specific verb (Fetch) and resource (one data feed's full configuration), and it enumerates the content returned (source, target, schedule, extract parameters). It's clear it retrieves a single binding, implicitly distinct from list_bindings although it doesn't name that sibling explicitly.

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

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

Implied usage: fetching a single feed's configuration by id. There's no explicit when-to-use versus list_bindings, and no prerequisites or exclusions stated. A reasonable agent can infer the single-vs-list distinction, but the description doesn't route explicitly.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the "available, owned" eligibility condition; it says nothing about what the renewed capability looks like, whether it expires, or whether prior download links are invalidated.

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

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

A single tight sentence with no filler and the key qualifier up front. It is efficient, though the brevity is closer to under-specification than true economy.

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

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

With no output schema, no parameter documentation, and no annotations covering return semantics, the description should explain what the agent receives back. It does not, and the mismatch between the name get_file_download and the verb "Renew" leaves the contract ambiguous.

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

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

Schema description coverage is 0% for the single required parameter file_id, so the description carries the burden and does not compensate. It never states what file_id is (numeric ID, path, UUID) or how to obtain a valid one.

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 names an action ("Renew") and a resource ("download capability for an available, owned artifact"), but the phrasing is abstract and does not match the tool name's implied "get a file download". An agent cannot tell whether this returns a URL, a token, or file bytes, and none of the sibling tools clarify the boundary.

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 only usage signal is the qualifier "available, owned artifact", which hints at a precondition but never states when this tool should be used versus alternatives. There is no mention of when-not to use it or what to do if the artifact is unavailable or unowned.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no note on behavior for an unknown source_key, no caching/freshness context, and no return shape. It is consistent but purely additive-free.

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

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

A single front-loaded sentence with zero filler. Nothing could be removed without losing meaning.

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 whose sole purpose is returning a schema, the description does not describe the return shape or units an agent should expect, and there is no output schema to compensate. The lone parameter is undocumented at 0% coverage, leaving the description under-specified for correct 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%, so the schema gives no meaning for source_key. The phrase 'inspection source' loosely ties the parameter to that concept, but the description omits format expectations, where valid keys originate, and that the parameter is required.

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

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

States a specific verb (get) and resource (column schema for an inspection source), which implicitly distinguishes it from siblings like list_inspection_sources (lists sources) and inspect_rows (returns rows). However, it never names or contrasts with those siblings explicitly, so the differentiation is left to inference.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. An agent must guess that source_key comes from list_inspection_sources and that this tool is a prerequisite step before inspect_rows.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by enumerating the return payload (timestamps, status, rows landed, error message), which matters because no output schema exists; it does not, however, describe failure behavior for an unknown id.

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, front-loaded with the verb and resource, and every clause carries information. No 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 single-record read with full annotation coverage, the description supplies the return fields that the absent output schema would otherwise need to carry. The remaining gap is error/not-found behavior, which is minor here.

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 single parameter is documented only as 'Load Id' in the schema. The description repeats that load_id is the key but adds no format or provenance detail (e.g., where a load_id comes from, whether it is a UUID).

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

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

States a specific verb (fetch), resource (one data load), and lookup key (load_id), and enumerates the returned content. It implicitly separates itself from the sibling list_load_history by scoping to a single load, though it never names that sibling explicitly.

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

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

Usage is only implied: the requirement of a load_id signals a targeted single-record lookup rather than a browse. There is no statement of when to prefer this over list_load_history or what to do if the load_id is unknown.

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

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

Annotations already declare this is a safe read-only, non-destructive, closed-world operation, so the safety bar is pre-covered. The description adds genuinely useful behavior beyond that: results are a 'capped sample' (truncation/limit semantics) delivered in two forms, a reasoning sample plus a user-facing grid, plus the precondition that the source must be enabled.

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

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

Two tight sentences with zero filler; the core action is front-loaded and the return behavior follows immediately. Every clause carries 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?

There is no output schema, so the description does well to sketch the return shape (capped sample + grid). However, with seven undocumented parameters and no stated usage context, an agent still lacks enough to construct a correct call for anything but the two required fields.

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?

Seven parameters with 0% schema description coverage, and the description only gestures at two of them ('source' and the cap implied by 'capped sample'). It never explains scenario_id, columns, filters, period_start, or period_end, which is a substantial compensation gap for a schema that documents nothing.

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

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

States a specific verb and resource ('inspect the row-level detail behind a figure'), which clearly distinguishes it from aggregate siblings like run_metric or run_statement_data. The domain term 'figure' and 'inspection source' are somewhat jargon-y but the core action is 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 phrase 'from an enabled inspection source' implicitly signals a prerequisite (the source must exist and be enabled, likely via list_inspection_sources/get_inspection_schema), but it never states when to reach for this tool versus get_inspection_schema or run_metric_data. No explicit when/when-not guidance or named 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful detail about the content of the listing (schedule, source, frequency), but does not disclose operational traits such as pagination, filtering behavior, or rate limits beyond what annotations provide.

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 zero waste. The em dash elaboration adds useful specificity without padding.

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

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

There is no output schema, and the description does explain what the listing contains, which is helpful. However, the two optional filter parameters ('target' and 'source_id') are completely undocumented in both schema and description, leaving an agent unable to use them correctly. For a list tool with filtering options, this is a significant gap.

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

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

The schema has 0% description coverage for its two parameters ('target' and 'source_id'), and the description does not mention either parameter at all. With no parameter documentation anywhere, the description fails to compensate for the complete lack of schema semantics.

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

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

The description states a specific verb ('List') and resource ('configured data feeds (ingestion bindings)') and elaborates on what is included ('schedule — which datasets load, from where, how often'). It clearly distinguishes the tool as a list operation, but it does not explicitly contrast with the singular sibling 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 listing verb implies a general use case, but there is no explicit guidance on when to use this tool instead of alternatives like get_binding or other list_* siblings. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral context beyond that: it is a catalogue-level read that returns keys, labels and kind classification rather than members, which sets the correct expectation about result scope.

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

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

Two tightly constructed sentences, front-loaded with the primary action; the sibling hand-off comes second and nothing is redundant.

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

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

There is no output schema, but the description compensates by naming the returned fields (keys, labels, kinds) and the kind taxonomy. For a zero-parameter, read-only catalogue tool this is sufficient for correct 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?

The tool takes zero parameters (100% trivial coverage), so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies no filtering input 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?

States a specific verb and resource (list dimensions defined in the model) and enumerates what is returned (keys, labels, kinds). It also names the sibling search_hierarchy as the tool for the adjacent task, so an agent can distinguish the two without opening schemas.

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 scopes usage as catalogue metadata only and routes member-listing to search_hierarchy. It does not address when this catalogue view is preferable to the other list_* siblings (list_kpis, list_variants), but the main ambiguity for this tool is resolved.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no auth prerequisites, no pagination or result-size behavior, no statement of what a 'source' identifier looks like.

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

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

A single front-loaded sentence with no filler and no repetition of the title. It is efficient, though so terse that it borders on under-specification rather than optimal density.

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

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

For a zero-param list tool with no output schema, the description is the only place a caller could learn what the returned sources represent and how they relate to inspect_rows. It gestures at the inspection workflow but never closes the loop, leaving an agent with a minimally sufficient definition.

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 takes zero parameters, so there is no parameter meaning for the description to carry. Baseline 4 applies; no compensating detail is required here.

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

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

States a specific verb ('List') and a qualified resource ('row-level sources available for inspection'), which is enough for an agent to know this is a zero-argument enumeration of data sources. However, it does nothing to separate itself from the many other list_* siblings (list_bindings, list_dimensions, list_kpis), and 'sources' is left undefined.

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 phrase 'available for inspection' hints that this is a precursor step to inspect_rows, so usage is implied rather than stated. There is no explicit when-to-use, no exclusions, and no mention of rival discovery tools such as list_bindings or get_inspection_schema.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds useful content-level context by naming the fields the catalogue exposes, but says nothing about volume, pagination, or ordering.

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

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

A single em-dash-joined sentence with zero filler; the resource is front-loaded and the payload is enumerated immediately after. Nothing could be cut without losing information.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description carries the burden of telling the agent what comes back, and it does so by naming the catalogue fields. Only the absence of any sense of scope (how many metrics, pagination) keeps it from being fully complete.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The mention of formats/domains/dimensions describes return content rather than inputs.

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

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

States a specific verb ('Browse') and resource ('the metric catalogue') and enumerates what the catalogue contains — metric keys, formats, domains, and per-metric dimensions. This distinguishes it reasonably from siblings like list_dimensions, though it never names an alternative explicitly.

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

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

The verb 'Browse' weakly implies exploratory/discovery usage, but there is no statement of when to use this versus siblings such as list_dimensions, run_metric, or search_hierarchy. No prerequisites or exclusions are given, leaving selection entirely to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that this is a historical audit trail rather than current state, but says nothing about pagination behavior, default page size, or result ordering.

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

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

Two tight sentences that lead with the verb and resource, then add concrete usage examples. No filler or restated metadata.

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

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

There is no output schema, and the description does partially describe the returned content, so that gap is half-covered. But for a five-parameter filtering tool with no parameter documentation anywhere, the definition leaves too much to inference about how to narrow the query.

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?

Five parameters with 0% schema description coverage, so the description carries the full burden. It hints at period and status filtering ('when each dataset landed, with what status') but never explains period format, status values, binding_id, dataset_id, or what limit (default 50) controls.

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?

Specific verb+resource ('List data-load attempts from the ingestion audit trail') with the returned fields stated ('when each dataset landed, with what status'). It does not, however, distinguish itself from the sibling get_load_status, which an agent could easily see as the same capability.

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 quoted user questions ('is April in yet?' / 'when was this data last loaded?') imply the right usage context, which is genuinely helpful. But there is no explicit when-not guidance and no routing against the closely related get_load_status sibling.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description contributes minor extra context by stating that status is returned, but says nothing about pagination, ordering, or empty-result 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?

One short, front-loaded sentence with no filler. It is efficient, though extremely terse for a tool whose return content is only hinted at.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description covers what is listed and indicates status is included. A slightly fuller note on the returned fields (e.g. name/id) would close the remaining gap.

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 takes zero parameters, so the baseline is 4. Schema coverage is 100% and there is nothing for the description to disambiguate; no param meaning is missing.

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?

Specific verb + resource: 'List the available planning scenarios' plus what is returned ('their status'). It is clearly distinguishable from the other list_* siblings (list_bindings, list_dimensions, list_kpis, list_variants), though it never explicitly names or excludes an alternative.

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

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

No when-to-use, when-not-to-use, or alternative is given. The only implied usage is that it enumerates scenarios, which an agent could infer from the name alone; the description adds no routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the domain notion that variants are 'what-if' objects and says nothing about permissions, scoping, or result shape.

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

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

A single front-loaded sentence with no filler, which is appropriate for a simple listing tool. It is efficient but too sparse to be considered well-structured beyond that.

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

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

For a one-parameter read tool with no output schema, the description should at least clarify what a variant is (identifier, name, what-if branch) and whether results are scoped or paginated. Neither the parameter meaning nor the return shape is addressed.

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

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

The single required parameter scenario_id has 0% schema description coverage and the description does not explain it at all, not even that it identifies the parent scenario whose variants are listed. With one undocumented parameter, the description fails to compensate for the coverage gap.

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

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

States a specific verb (list) and resource (what-if variants of a scenario), so the agent knows it retrieves variants rather than scenarios. It does not explicitly distinguish itself from the sibling list_scenarios, which is the nearest alternative.

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

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

No when-to-use guidance, no prerequisites, and no mention of how this differs from list_scenarios. The agent must infer from the name alone that this is the variant-level listing.

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?

Annotations already declare a safe read-only, non-destructive, closed-world operation, so the safety burden is lifted. The description adds genuinely new behavioral context beyond that: the return is a formatted table with structured data, the widget already renders it to the user, and the agent should interpret rather than echo the table. What it does not disclose is error behavior or how large a breakdown it can handle.

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?

Front-loaded with the core purpose and examples before moving to invocation and output guidance, so the most important information lands first. The closing sentence about not reproducing the table is long but earns its place as an output-behavior instruction; overall there is little 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 no output schema the description usefully defines the table's row/column structure, which covers the return-value gap. However, for an 8-parameter tool with 0% schema description coverage, the description leaves most inputs (filters, period bounds, scale, decimals) unexplained, so an agent cannot fully invoke it from the definition alone.

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% across 8 parameters, so the description must carry parameter meaning itself. It does add real semantics for `scenarios` (array of objects, each needing a user-facing alias) and implies `dimensions`/`metrics` via the row/column description, but `scale`, `decimals`, `filters`, `period_start`, and `period_end` are left entirely undefined in both schema and 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?

States a specific verb and resource ('Break one or more metrics down by a dimension') and reinforces it with four concrete examples (revenue by project, utilisation by employee, headcount trends, GL account drill-down). The output shape ('rows are the dimension; columns are metrics × scenarios') further pins down what the tool produces. It never names or contrasts a sibling such as run_metric_data, so differentiation from the closely named data variant is left to inference.

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 actionable invocation guidance ('Pass `scenarios` explicitly and give every scenario a concise, user-facing `alias`') and one conditional output rule ('unless the user explicitly requests it or the widget is unavailable'). It does not state when to reach for this tool versus run_metric_data or run_statement, so the routing decision remains implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: result shape (rows=dimension, columns=metrics×scenarios), returned artifacts (raw figures plus a `data_ref`), and the constraint that it renders no user-facing table.

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?

Dense but front-loaded: purpose first, then result shape, then the scenarios/alias instruction, then the data_ref handoff. Nearly every sentence carries information, though the scenarios instruction and return-value notes make it longer than strictly necessary.

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 description covers return values and the chart handoff, which partly compensates for the absent output schema. However, for an 8-parameter tool at 0% schema coverage with no output schema, the majority of inputs remain unexplained, so it is only minimally adequate.

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

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

Schema description coverage is 0% across 8 parameters, so the description carries the full documentation burden. It clarifies only `scenarios` (pass explicitly, give each a concise user-facing `alias`) while scale, decimals, filters, dimensions, period_start/period_end, and metrics are entirely undocumented.

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

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

States a specific verb+resource ('break one or more metrics down by a dimension') with concrete examples (revenue by project, utilisation by employee). It also implicitly distinguishes itself from the sibling run_metric by noting it 'does not show the user a table' and returns raw figures instead.

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?

Tells the agent when to reach for it (own analysis, or to build a chart) and names the downstream alternative by instructing the agent to pass `[data_ref]` as `data_refs` to eval_chart_transform. No explicit 'do not use when' clause, but the usage path is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it returns a formatted table with structured data, the widget already renders it to the user, and the agent should add interpretation rather than reproduce rows — non-obvious interaction semantics not derivable from annotations.

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

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

Front-loads what the tool produces, then the alternative, then scenario naming, then the return/rendering contract. Every sentence carries information, though the widget/interpretation guidance runs long and could be tightened.

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?

Behavioral context is strong — return format, widget rendering, and interpretation expectations are all covered despite there being no output schema. However, with 8 parameters and 0% schema coverage, five parameters (scale, decimals, filters, period_start, period_end) remain opaque, which is a real gap for a tool whose whole job is parameterized statement generation.

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% across 8 parameters, so the description must carry the load. It clarifies `statement` (P&L, variance, exec summary), `scenarios` (columns, with a required user-facing `alias` like Actuals/Budget/Variance), and `dimensions` (optional breakdown by period or cost centre), but says nothing about `scale`, `decimals`, `filters`, `period_start`, or `period_end` — five undocumented 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?

States a specific verb (run) and resource (financial statement) and immediately enumerates the concrete outputs — P&L, variance report, executive summary — plus the row/column semantics of the result. An agent can distinguish this from run_metric or run_statement_data without opening a schema.

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

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

Gives an explicit routing rule: for an unspecified general P&L, prefer `full_pnl` when listed by precis_orientation. It also prescribes downstream behavior (add interpretation, don't restate the table unless asked or the widget is unavailable). It does not clarify the boundary against the close sibling run_statement_data, which keeps this at 4.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds meaningful context beyond that: it returns raw figures plus a data_ref rather than rendering anything, and states 'Does not show the user a table.' It does not describe failure modes or auth requirements, but the output/behavioral nature is well disclosed.

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 core purpose is front-loaded in the first sentence, and the paragraph covers statement types, row/column structure, dimensions, sibling routing, and chaining without filler. It is slightly dense but each sentence serves a distinct purpose; the alias guidance sentence is the least essential.

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

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

With no output schema, the description appropriately explains that results are raw figures and a data_ref, covering return-value expectations. However, for an 8-parameter, 0%-coverage tool with complex financial semantics, the undocumented parameters (scale, decimals, filters, period range) leave the agent under-equipped to invoke it correctly.

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

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden. It meaningfully documents statement (P&L/variance/exec summary), scenarios (columns, alias), and dimensions (breakdown by period or cost centre), but leaves scale, decimals, filters, period_start, and period_end entirely unexplained, so roughly half the parameters remain opaque.

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

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

States a specific verb and resource ('Run a financial statement — P&L, variance report, or executive summary') and describes the resulting structure (statement lines as rows, scenarios as columns). It explicitly distinguishes its behavior from the display variant by noting 'Does not show the user a table,' so an agent can tell it apart from run_statement and run_metric_data.

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 routing rule ('For an unspecified general P&L, prefer full_pnl when it is listed by precis_orientation') and a downstream chaining instruction ('pass [data_ref] as data_refs to eval_chart_transform'). It also tells the agent to assign user-facing scenario aliases. It stops short of enumerating when-not-to-use for the other statement types, but the primary selection context is explicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered elsewhere. The description adds that the call returns valid codes and ids, a small amount of output context, but says nothing about pagination, match semantics, or behavior when query/dimension are omitted.

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

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

A single compact sentence with the purpose front-loaded and no filler. It is efficient but arguably too terse for the amount of undocumented surface it must carry.

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 0% schema coverage, no output schema, and three free-form parameters, the description should do more explaining. It conveys the discovery intent but leaves an agent guessing about argument formats and result shape.

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 three parameters (limit, query, dimension) are undocumented in both schema and description. The description mentions 'dimension hierarchies' conceptually but never explains whether query supports wildcards, what dimension values are accepted, or what limit defaults to.

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

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

States a specific verb (search) and resource (dimension hierarchies) and gives concrete examples (cost centres, accounts), making the target domain clear. It does not explicitly distinguish itself from the sibling list_dimensions, so it falls short of a 5.

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

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

'before composing a query' implies the workflow slot (discovery step preceding query composition), which is useful implied usage. However, it never names alternatives such as list_dimensions or list_variants, nor states when not to use this tool, so guidance remains implicit.

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