Score santé consolidé (0-100, label A-D) par SIREN : statut SIRENE, procédures BODACC, comptes annuels INPI, benchmark Banque de France, dirigeants RNE croisés avec le registre INSEE décès. Clé API requise — le plan gratuit y a accès (1 SIREN par appel).
| Name | Required | Description | Default |
|---|---|---|---|
| sirens | Yes | ||
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds important behavioral context beyond annotations: the API key requirement and the one-SIREN-per-call limit. It also implies the tool cross-references multiple databases, which is useful transparency about its operation.
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 fluff. The first sentence front-loads the core purpose (score, range, label, key identifier), then lists data sources compactly. The second sentence conveys the API key and call limit. Every word 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?
With no output schema, the description explains the primary return value (score 0-100, label A-D) and lists data sources, which is sufficient for understanding the tool's output. It also covers the critical constraint on calls. It could elaborate on the exact response structure, but for a read-only scoring tool this is reasonably 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 explains that siren is the company identifier ("par SIREN") and that api_key is required ("Clé API requise"). Crucially, it disambiguates the array parameter by stating "1 SIREN par appel", preventing an agent from passing multiple SIRENs. It does not detail the exact string format, but the core meaning is clear.
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 immediately states a specific verb and resource: "Score santé consolidé (0-100, label A-D) par SIREN" – it produces a health score per SIREN. It lists distinct data sources (SIRENE, BODACC, INPI, Banque de France, RNE) which clearly differentiates it from siblings like dirigeants_entreprise or verifier_siret.
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 concrete usage constraints: "Clé API requise" and "1 SIREN par appel", telling the agent that an API key is mandatory and only one SIREN can be queried per call. However, it does not explicitly contrast with alternatives or state when not to use the tool, 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.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes (e.g., name-to-SIREN resolution vs SIRET verification), but croiser_deces and dirigeants_entreprise both involve death-registry matching, and the pair resoudre_siren/verifier_siret could initially confuse. However, the descriptions disambiguate well.
The naming mixes infinitive verbs (resoudre, verifier, croiser, diagnostiquer) with noun phrases (sante_entreprise, dirigeants_entreprise, surveillance_alertes), so there's no uniform verb_noun or noun pattern. Still, the names are reasonably readable and not chaotic.
With 8 tools, the server covers the core workflows of data validation, enrichment, scoring, and monitoring without bloat. Each tool addresses a distinct business need, and the count is well within the ideal range.
The surface covers identification, verification, scoring, and portfolio monitoring, but lacks a simple company detail retrieval endpoint (e.g., by SIREN) and a tool for updating/deleting non-portfolio data. These are minor gaps that can be worked around.
