French 45-days-end-of-month due date (L441-10 I derogation). Statutory reading: 45 days after month-end of the invoice. Alternate usage: +45 then EOM. Must be stipulated. 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 exist, so the description carries the full burden. It usefully discloses the two interpretations (statutory 45-after-month-end vs alternate +45-then-EOM) and the stipulation requirement, which is real behavioral context. However, it ends with the irrelevant 'Paid $0.01 USDC Base x402' line, which adds noise rather than behavior. It also never states what the tool returns. A 3 reflects partial disclosure with a distracting non-sequitur.
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 core explanation is tight and front-loaded with the legal basis and both readings, but the final sentence 'Paid $0.01 USDC Base x402' is unrelated noise that wastes a clause and dilutes focus. Three useful sentences followed by one irrelevant fragment — efficient but not clean.
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 zero-parameter tool with no output schema, the description explains the concept and its legal context well, covering both statutory and alternate readings. But it never discloses what the tool outputs (e.g., a formatted due-date string to insert), and with no annotations or output schema, that gap is the agent's only missing piece. The USDC noise further reduces completeness.
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?
Zero parameters, so baseline 4 applies. The description explains the meaning of the 45-day EOM concept itself, which is the closest thing to parameter semantics for a parameterless tool. Nothing more is needed.
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?
States a specific concept — French 45-days-end-of-month due date — with legal citation (L441-10 I derogation) that clearly distinguishes it from sibling 'due_date'. The verb is implicit (the tool represents/produces a due-date term) but the resource and scope are unambiguous. It earns a 4 because it is specific and identifiable, though it never states an explicit action.
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?
No guidance on when to use this tool versus alternatives. With siblings like 'due_date', 'payment_term_max', and 'days_late', the description never names a condition that selects this tool or an alternative to prefer. 'Must be stipulated' is a legal requirement about the term, not usage direction. An agent gets no routing help.
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.