debary-mcp-compliance
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_listingA | Run listing text through the compliance rule engine. Returns every rule that fired, the statute behind it, and the required elements the text is missing for that state and channel. Supplying brokerage, licensee and license_id lets the engine verify disclosure elements instead of deferring them to manual review. |
| explain_ruleA | Return the full rule behind a finding, including the statute it rests on. Use this before telling anyone why their text was flagged. The |
| suggest_rewriteA | Collect what must change in a text, with character offsets and the engine's own replacement wording. This tool deliberately does not rewrite anything. It hands back the spans and the
approved substitutions; composing the new text is the calling model's job, and
the result must be checked again with |
| get_receiptA | Retrieve a stored check receipt, including its anchoring block if one exists. A receipt records what was checked, against which rule version, and the SHA-256 of the exact text. Where an anchor is present, that digest was written to a public ledger by a signer that does not run on the gate -- so the record can be shown to a third party without asking them to trust the server that produced it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| review_listing | Check a listing, then repair it and verify the repair. |
| explain_verdict | Turn a stored receipt into an explanation a licensee can act on. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| rules_index | Every phrase rule and required element, id and category only. |
TDQS
Scored across 4 tools
Each tool occupies a distinct role: running a compliance check, explaining a rule, suggesting rewrite spans, and retrieving an audit receipt. There is no meaningful overlap or ambiguity between them.
All four tools follow the same snake_case verb_noun pattern: check_listing, explain_rule, suggest_rewrite, get_receipt. The naming is predictable and makes the action and target of each tool immediately clear.
Four tools is a well-scoped size for a compliance-assistance server. Each tool supports a necessary step in the workflow without adding redundant or decorative surface area.
The tool set covers the full workflow: check a listing, understand why it was flagged, obtain safe replacement wording, and retrieve verifiable proof of a prior check. The deliberate absence of auto-rewriting is handled cleanly through the check-again instruction.