site

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

With no annotations and no output schema, the description carries the full disclosure burden, and it does describe the payload contents (columns, numeric flags, row count, provenance banner). It never explicitly states read-only/safe semantics, but for a zero-parameter inspection call the return-content disclosure is the substance an agent needs.

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

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

Two sentences with zero filler: the return contents are front-loaded, followed immediately by the usage directive. Nothing is repeated from the name or title.

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

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

For a simple no-param, no-annotation, no-output-schema read tool, describing the returned fields is essentially complete coverage. It could go one step further by clarifying how it differs from dataset_stats or dataset_provenance, whose outputs may overlap on row count and provenance.

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 no parameters, so by the rubric this is a baseline 4; there is nothing for the description to clarify beyond what the empty schema already implies.

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 (the Calcul Brut en Net dataset) and enumerates exactly what is returned: column list, which columns are numeric, row count, and the provenance banner. It implicitly separates itself from dataset_stats and dataset_provenance by scoping to schema shape, though it never names those siblings.

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

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

"Call this first to learn the schema" gives concrete ordering guidance for when to invoke the tool relative to the rest of the dataset family. It stops short of naming alternatives or stating when not to use it, so it is clear context rather than full routing.

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

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

No annotations are provided, so the description carries the entire behavioral burden. It does disclose one genuine trait — results come back 'in the order given,' preserving the order of the input values — but says nothing about what happens when a value has no matching row, result limits, or permissions.

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 that leads with the resource and ends with the use case. No filler, though the trailing 'for "X vs Y" questions' is somewhat clipped and reads like a fragment.

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-parameter lookup with no output schema and no annotations, the description covers the core selection logic but omits the return shape, ordering caveats beyond input order, and failure behavior. Adequate to call, but not 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 0%, so the description must compensate. It maps meaning onto both parameters by describing 'the rows whose column is any of the given values,' clarifying that 'values' is matched against 'column' with OR semantics. It adds no format, casing, or value-count guidance beyond what the schema constrains.

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 resource (rows of the Calcul Brut en Net dataset) and the selection rule (column is any of the given values), plus a concrete use case ('X vs Y' questions). It's clear what it retrieves, though it never explicitly distinguishes itself from sibling dataset_search or dataset_row.

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 'for "X vs Y" questions' implies the context of use, giving some guidance. However, it offers no when-not conditions and does not name dataset_search as the alternative for broader filtering, leaving the agent to infer the boundary.

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

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

No annotations are provided, so the description carries the full disclosure burden. In a single phrase it enumerates the four fields returned and frames the tool as read-oriented, effectively standing in for the missing output schema. It does not state that the metadata is static or note any caching/staleness behaviour, which keeps it below a 5.

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 short sentences with no filler: the return content is front-loaded, followed immediately by the reason to call it. Nothing could be removed 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?

With no output schema and no annotations, the description is the only source of return-value information, and it supplies it adequately for a zero-parameter read tool. Only a note on whether the metadata is static or dataset-versioned would make it 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 per the baseline there is nothing for the description to disambiguate and no schema coverage gap to compensate for. It correctly avoids inventing parameter detail that does not exist.

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

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

The description names the specific resource (the Calcul Brut en Net dataset) and enumerates exactly what provenance the tool exposes: source, computed date, licence, citation. It is clearly distinct from siblings like dataset_stats or dataset_columns, though it never names an alternative to sharpen the contrast.

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

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

"Read this to attribute a figure correctly" gives a concrete use case for invoking the tool, which is more than most metadata endpoints offer. It stops short of stating exclusions or pointing to a sibling for related needs, so it is clear context rather than full when/when-not 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that matching is exact and case-insensitive, which is real behavioral information beyond the schema. It says nothing about how many rows can come back, ordering, or pagination, which leaves meaningful gaps for a lookup 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?

A single tight sentence, front-loaded with the resource and constrained by the match semantics. No filler. It is slightly under-formed as a sentence (no explicit verb), but nothing needs to be cut.

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 two-parameter exact-match lookup with no annotations and no output schema, the description covers the core contract but omits return shape (row count, ordering, whether multiple matches are returned). An agent could call it, but would be guessing about the result.

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 both required parameters ('column' and 'value') are undocumented in the schema itself. The description partially compensates by explaining that 'column' names a dataset column and 'value' is compared exactly and case-insensitively, but it never says how column identifiers are formatted or whether unknown columns error. Partial compensation only.

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 the resource (rows of the Calcul Brut en Net dataset) and the exact operation (column equals value, case-insensitive), so an agent knows it is an exact-key lookup. It implicitly contrasts with the fuzzy matching a sibling like dataset_search would do via the word 'exactly'. It stops short of an explicit verb and never names a sibling, so it is clear but not fully differentiated.

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

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

There is no statement of when to use this tool versus dataset_search, dataset_compare, or dataset_top. The only guidance is the implicit 'exact match' cue embedded in the purpose sentence. No prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses two traits: matching is case-insensitive over any cell, and results are capped at 50. However, it says nothing about result ordering, what a returned row looks like, or whether the 50-result cap is a truncation (i.e. silent drop of further matches).

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 zero filler, and the scope ('Calcul Brut en Net dataset') plus the key constraint ('up to 50') are front-loaded. The 'Rows of ...' opening is slightly indirect but nothing is wasted.

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 and no annotations, so the description must stand alone; it covers the match semantics and result cap but omits ordering, return row shape, and truncation behavior. Adequate for invocation but leaves the agent guessing about what comes back.

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 50% and the undocumented 'limit' is partly explained by 'up to 50'. More importantly, the description adds semantics the schema omits: matching is substring-style against any cell and is case-insensitive. That is genuine meaning beyond 'text to look for in any cell'.

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 (the Calcul Brut en Net dataset) and operation (returning rows whose cells contain a query), which is a clear verb+resource statement. The 'whose cells contain the query' phrasing distinguishes it from row-fetching siblings like dataset_row, though it never explicitly labels itself as a search or contrasts with dataset_top/dataset_stats.

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

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

There is no when-to-use or when-not-to-use guidance, and no sibling is named even though dataset_row, dataset_top, and dataset_stats could plausibly overlap. The agent is left to infer that this is the free-text/substring lookup option on its own.

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

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses that grouping commas and currency are handled and that non-numeric rows are excluded and counted, but it does not state that the operation is read-only, how permissions work, what happens on errors, or how the results are structured.

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

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

The description is a single well-formed sentence that front-loads the statistics list, then the data source, then behavioral caveats in parentheses. Every clause carries information and there is 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 tool with no output schema, no annotations, and one required parameter, the description covers the core statistics and two data-cleaning behaviors. However, it omits output shape, error handling, empty-result behavior, and column-discovery guidance, leaving meaningful gaps 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 description must compensate for the single undocumented 'column' parameter. It adds an important constraint by specifying that the column must be numeric and belong to the Calcul Brut en Net dataset, but it does not explain valid column names, format expectations, or how to discover columns.

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 the exact statistics computed and the data source (a numeric column of the Calcul Brut en Net dataset), making the tool's purpose unambiguous. It does not explicitly contrast with sibling tools like dataset_compare or dataset_top, but the numeric-column scope is distinctive enough to separate it from most siblings.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no named alternative tool. The description only states what is returned, leaving the agent to infer when this tool is appropriate versus siblings such as dataset_columns or dataset_top.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses the direction semantics (highest vs lowest) but says nothing about the 50-row cap, null/ties handling, or that this is a read-only operation, leaving meaningful behavioral gaps for a ranking 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?

A single compact sentence that front-loads the core behavior (top/bottom rows by a numeric column) with no filler. Slightly terse for the amount of undocumented behavior it must cover.

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 annotations, no output schema, and one of three parameters undocumented, the description is too thin. It doesn't explain the row shape returned, the limit cap, or what 'column' values are valid, so an agent must infer significant details.

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 33% (only 'ascending' is described). The description partially compensates by stating the column must be numeric and that ordering can be highest or lowest, but it says nothing about the 'limit' parameter's 1-50 range or default behavior, so the gap is not closed.

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: returning the highest or lowest rows of the Calcul Brut en Net dataset ranked by a numeric column. This is clearly distinguishable from sibling tools like dataset_stats or dataset_search, though the description never names or contrasts them 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 parenthetical '"which is the most/least X"' implies the use case (top-N ranking questions), but there is no explicit when-to-use framing, no prerequisites, and no mention of alternatives such as dataset_stats or dataset_search for adjacent needs.

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

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

With no annotations, the description carries the full behavioral burden and largely succeeds: it explicitly negates side effects ("Nothing is bought, ordered or paid"), states cost ("it is free"), and denies a guarantee ("no quote is guaranteed"). It also discloses content the tool surfaces, notably the consent wording and who receives the data — meaningful behavioral context. It stops short of stating permissions or a return 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?

Short and front-loaded with the imperative "Read first." Each clause adds a distinct fact (no purchase, no guarantee, free, return contents). Minor waste in the meta-phrasing "States plainly what submit_enquiry does," but overall tight.

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 exists, so the description must cover returns — it does so by listing recipients, consent wording, and the confirmation mechanism. With zero parameters and a simple advisory tool, this is nearly sufficient; only the exact return format is left unstated, which is acceptable for a descriptive helper.

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, which is the baseline-4 case: there is nothing for the description to disambiguate, and the schema is trivially complete. No parameter 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?

The description states a specific read-only resource: it explains the enquiry flow ("states plainly what submit_enquiry does") and enumerates the content it returns — recipients, consent wording, confirmation path. It is distinguishable from the sibling submit_enquiry because it frames itself as explanatory rather than transactional. It is slightly roundabout by describing a sibling's behavior rather than its own name, but the intent is still recoverable.

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?

"Read first" implies the tool should be consulted before submit_enquiry, giving an implied usage position. However no explicit when/when-not statement or named alternative ordering is given, so an agent must infer that this precedes the write tool. Minimum viable but not directive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the returned data (key, label, type, required, help text, allowed options), which substitutes for the missing output schema, but it says nothing about whether the result is static/cacheable, ordering, or any other operational trait.

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 front-loads what the tool returns, the second gives the downstream action. No padding or restatement of the name.

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 input schema, no annotations and no output schema, the description adequately covers the contract by spelling out the returned field attributes and the handoff to submit_enquiry. Minor gap: the domain term 'Calcul Brut en Net' and the distinction from enquiry_describe are left unexplained.

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 per the rubric the baseline is 4. The description correctly implies a parameterless call and instead spends its words explaining how the returned field keys are consumed downstream.

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?

Names the exact resource (the fields of the Calcul Brut en Net enquiry) and enumerates what each field carries (key, label, type, required flag, help text, allowed options). An agent can tell this is the schema-inspection tool rather than the submission tool, though it never explicitly contrasts itself with the sibling enquiry_describe.

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 second sentence gives concrete routing guidance: read the fields here, then pass answers to submit_enquiry keyed by field key. That establishes the read-then-submit workflow, but there is no statement of when not to use it or how it differs from enquiry_describe.

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

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

With no annotations, the description carries the full burden and does so: it discloses that step 1 only validates and returns a summary, consent line and token; that submission happens only on step 2 with the token; and that an email link must be clicked before any provider sees the enquiry. The definition of consent is spelled out verbatim, which is essential for a tool that sends personal data onward.

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 disambiguating scoping statement, then cleanly organized as Step 1 / Step 2. Dense but every clause is load-bearing; the only minor cost is the quoted consent sentence, which lengthens the text but is functionally 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?

For a nested-object, two-phase write tool with no output schema, the description fully covers inputs, the return of step 1 (summary, consent line, token), the gating condition, and the downstream email-confirmation behavior. An agent has everything needed to run both calls 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 baseline is 3, but the description goes beyond the schema by explaining sequencing: 'answers' must be keyed by field key from enquiry_fields, 'consent=true' is required in both calls, and 'confirmation' is the token from step 1 used only in step 2. That conditional presence of the token is real semantic value the schema alone does not convey.

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 ('Submits an enquiry to Calcul Brut en Net') and immediately scopes it with two negations ('NOT a purchase, NOT a guaranteed quote'). This clearly separates it from the dataset_* siblings and from the read-only enquiry_describe/enquiry_fields helpers.

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 prescribes the two-call sequence, the condition that gates step 2 ('only if the person agrees'), and what to do with step 1's output ('show the person the summary and the consent line'). Nothing about when to invoke it is left to inference.

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