French quote (devis) validity calendar. Default 30 days from quote_date. Commercial usage, not L441-9. Returns expiry and a collable mention. Paid $0.01 USDC Base x402.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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. It usefully reveals the default 30-day behavior, the return value ('expiry and a collable mention'), and the $0.01 payment requirement. However, 'collable mention' is unclear, and there is no mention of how missing/invalid quotes are handled or whether the operation is purely 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 compact and front-loaded with the core purpose, followed by the default rule, legal scope, return value, and cost. Every sentence adds information, though the odd phrase 'collable mention' and the payment detail could be clearer without adding length.
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, parameter-free tool the description is mostly complete: it gives the default period, the commercial scope, the return value, and the cost. But it lacks an output schema and does not specify the expected input format for 'quote_date,' explain what 'collable mention' means, or describe error behavior—gaps that matter for an agent trying to invoke 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?
The tool has zero declared parameters and schema description coverage is 100%, so the baseline is 4. The description still adds useful meaning by referencing 'quote_date' as the basis for the 30-day default, even though the schema does not formally define it.
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 clear resource and function: a French quote (devis) validity calendar with a default 30-day period. It also signals a differentiator from legal-article tools by saying 'Commercial usage, not L441-9.' It is not a single strong verb like 'calculate,' but the intent is unambiguous.
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 implies when to use the tool: whenever a French quote validity/expiry date is needed. The phrase 'Commercial usage, not L441-9' provides some exclusion guidance, but it never names sibling tools or gives concrete 'use this instead' conditions, leaving route selection largely to inference.
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.
Many tools cover adjacent legal concepts such as down payments (acompte/arrhes), payment deadlines (due_date/due_eom/days_late), and identifier checks (check_siret/siren_from_siret/vat_key/eori), which can cause misselection. The descriptions do distinguish them clearly, but the sheer volume of overlapping categories still creates boundary confusion for an agent.
All tool names use lowercase snake_case and are mostly short, readable French legal nouns or noun phrases, so there is a predictable stylistic pattern. The mix of French and English names and the occasional verb-led names like check_siret or siren_from_siret prevent a perfect score.
With 68 tools, this server is far beyond the well-scoped 3-15 tool range and even beyond the 50+ extreme-mismatch threshold. Each tool is a tiny one-purpose helper, but the set as a whole is overwhelming and should be grouped into fewer, broader tools or split into multiple servers.
The tool surface covers an impressively broad range of French legal needs: statutory invoice mentions, payment penalties, holidays, VAT calculations, identifier checks, warranties, withdrawal rights, and dunning steps. There are no obvious dead ends, and mention_fields acts as a completeness checklist for required invoice mentions.