PublicOffre — marchés publics français

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile needs no restating. The description does add genuine context beyond that: the per-capita debt is benchmarked against similarly-sized communes, which tells the agent the output is comparative rather than raw. It still says nothing about response shape or limits.

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

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

One dense, front-loaded line with no filler; every item listed adds scope information. It is a noun fragment rather than a structured statement, 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?

For a single-parameter read-only lookup with no output schema, the topic enumeration effectively acts as a return-value summary, which is enough for an agent to decide whether the tool is relevant. The only real gap is the absence of guidance on how it relates to the overlapping contract-award siblings.

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 parameter with 100% schema description coverage; the schema already states 'Nom ou code INSEE' with an example. The description only reinforces the French-commune scope, adding no format details beyond the schema, so the baseline of 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 resource (the public finances of a French commune) and enumerates the four data domains it covers: debt, property tax rate, contract-winning companies, and public works sites. It does not, however, differentiate itself from siblings such as qui_remporte_les_marches, even though 'entreprises qui remportent ses marchés' clearly overlaps with them.

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 by the enumeration of covered topics, which suggests the kinds of questions the tool answers. There is no explicit statement of when to call it, no exclusions, and no routing to siblings that cover overlapping contract-award 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context beyond them: the fixed 24-month observation window, the aggregation level, and the fact that results include top companies and buyers alongside the headline metrics.

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

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

One sentence, front-loaded with the core metric before the scope and the returned entities. It is dense but every clause carries information; a slight trim of the trailing 'avec les entreprises et acheteurs principaux' phrasing would make it tighter.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the metrics (single-offer share, median offer count) and the accompanying entity lists. Combined with annotations covering the safety profile, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single parameter already documents that an empty value means all of France. The description's 'France ou un département' merely restates the schema's contract, so the baseline of 3 applies for a fully documented parameter set.

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 measurement (single-bidder share and median bid count for public contracts) with a defined aggregation window and geographic scope, which is far more precise than the title alone. It does not, however, distinguish itself from the sibling qui_remporte_les_marches, which sounds like an adjacent view of the same 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?

Usage is only implied: the phrase 'pour la France ou un département' hints that the tool is used for geographic comparison of competition intensity, but there is no explicit when-to-use statement and no mention of when another sibling tool would be the better 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?

Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is covered. The description adds the returned facts but omits the aggregation window, how many top firms are listed, and how many ‘derniers marchés’ are returned – limits an agent needs to interpret the results correctly.

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 buyer scope and ending with the outputs. Every clause contributes information; there is no repetition or filler.

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

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

For a read-only statistics tool with no output schema, the description does explain the return fields reasonably well. However, it leaves the temporal scope and result caps unspecified, which is material for an agent interpreting contract-award data. Adequate but with clear gaps.

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 acheteur parameter is fully documented with an example. The description adds the entity categories (commune, département, hôpital, bailleur, État) and reiterates name or SIREN, but gives no matching behavior beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 precisely what is returned for a public buyer and enumerates the buyer types and identifier form. It is clearly an awardee-statistics lookup for one buyer, but it does not distinguish itself from sibling concurrence_marches_publics, whose single-offer-share metric overlaps with its own output.

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, when-not-to-use, or named alternative among the siblings. Usage is only implied by the described outputs, which is the minimum viable level of guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful context beyond annotations: source coverage, daily updates, and the fields returned. It does not mention rate limits, pagination, or the effect of the limit parameter.

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

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

The description is two compact, front-loaded sentences with no filler. The source list, return fields, and filter examples all earn their 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?

With no output schema, the description usefully names the returned fields, sources, and update frequency, which covers most of what an agent needs. It leaves out limit behavior and explicit routing to sibling tools, so it is strong but not 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?

Schema description coverage is 75%, and the description adds concrete meaning for the filters, especially department code formats (2A, 974) and CPV division examples with domain mappings. It does not explain the limite parameter, but that parameter has schema min/max constraints.

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 and scope: open public tenders in France from BOAMP, JOUE/TED, and public platforms. It also names the returned fields and filters, so an agent can distinguish it from siblings such as qui_remporte_les_marches by the focus on open tenders rather than awarded contracts.

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 clearly implies the tool is for searching open tenders and lists filter dimensions, but it does not explicitly say when to use it versus alternatives like concurrence_marches_publics or qui_remporte_les_marches. No exclusions or sibling routing are provided.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds useful scope about what data is returned, but does not go beyond that with caveats, permissions, or no-result behavior.

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

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

The definition is a single efficient sentence that front-loads the entity scope and then enumerates the returned information. There is no filler or redundant explanation.

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 read-only, single-parameter lookup with full schema coverage and annotations, the description is largely complete because it states the entity input and the main returned metrics. It could still clarify no-result behavior or output shape, but the core information an agent needs is present.

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 schema already documents the entreprise parameter as a name or SIREN with examples. The description’s “(nom ou SIREN)” repeats the schema rather than adding new parameter semantics.

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

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

The description clearly states the tool’s purpose for a company identified by name or SIREN and lists the specific public-procurement outputs returned. It is distinguishable from most siblings, though it does not explicitly contrast itself with qui_remporte_les_marches.

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 usage for a given company by saying “Pour une entreprise (nom ou SIREN)” and listing the returned metrics. However, it gives no explicit when-to-use guidance, exclusions, or routing advice versus sibling tools such as qui_remporte_les_marches.

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