DataRespublica

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

With no annotations supplied, the description carries the full burden; it usefully discloses the data source (DataRespublica/INSEE) and that fiscal and security sections are conditional ('quand présents'), warning the agent some fields may be absent. It does not state what happens with an unknown or out-of-range commune code, whether values can be null, or any rate/coverage limits, which are notable gaps for a zero-annotation 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 dense sentence that front-loads the tool identity, source, and territorial level before listing contents. It is jargon-heavy but every clause conveys content the agent needs given the absent output schema; no filler sentences.

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 compensates well by enumerating the returned fields (population, superficie, demographic series, DVF headline price, fiscal and security indicators). What remains missing is edge-case behavior on invalid commune codes and confirmation of read-only, non-mutating semantics, but for a one-parameter lookup this is close to sufficient.

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

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

There is one parameter with 100% schema description coverage, so the schema already explains commune_code including an example (69123) and length bounds. The description only reinforces the commune-level scoping via territoires.level=commune and adds no format, validation, or lookup semantics 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?

The description identifies a specific resource (commune-level INSEE fact sheet under territoires.level=commune) and enumerates its contents: population, area in km², INSEE demographic series, headline DVF price, fiscal and security indicators. Siblings like get_dvf_commune and get_delinquance_commune are implicitly differentiated by the word 'tête' (headline/summary) and 'quand présents', but the description never names a sibling or states the boundary 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: an agent infers it should call this for a bundled commune overview and the specialized tools for deep dives on DVF or delinquency. There is no explicit when-to-use, when-not-to-use, or named alternative, so routing against get_dvf_commune, get_delinquance_commune, and get_departement 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.

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

No annotations are supplied, so the description carries the full behavioral burden and does not meet it. It never states that the call is read-only, whether it is cheap or expensive, whether results are paginated or cached, or what a 'READINESS / DATA_DEPTH level' actually conveys; only the subject matter is 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?

It is a single front-loaded sentence with no filler, which is appropriate in length. However, the em-dash appositive structure packs in three undefined terms, making it terse rather than informative — compactness is achieved at the cost of comprehension.

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 parameters and no output schema, the description is the only source of information about what comes back, and it only gestures at the return content (dataset entries plus readiness/depth levels). For a discovery-oriented catalogue tool that an agent would use to plan subsequent calls, it should say more about what each entry contains and how to act on 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?

The tool takes zero parameters, and the description does not invent any, so the baseline of 4 applies. There is no parameter semantics to add beyond the empty 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 identifies the resource as a catalogue of documented datasets and mentions READINESS / DATA_DEPTH levels, so the general subject is clear. But it is a noun phrase with no verb, and the jargon ('fiches D09', 'READINESS / DATA_DEPTH') is never explained, so an agent cannot be certain what this returns or how it differs from siblings like get_territory_scores or get_ranking_head.

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 at all: no trigger conditions, no exclusions, and no mention of any of the seven sibling tools. The agent must infer from the name alone that this is a discovery/meta tool to consult before calling the data-retrieval siblings.

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 it does disclose something valuable beyond the schema: the data comes from the series_publiques dataset with an ind_delinquance fallback, so the agent learns the metric has a sourcing hierarchy. However, it says nothing about missing communes, temporal coverage of the "dernier" value, permissions, or error 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?

It is a single short sentence with no filler, which is good, but it is front-loaded with a vendor name (“DataRespublica”) and parenthetical internal identifiers rather than the action and return value. Density here comes from unexplained jargon rather than 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?

A one-parameter tool with no output schema and no annotations needs the description to explain what comes back (rate, year, geography level) and how gaps are handled. The fallback mention is the only substantive detail; the return shape and coverage limits remain unstated.

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

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

The input schema has 0% description coverage and the description never mentions commune_code at all. It does not clarify that this is an INSEE code, what the 4–5 character constraint implies, or whether leading zeros matter — the one parameter an agent must supply is left entirely to inference.

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 concrete resource — the latest SSMSI rate per 1,000 inhabitants — so an agent can infer it retrieves a delinquency indicator. But the verb is nominal/implicit and the payload is wrapped in unexplained jargon (SSMSI, series_publiques, repli ind_delinquance), and nothing distinguishes it from data-fetching siblings like get_dvf_commune or get_territory_scores.

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 alternative-tool routing, and no stated preconditions. The only hint is the subject matter itself, leaving the agent to guess whether this or get_territory_scores / get_commune is the right call for delinquency data.

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

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

With no annotations, the description carries the full behavioral burden and discloses almost nothing: read-only-ness is only implied by the get_ prefix, and there is no mention of auth requirements, error behavior for an invalid or unknown code (e.g. 2A, 971), or response size. Only the dataset-level scoping adds real context.

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?

It is a single short clause with the resource front-loaded and zero padding, which is good, but the brevity tips into under-specification rather than tightness. There is no structured layout beyond an em-dash separator.

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?

This is a simple one-parameter lookup with full schema coverage, so the bar is low, but there is no output schema and the description never indicates what the returned fiche includes (scores, population, boundaries). An agent cannot anticipate the result shape 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 100% — the departement_code parameter is fully documented in the schema with INSEE examples (69, 2A, 971) and length bounds. The description adds no additional meaning beyond that, 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 identifies the resource as a "fiche département" and scopes it with the hint "territoires.level=departement", which implicitly separates it from get_commune. However, it uses no verb ("retrieve"/"return") and never says what a "fiche" contains, so the purpose is only partially pinned down.

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 statement of prerequisites, and no explicit routing to or away from siblings such as get_commune or get_territory_scores. The only usage signal is the embedded dataset-level phrase, which an agent must infer from.

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 disclosure burden. It does reveal the shape of the result (averages, volumes, evolutions, conditional medians), which is useful behavioral context absent from any structured field. However, it says nothing about data coverage years, handling of missing communes, or error behavior, leaving notable gaps for a data-retrieval 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 dense sentence, front-loaded with the data source name and ending with the conditional output caveat. Nothing is wasted, though the heavy use of semicolons and abbreviations slightly reduces readability.

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, no annotations, and no output schema, the description does reasonably well by enumerating expected metrics. It falls short on parameter meaning and edge cases, leaving the agent without enough to call it confidently with correct commune codes.

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 single required parameter commune_code is not explained in the description at all — no mention that it is an INSEE code, no format guidance beyond the schema's min/max length. With the sole parameter undocumented in both schema and description, the description fails to compensate.

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 dataset (DVF), the level ('communal'), and the metrics produced (weighted average €/m², volumes, evolutions, type-level medians). This is a specific verb-plus-resource statement that distinguishes it from generic siblings like get_commune. It stops short of an explicit 'use this instead of X' contrast, which keeps it at 4.

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 explicit when-to-use or when-not-to-use guidance, and no comparison against the sibling tools such as get_commune or get_territory_scores. The only usage-adjacent hint is the conditional clause about medians being exposed by commune_market_summary, which implies a dependency but does not tell the agent when to pick this tool.

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 mentions that the ranking is 'précalculé' (precomputed), which is useful context, but it does not disclose read-only behavior, authentication requirements, result ordering, coverage limits, freshness, or what 'tête' means in terms of result size.

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 compact line with no wasted wording, and the ranking_slug examples are front-loaded. Its brevity is appropriate structurally, though the content is under-specified rather than overly verbose.

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

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

Given four parameters, no annotations, no output schema, and 0% schema description coverage, the description is not complete enough. It covers ranking_slug candidates only and leaves limit, min_population, departement_code, and the return format 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?

Schema description coverage is 0%, so the description must compensate. It provides candidate ranking_slug values (prix-immobilier, delinquance, etc.), which adds meaning for the required parameter. However, it does not explain the semantics of limit, min_population, or departement_code, leaving three of four parameters undocumented 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?

The description identifies the resource as a precomputed '/tops' ranking and indicates it returns the 'tête' (head) of that ranking, which gives a general sense of purpose. However, it does not explicitly state the operation in plain terms (e.g. 'returns the top entries') and does not distinguish this tool from siblings such as get_territory_scores or get_commune.

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

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

The description gives no guidance on when to use this tool versus alternatives. It lists ranking_slug values but does not explain when a caller should choose this tool over get_territory_scores or other sibling tools.

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 of behavioral disclosure. It notes that the scores are proprietary and lists categories, but says nothing about permissions, data coverage, return shape, score ranges, or whether the operation is read-only.

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

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

The description is concise, but it is structured as a brand fragment rather than a front-loaded action statement. The brand name leads, while the tool's function and required input are absent.

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 data-retrieval tool with no annotations, no output schema, and an undocumented required parameter, the description is materially incomplete. It identifies the dataset domain but does not explain the input, output, or how to interpret the proprietary scores.

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 one required parameter, commune_code, with 0% description coverage. The description never mentions commune_code or explains that a commune identifier is required, so it adds no semantic meaning beyond the schema property name.

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

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

The description identifies the resource as proprietary territorial scores and gives example categories (tranquillité, fiscalité, dynamisme immo), which conveys the general data domain. However, it lacks a clear action verb, does not explicitly say it retrieves scores for a commune, and does not distinguish itself from siblings such as get_commune or get_delinquance_commune.

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 explicit guidance on when to use this tool versus alternatives like get_commune, get_delinquance_commune, or get_dvf_commune. The score categories imply a possible use case, but the agent is left to infer when this tool is the right choice.

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

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

With no annotations provided, the description carries the full burden and does supply two useful facts: 'Lecture seule' (read-only, so no mutation risk) and the shape of the returned metadata (type, date, URL). It says nothing about pagination behaviour, the default/ceiling for limit, or what happens when the elu_id has no declarations or does not exist.

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 line with no filler: source, resource, scope and return fields in that order. It is terse to the point of under-specification rather than padded, which is the preferable failure mode but still leaves gaps.

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 read tool with no output schema, the description does list the returned fields, which partly substitutes for a missing return contract. However, the undocumented limit parameter and the absence of any guidance on missing/empty results leave it only minimally 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 coverage is 50%: elu_id is documented in the schema as a DataRespublica UUID, but the limit parameter (1–25) has no description anywhere. The description never mentions limit or any default, so it fails to compensate for the coverage gap on the second parameter.

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

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

The description names a specific resource (HATVP declarations, DataRespublica source) and its scope (linked to one elected official), which an agent can distinguish from the get_* siblings covering communes, departments, delinquency, DVF and scores. The list verb itself is carried only by the tool name, and 'HATVP' is unexplained jargon, keeping it 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?

It implies the tool is used for a given elected official, but gives no explicit when-to-use, no when-not-to-use, and no alternative tools for related data. An agent must infer from the name and required elu_id that this is a per-official lookup rather than a search.

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