Skip to main content
Glama
Sign In
Conformo

Conformo

by arsalmurad
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Explain a validation rule

explain_validation_rule
Read-onlyIdempotent

Explains a validation rule ID from official rule sets, including wording, plain-language summary, reason, and fix steps so users can resolve invoice validation errors.

Instructions

Explains one validation rule id, such as BR-CO-15, BR-DE-15, PEPPOL-EN16931-R003 or BR-FR-05: the publisher's official wording from the compiled rule sets and, where available, a plain-language summary, the reason for the rule and how to fix it. Use it after validate_invoice reports a rule you need to explain or fix, or when a user asks what a rule means. It does not check an invoice; call validate_invoice for that. An unknown id is not an error: the result has found false and an empty official list; say so and do not guess. Reads the bundled rule sets; no network.

Input Schema

NameRequiredDescriptionDefault
ruleIdYesThe rule id, e.g. BR-CO-15.

Output Schema

NameRequiredDescriptionDefault
foundYesFalse when no compiled rule set knows this id.
ruleIdYesThe rule id as looked up.
officialYesOfficial wording, one entry per rule set that defines the id.
plainLanguageNoPlain-language explanation, when one exists for this rule.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedOutput schema / properties / found / description
      Added value: +"False when no compiled rule set knows this id."
    • addedOutput schema / properties / official / description
      Added value: +"Official wording, one entry per rule set that defines the id."
    • addedOutput schema / properties / official / items / properties / ruleSet / description
      Added value: +"Rule set containing the rule."
    • addedOutput schema / properties / official / items / properties / text / description
      Added value: +"The publisher's wording of the rule."
    • addedOutput schema / properties / plainLanguage / description
      Added value: +"Plain-language explanation, when one exists for this rule."
    • addedOutput schema / properties / plainLanguage / properties / fix / description
      Added value: +"How to change the invoice so the rule passes."
    • addedOutput schema / properties / plainLanguage / properties / summary / description
      Added value: +"What the rule requires, in plain language."
    • addedOutput schema / properties / plainLanguage / properties / why / description
      Added value: +"Why the rule exists or why it typically fires."
    • addedOutput schema / properties / ruleId / description
      Added value: +"The rule id as looked up."
  2. First observedv0.2.1

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description still adds real behavioral context beyond them: unknown ids are not errors but yield `found` false with an empty `official` list, and the tool reads bundled rule sets with no network access. That said, it does not describe result sizing or how large the official wording list can get, so it is useful but not exhaustive.

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

Conciseness5/5

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

A single dense paragraph, front-loaded with the verb/resource and the id formats, then usage, then the negative case, then data sourcing. Every clause earns its place; the 'does not check an invoice' sentence is a deliberate disambiguation rather than filler.

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

Completeness5/5

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

For a one-parameter, read-only lookup with an output schema, the description covers purpose, routing, edge-case behavior and data provenance. Return values are backed by the output schema, and the description goes further by naming the `found`/`official` fields for the miss case so an agent knows what to report to the user.

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

Parameters3/5

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

Schema description coverage is 100% and the single `ruleId` parameter is already documented with its own example, so the schema carries the parameter burden. The description reinforces the id format with several additional naming conventions (PEPPOL-EN16931-R003, BR-FR-05), which helps an agent recognize valid ids but adds no new constraints. Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and resource ('Explains one validation rule id') and immediately grounds it with concrete id examples (BR-CO-15, BR-DE-15, PEPPOL-EN16931-R003, BR-FR-05), making clear it is a lookup/explanation tool, not a validator. It explicitly distinguishes itself from validate_invoice, so an agent can route correctly without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggering conditions ('after validate_invoice reports a rule you need to explain or fix, or when a user asks what a rule means') and an explicit exclusion ('It does not check an invoice; call validate_invoice for that'). The alternative sibling and the condition that selects it are named outright, leaving nothing to inference.

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

Deploy Server

Other Tools