socs.fr, la commande publique française

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by clarifying that only actually awarded contracts are included ('réellement attribué') and by revealing the nature of the returned data (count, median budget, last order).

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 short sentences cover purpose, output, usage context, and the required input format. There is no filler, and the main scoping information 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?

Because there is no output schema, the description usefully names the returned aggregates so an agent knows what to expect. It covers the key use case and required parameter format; the only gaps are the optional 'limite' and 'secteur' behaviors, which are partly inferable from the schema.

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 67%: 'departement' and 'secteur' are documented, but 'limite' is not. The description's only parameter-related sentence repeats the schema's exact 'departement' format ('35', 'Ille-et-Vilaine') and adds no new meaning about 'limite' or 'secteur'.

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 uses a specific verb ('Liste') and identifies the exact resource: collectivités, hôpitaux and établissements publics that actually awarded contracts in a department. It also states the returned metrics (number of contracts, median budget, last order), which makes the tool's purpose concrete. The use-case phrasing 'à qui vendre / qui achète' distinguishes it from the sibling tools about sector statistics, open consultations, and company-specific 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 gives an explicit trigger: use this tool when the question is about 'à qui vendre' or 'qui achète' in a territory. It does not name alternative tools or state when not to use it, so it falls short of a full exclusion guide.

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, openWorldHint, idempotentHint, and destructiveHint false, which covers the safety profile. The description adds meaningful behavioral context by specifying what the tool computes (averages, ranges, shares) and how the scope changes with or without a department. This goes beyond the annotations and helps the agent understand the nature of the response.

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 exceptionally concise: two sentences pack the tool's purpose, the indicators returned, the recommended usage moment, and the default geographic scope. It is front-loaded with the resource and question being answered, followed by actionable guidance. No filler or redundancy.

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 analytical tool with only two simple parameters and no output schema, the description is complete. It tells the agent what the tool returns, when to call it, and what happens if the optional parameter is omitted. The absence of an output schema is mitigated by the description's enumeration of the indicators, which effectively describes the return content.

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%, as both 'secteur' and 'departement' already have clear descriptions. The description adds minor context by clarifying the sector can be a CPV code or label, and that the territory is a department with France-wide fallback, but it largely echoes what the schema already states. Thus the description does not substantially enhance parameter understanding 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?

The description clearly defines what the tool does: it returns market statistics (average number of offers, amount ranges, share of adapted procedures, share of framework agreements) for a purchasing sector on a territory. It also distinguishes it from sibling tools by framing it as the call to make 'avant de décider de candidater', which positions it as a market-analysis tool rather than a direct procurement search.

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 explicitly states when to use the tool: 'À appeler avant de décider de candidater'. It also explains the default behavior when no department is provided ('la réponse porte sur la France entière et sert de repère'). It does not explicitly mention when not to use it or name alternatives, but the context is clear enough to guide selection.

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 signal read-only, idempotent, open-world behavior; the description adds valuable context beyond that by stating the data is queried live and changes every day. It also explains why memory/cached knowledge is insufficient, which is useful behavioral guidance.

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, each earning its place: purpose, usage trigger, and filter guidance with rationale. No filler, and the most important information 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?

For a read-only, optionally-filtered live query tool, the description covers purpose, triggers, filters, and why live access is necessary. The main gap is the meaning of 'limite', which is undocumented in both schema and description, and there is no output-schema guidance; still, the tool is simple enough that this does not seriously impair use.

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 80%, so the baseline is 3. The description groups filters (department, keywords, minimum remaining delay) and adds a rationale for the two-week threshold, but it adds nothing about the undocumented 'limite' parameter or anything 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?

The description opens with a precise definition: consultations published at BOAMP whose submission deadline has not passed, queried live. This clearly distinguishes the tool from any past-contract or sector-level siblings by its 'still open' scope and live data source.

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 trigger: call whenever a question concerns markets described as 'à venir', 'ouverts' or 'auxquels répondre', because notices change daily and cannot be known from memory. It does not name alternative sibling tools or state when not to use it, so it stops 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 signal a safe, read-only, non-destructive operation. The description adds meaningful behavioral context beyond that: it returns an empty response when the company has won no declared contracts, and notes this is true for the vast majority of French companies, which helps calibrate agent expectations.

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 with no wasted words: the first defines the input and output, the second gives usage context, and the third warns about empty results. Information is front-loaded and every sentence 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?

For a simple read-only tool with two well-documented parameters and no output schema, the description covers what is returned, the triggering question, and the empty-result edge case. It could add a bit more about output structure or invalid SIREN handling, but nothing essential 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 schema already documents both parameters ('siren' format and 'limite' constraints and default). The description adds only the general framing 'from a SIREN' but does not meaningfully enrich the parameter-level semantics 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?

The description states a specific verb and resource: from a SIREN, return the public contracts a company has won, including buyers, sectors, and amounts. It also frames the tool around a company's public activity, which clearly distinguishes it from the sibling tools focused on buyers, sectors, and open consultations.

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 explicitly says when to call the tool: when the question concerns a company's public activity, public clientele, or weight in a market. It does not name alternatives or state when not to use it, but the context provided is clear enough for routing.

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