Open Economics

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful scope context beyond that: it enumerates the metadata categories returned and states the one thing the tool will not do (fetch observations).

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

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

Two sentences, zero filler. The positive scope is front-loaded and the exclusionary clause comes last, which is the right ordering for routing.

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

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

Return values are covered by the output schema, so the description need only state purpose and boundary. For a single-parameter, read-only lookup it does exactly that, leaving no gap an agent would need filled before calling it.

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

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

Schema coverage is 100% with a regex pattern and worked examples for dataset_id, so the schema carries the parameter burden. The description only restates that the value is an exact ID from search_official_data, adding no format or schema detail beyond it.

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 (get) plus resource (identity, publisher, collection, provenance, query capability, series shortcuts for a dataset ID) — an agent can see exactly what comes back. The closing sentence 'This does not fetch observations' cleanly separates it from the get_* siblings that return 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?

Explicitly ties the input to search_official_data ('an exact dataset ID returned by search_official_data') and rules out the data-fetching case. It stops short of naming which sibling to use instead for observations, but the implication (the get_* tools) is unambiguous.

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 readOnly, idempotent, non-destructive, openWorld. The description adds real behavioral context: results are auditable aggregates that deliberately exclude station identity and addresses while retaining sample count and source URL, which signals a privacy-conscious aggregation layer rather than raw observations.

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 purpose then usage then return shape. Each sentence carries distinct information (what, when, what comes back) with no repetition of structured fields.

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 10-parameter tool with an output schema present, the description covers the key conditional logic (year/month pairing) and the aggregation/privacy posture, leaving per-field syntax to the 100%-covered schema. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: the year/month coupling (both-or-neither) and the meaning of the default (rolling latest four weeks, published monthly files from 2023). That goes past the per-field 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?

States a specific verb (retrieve) and resource (auditable fuel and GLP price statistics) with the source qualifier (official ANP station observations). This is clearly distinguishable from sibling dataset tools like get_bcb_series or get_comexstat_data by domain.

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 explicit conditional usage: omit year and month for the rolling latest four weeks, or provide both for a published monthly file from 2023 onward. It does not name sibling tools as alternatives, but the domain is distinct enough that routing is unambiguous.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it discloses that the payload is metadata (including warnings and coverage dates) rather than observations, which clarifies the nature of the call.

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

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

Two sentences, no filler, with the capability and its returned fields front-loaded and the usage condition second. 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?

An output schema exists, so return values need not be explained, yet the description still surfaces the salient fields. Combined with annotations covering safety and a fully documented single parameter, nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100% and the single dataset_id parameter is fully documented with its pattern and provenance (returned by search_official_data). The description's "exact BCB SGS series" reinforces the exact-match requirement but adds no syntax beyond the schema, so baseline 3 applies.

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

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

States a specific verb (fetch) and resource (authoritative metadata for a BCB SGS series) and enumerates the fields returned (name, hierarchy, periodicity, unit, decimals, formula, warnings). It explicitly distinguishes itself from observation retrieval, so an agent can separate it from get_bcb_series.

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?

"Use when interpreting a BCB series without retrieving observations" gives a clear use condition and implicitly contrasts with the observation-fetching sibling, though it never names get_bcb_series or states exclusions (e.g. when to prefer describe_official_dataset).

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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuine behavioral context beyond that: data is returned with dates, units, periodicity, source, and raw values preserved, and no transformations are guessed. This tells the agent what arrives unmodified, which the annotations do not.

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 the purpose front-loaded and the prerequisite in the second sentence. Every clause carries information, though 'authoritative schema metadata' and the closing phrase about not guessing transformations are slightly redundant with adjacent statements.

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

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

With an output schema present, rich annotations, and full parameter coverage, the description only needs to supply the prerequisite and fidelity context, which it does. The one remaining gap is disambiguating itself from get_bcb_schema, which it leaves unaddressed.

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

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

Schema description coverage is 100%, so all five parameters (dataset_id, start, end, limit, order) are already documented in the schema, including defaults, patterns, and enum. The description only alludes to dates being preserved and does not add format or usage detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Retrieve official observations and authoritative schema metadata') for an exact BCB SGS dataset ID, which is concrete. However, the phrase 'and authoritative schema metadata' blurs the line with the sibling get_bcb_schema, and the description never resolves that overlap, so an agent cannot fully separate the two from text alone.

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?

It gives an explicit prerequisite and ordering: 'Use only after search_official_data identifies the series,' which clearly sequences this tool behind the search tool. It does not, however, say when to prefer this over get_bcb_schema, which is the closest-looking 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, idempotentHint, and openWorldHint, so the baseline is lower. The description adds that the slice is 'bounded' and 'explicit' and that certain fields 'remain attached to the result', which gives some behavioral context about output structure. However, it lacks details about rate limits, pagination, or authentication, and much of the behavioral profile is already covered by 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?

Two concise sentences with no waste. The first sentence front-loads the core operation and scope, and the second provides necessary usage and output context. Every part earns its place.

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

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

Given the complexity (9 parameters, nested filters, annotations, and an output schema), the description provides essential guidance: the data source, time range, prerequisite, and that fields remain attached. It doesn't need to explain return values due to the output schema. It could mention limitations like max dimensions or filters, but it's largely complete.

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

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

Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description mentions selecting 'period, dimensions, metrics, and optional official filter codes', which is a high-level summary that doesn't add syntax or format details beyond the schema. When schema does the heavy lifting, a baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Retrieve a bounded, explicit MDIC Comex Stat export or import slice from 1997 onward'), which clearly identifies the operation. It doesn't explicitly differentiate from siblings like get_ibge_data or get_siconfi_data, but the specificity of 'Comex Stat' and 'merchandise trade' makes its purpose clear.

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

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

Provides a clear prerequisite: 'Use comexstat:general only after search_official_data.' This tells the agent when to use this tool relative to a sibling. However, it doesn't mention when NOT to use it or other alternatives, so it falls short of a 5.

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 readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely useful data-semantics beyond that: net assets and flows are additive across rows, quota values are fund-level only, and holder totals are not deduplicated — non-obvious interpretation caveats an agent would otherwise get wrong.

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

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

Two sentences, no filler. The primary retrieval modes are front-loaded, with the data caveats packed into a compact trailing clause. Every phrase 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?

With an output schema present, return-shape explanation is unnecessary, and the description covers both operating modes plus the key interpretation pitfalls. What is missing is small routing guidance — when to reach for the schema sibling or the search tool — but for an 8-parameter read tool this is close to complete.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description earns an extra point by explaining what breakdown actually selects and by clarifying the aggregation-level semantics that the schema only states mechanically ('aggregate by official classification or resolve a fund'). It still does not speak to limit defaults or the maxItems caps.

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 two concrete verbs and resources: 'Retrieve daily CVM aggregates by official fund classification' and 'resolve a fund/class latest report by CNPJ or name.' The two modes map cleanly onto the breakdown enum, and the sibling get_cvm_investment_funds_schema is clearly the schema companion rather than a competitor.

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 that aggregation vs. single-fund resolution is chosen by which lookup key you supply (classification vs. CNPJ/name), and the schema notes query is only valid with breakdown=fund. But there is no explicit when-to-use guidance, no mention of when to prefer the schema sibling, and no stated 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?

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description needn't restate that. It adds useful framing that this returns a contract/constraint description rather than data, but attaches no behavioral caveats beyond that scope statement.

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

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

Two sentences, both loaded with content: the first enumerates what is inspected, the second states when to use it. Nothing is redundant, though the enumerated list is packed densely without prioritization.

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

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

With an output schema present, the description needn't explain return values, and the annotations cover the interaction profile. The one gap is the absence of an explicit pointer to get_cvm_investment_funds as the intended follow-up, which would have closed the loop fully.

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

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

Only one parameter exists and the schema documents it fully (100% coverage), including the const value. The description adds no parameter-level information beyond what the schema already provides, so the baseline 3 applies.

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

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

The description names a specific resource and enumerates what the inspection covers: the daily-report window, official classifications, fund-search contract, measure meanings, and aggregation constraints. The tool name and sibling set (e.g., get_bcb_schema, get_siconfi_schema) make the *_schema convention clear, so the sibling distinction is signaled by naming rather than by explicit contrast in the description.

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?

It routes the agent to the right moment to call the tool – 'Use before querying a fund by name or comparing classes' – which clearly implies get_cvm_investment_funds is the subsequent call. However, it does not name that sibling explicitly or state exclusions, so it falls short of a 5.

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 readOnly/idempotent/non-destructive/openWorld=false, so safety is covered. The description adds genuine behavioral context beyond that: the response identifies the exact synchronized official workbook version and discloses aggregation across source system rows, which is provenance information an agent would not otherwise have.

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, no filler, front-loaded with the resource and time span before the filtering guidance. Slightly dense jargon ("synchronized official workbook version") but each sentence 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?

With an output schema present, return-value explanation is not needed, and the description covers scope, filters, and data provenance. Only the absence of routing guidance relative to sibling tools keeps it short of complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The prose adds only marginal meaning over the schema — the 2004 lower bound and the UF/region/state geography framing — while mostly restating the filter parameters already fully documented in the schema.

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

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

States a specific verb (retrieve) plus resource (monthly EPE electricity consumption and consumer counts) and scope (from 2004 onward). The EPE dataset naming cleanly separates it from the many other Brazilian official-data siblings (BCB, IBGE, CVM, Tesouro, etc.).

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 tells the agent what to select (bounded period, geography, classes, market) but never says when to prefer this tool over search_official_data or describe_official_dataset, nor any exclusions or prerequisites. Usage is implied by the dataset name rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond that by enumerating the return shape (variables with classification selections, geographies, observations) and by stating that official suppression, missing, quality-flag, and zero states remain distinct — semantics an agent would otherwise have to guess.

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 dense sentences with no filler: the first front-loads the action and its prerequisite, the second enumerates output composition and state semantics. 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?

With an output schema present, the description need not detail return values, yet it still communicates the important semantic point that missing/suppressed/zero states are distinct — a common source of misinterpretation. For a five-parameter, schema-covered read tool this is largely sufficient, though it omits any note on result size or pagination limits.

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

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

Schema description coverage is 100%, so all five parameters (periods, locality, variable, dataset_id, classification) are already documented with patterns and examples in the schema. The description adds only the general notion of an 'explicit slice' and does not explain period shorthand, geography nesting syntax, or the pipe-delimited multi-ID convention beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb (Retrieve) and resource (an explicit slice of an IBGE aggregate), with the qualifier 'explicit slice' signaling that broad discovery is out of scope. Sibling differentiation is only implicit, via the reference to inspecting the schema first, rather than naming get_ibge_schema or search_official_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?

The phrase 'after inspecting its schema' establishes a clear prerequisite workflow step and implicitly routes the agent to the schema-inspection sibling before calling this tool. No explicit when-not-to-use guidance or named alternative is given, so it falls short of the top band.

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, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by explaining the tool's preventive role: it stops agents from guessing a measure or dimensional slice before requesting data.

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

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

Two tightly written sentences. The first states what the tool returns; the second gives the ordering rule and the exception. No filler or repetition.

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 one required parameter, full schema coverage, rich annotations, and an existing output schema, the description supplies the needed call workflow and prerequisite. An agent has enough context to invoke it correctly and knows when it must be used.

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

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

The single parameter has 100% schema description coverage, including the exact pattern and source from search_official_data. The description reinforces that the dataset_id comes from search_official_data but adds no further syntax or format detail beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource: 'Fetch official metadata for an IBGE aggregate.' It clearly distinguishes itself from sibling data tools like get_ibge_data and from search_official_data by specifying that it returns metadata for an aggregate selected by the search tool.

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

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

Explicitly gives when-to-use guidance: 'Always use this before get_ibge_data unless the official variable, locality, and classification IDs are already known.' It names the alternative tool and the condition under which it can be skipped, leaving little 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 cover read-only/idempotent/non-destructive, so those need no restating. The description adds genuinely non-obvious behavior: the data is *revised* monthly, it tracks the MTE workbook vintage, and combinations (state-by-industry) are never synthesized. That is real value beyond the 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?

Three tightly packed sentences: measures/scope first, the breakdown constraint second, the fidelity caveat last. Every sentence carries information, with only minor density issues from the compound noun lists.

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

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

With an output schema present, return formatting need not be described, and the description covers scope, granularity constraint, and data fidelity. The one notable omission is any pointer to the sibling schema tool that supplies the valid industry IDs, which the agent needs for the industries parameter.

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

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

Schema coverage is 100% and the enum for breakdown plus the state/region enums are fully documented in the schema, so the baseline of 3 applies. The description reinforces the one-breakdown-at-a-time rule but adds no syntax, defaults, or format detail beyond what the schema already states.

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

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

Specific verb (retrieve) plus the exact resource and the measures returned (Novo Caged stock, admissions, dismissals, balance, relative change) with a stated time floor of 2020. It does not, however, name or distinguish itself from the sibling get_mte_formal_employment_schema, which an agent could easily confuse with this query tool.

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

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

'Select exactly one official breakdown' and 'never synthesizes state-by-industry values' give the agent a real invocation constraint. There is no explicit when-to-use/when-not guidance, and no routing to the schema sibling for valid industry IDs, so usage is implied rather than fully specified.

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 readOnly/idempotent/non-destructive, so safety is covered. The description adds real informational value: source vintage, measure meanings, available industry IDs, and the cross-table geography/industry constraint, which the agent would not know from annotations alone.

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

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

Two tight sentences with no filler; the list of returned contents is efficiently packed and the usage cue is placed last. Minor density of domain jargon keeps it from a 5.

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

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

An output schema exists, so return values need not be re-explained. The description covers purpose, contents, and usage adequately for a single-const-param introspection tool, leaving only minor gaps (no sibling routing).

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?

Single parameter with 100% schema description coverage; the const dataset_id is fully explained by the schema. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Inspect) and resource (Novo Caged selection contract) and enumerates the contents returned (measure meanings, industry IDs, constraints). It is clearly distinguishable from the sibling get_mte_formal_employment, though the phrase 'selection contract' is somewhat jargon-heavy.

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 usage condition: 'Use before an industry query.' That is actionable timing guidance, but it names no alternative and offers no when-not-to-use clause, so it falls short of the 5 level.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value beyond them by stating it preserves raw account/column/annex/period/entity fields and upstream provenance without aggregating or substituting concepts, telling the agent the data is faithful and unmodified.

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 compact sentences with the retrieval scope front-loaded followed by the schema-inspection directive and the fidelity guarantee. No wasted text, though the middle imperative slightly interrupts the flow.

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 annotations, a rich fully-documented schema, and an output schema, the description need not explain return values. It covers purpose, prerequisite, and data-fidelity behavior, leaving only sibling differentiation as a 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?

Schema description coverage is 100% with all nine parameters documented and four enums, so the schema does the heavy lifting. The description reinforces that account, column, annex, period, and entity fields are preserved but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Retrieve) and resource (official SICONFI DCA, RREO, RGF, or entity-registry selection), which lets an agent identify the domain. It does not clearly distinguish this tool from the sibling get_siconfi_schema, 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?

'First inspect the schema' hints at the get_siconfi_schema/get_bcb_schema-style prerequisite pattern, which is useful implied guidance. However it never states when to prefer this over search_official_data or describe_official_dataset, nor any exclusions.

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

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

Annotations already declare a safe, idempotent read (readOnlyHint, idempotentHint, openWorldHint=false), so the safety profile is covered. The description adds real context: it discloses that the fields surfaced are the selection dimensions needed downstream and that the ID must come from search_official_data, though it says nothing about error behavior on a non-matching 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?

Two tight sentences: the first defines the tool, the second gives the workflow rule. Nothing is padding, and the purpose is 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?

With an output schema present, return values need not be explained; the description covers purpose, provenance of the input, and sequencing. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and the single parameter's description ('Exact SICONFI dataset ID returned by search_official_data') already conveys format and source. The description largely restates that same guidance, so the schema does the heavy lifting — baseline 3.

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

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

States a specific verb (Get) and resource (meaning and required selection fields for an exact SICONFI dataset), and ties it to the sibling that produces the ID (search_official_data) and the sibling it precedes (get_siconfi_data). An agent can distinguish it from the other *_schema and get_*_data tools 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?

Explicitly says to use it before get_siconfi_data and explains why (so entity, period, report type, branch, and annex are explicit rather than guessed). That names both the alternative and the condition that selects it.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: results are per-table, one table per call, and units are table-specific and must not be aggregated across tables.

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 that are fully front-loaded: the retrieval scope comes first, then the critical units caveat. Every clause carries informational weight with 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?

With an output schema present, a fully documented 7-parameter schema, and complete annotations, the description need only convey scope and the table-isolation rule, which it does. The only gap is the missing pointer to the sibling schema tool for discovering category IDs.

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

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

Schema description coverage is 100%, so the baseline is 3; every parameter (from/to, limit, query, table, categories, dataset_id) is documented in the schema itself. The description adds only the table-level scoping constraint, not format or semantic detail beyond the schema.

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

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

States a specific verb (Retrieve) and resource (official monthly RMD table), and enumerates the six concrete table variants the agent can request. However, it does not explicitly name its closest sibling get_tesouro_dpf_schema, which the parameter schema relies on for category IDs, so sibling differentiation is only implied.

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?

"Retrieve one ... table at a time" and "units ... are never combined" convey an important usage constraint, but the description never says when to call this versus get_tesouro_dpf_schema (to discover categories) or when to prefer a different dataset tool. Usage is implied rather than 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds content context ('versioned', 'methodological constraints') but says nothing about behavioral traits such as return size, whether all six tables are always returned, or pagination. With annotations carrying the safety burden, a 3 is appropriate.

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

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

A single sentence that leads with the object of inspection and front-loads the six-table scope. It is efficient, though the list of distinct attributes makes it slightly dense without being wasteful.

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

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

An output schema exists, so return-value details need not be spelled out, and the description covers the breadth of what the schema exposes (tables, units, IDs, definitions, publication, constraints). It is nearly complete for a schema-introspection tool, missing only an explicit statement that it returns metadata rather than observations.

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 effectively one parameter with an enforced const value and 100% schema description coverage, so the schema does all the work. The description adds no syntax, value, or semantics beyond what the schema states, making the baseline 3 correct.

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

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

The description names a specific action and enumerates the artifact's contents (six versioned RMD annex tables, units, coverage, category IDs, holder definitions, source publication, methodological constraints), which is concrete enough to signal it exposes schema/metadata. However, it never explicitly differentiates itself from the sibling get_tesouro_dpf (the data fetcher) or states that it returns schema rather than data, leaving the agent to infer the schema-vs-data distinction from the name alone.

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 'before selecting data' gives an implied sequencing hint (call this prior to picking a data query), which is useful. But it names no alternative tool and gives no explicit when-not-to-use case, so the guidance stays at the implied level.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description adds real behavioral context on top: values are monthly and current-value (nominal, not deflated), coverage starts in 1997, and the default account set is a specific fixed list. These details materially affect how results should be interpreted.

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 dense sentences with no filler. The default-result behavior is front-loaded, followed by the two selection mechanisms — exactly the order an agent needs to decide whether to pass parameters at all.

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

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

An output schema exists, so return values need no explanation, and full schema description coverage handles parameter mechanics. The description supplies the remaining interpretive context (time coverage, nominal values, default aggregate set) needed to call the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents every parameter and a 3 is the floor. The description adds meaning the schema does not: the default response is the five named aggregates, 'query' searches account labels, and 'accounts' takes exact IDs sourced from the schema tool. That is genuine value beyond the structured fields.

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 ('Retrieve monthly current-value RTN accounts') and pins the scope with 'from 1997 onward'. The title adds the domain (government central revenue/expenditure), so the agent knows exactly what data set this returns, though it never explicitly names the sibling get_tesouro_rtn_schema as its companion beyond an oblique 'account IDs returned by get_tesouro_rtn_schema' reference in the 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?

Explains default behavior (returns the five headline aggregates) and the two ways to get detail — select exact account IDs or search labels. This gives an agent clear routing for the common 'default vs. drill-down' decision. It stops short of explicit when-not guidance or naming an alternative tool for other use cases.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds the domain-specific detail that the output includes vintage/coverage/constraint metadata, but says nothing about auth needs, rate limits, or output size — adequate but not rich for a metadata tool whose annotations carry the safety profile.

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

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

Two sentences, zero filler: the first lists what is inspected, the second gives the usage trigger. Front-loaded with the resource and its contents, then the action instruction.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description is complete enough for a fixed-argument, read-only metadata tool. The only minor gap is that the caller learns nothing about the shape or size of what is returned before invoking it.

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

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

There is a single required dataset_id parameter, fully documented at 100% schema coverage with a const value, so the schema already carries the semantics. The description adds no information about the parameter, which is the expected baseline when structured data does the work.

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

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

The description opens with a concrete verb (Inspect) and enumerates exactly what metadata is returned: account IDs, hierarchy, unit, coverage, source vintage, and above/below-the-line constraints. It is clearly the schema/metadata counterpart to get_tesouro_rtn, though it never names that sibling explicitly, leaving the differentiation 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?

"Use before selecting revenue or expenditure categories" gives a clear sequencing rule that positions the tool relative to downstream data retrieval. It states when to use the tool but offers no explicit when-not or named alternative, so it stops short of full 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: ranking of candidates, confidence signal, reporting of missing source integrations, and an explicit unresolved/partial state that tells the agent results may be incomplete.

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

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

Two dense sentences with zero filler, front-loaded with the 'start here' routing instruction and the query-language constraint. Every clause carries usable 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?

An output schema exists, so the enumerated return contents (ranked datasets, confidence, unresolved state) are a bonus rather than a necessity, and annotations cover the safety profile. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented and the baseline is 3. The description adds meaningful semantics beyond the schema by specifying that the natural-language query is accepted in Portuguese or English, which is not stated in the schema.

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

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

The description states a specific verb+resource ('search' Brazilian official economic data) and scopes it precisely as a natural-language concept resolver rather than a data fetch. 'Start here' plus the explicit unresolved/partial return state clearly separates it from the get_*_data siblings that require a known dataset ID.

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?

It gives a clear when-to-use rule: before any data query when the exact official dataset ID is unknown, and it accepts both Portuguese and English input. It does not explicitly name the follow-up sibling (e.g., describe_official_dataset) or state when NOT to use it, so it stops just short of full when/when-not/alternative coverage.

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