Free mechanical checks for AI text: unnamed counts, dangling references, bad arithmetic, misquotes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 1 of 1 tools scored.
There is only one tool, so there is zero chance of an agent selecting the wrong operation. The single tool's purpose is clearly described, and no overlapping tool boundaries exist.
With only one tool named citation_check, naming is trivially consistent. The snake_case name is clear and accurately reflects the server's purpose, following a recognizable verb_noun pattern.
A single tool is borderline-thin, but the description reveals that it bundles seven distinct checks plus demo and external-verification modes into one call. The core workflow is fully covered, but the server functions as a monolith rather than a modular tool set.
The seven checks thoroughly cover the self-referential citation domain, and the ground=true mode extends coverage to external sources. Minor gaps include the inability to run individual checks in isolation and external verification being gated behind a prepaid key.
citation_checkAInspectCheck a document against the claims it makes about ITSELF — miscounts, pointers to things that are not there, totals that do not add up. CALL IT WITH NO ARGUMENTS for a complete worked verdict on our example document: nothing to prepare, no key, no signup, and it says plainly that the document was ours. Then send your own text the same way. 7 checks run on every call, each answering one question no other answers: Enumeration and manifest (a document against the counts and listings it makes about ITSELF); Internal reference (a pointer inside the document against the thing it points at); Arithmetic (a stated total against the figures standing beside it); Count against list (a count introducing a list against the items actually in that list); Declared bound and form (an instruction the document gave ITSELF against what it then produced); Ordinal sequence (a named sequence against its own order); The document against its own principles (a rule the document stated against what the document later does with it). Returns convictions with line locations. Every answer also states what did NOT apply and what was never examined, because silence from a checker is otherwise unreadable. Verdicts are 3: conviction, clean, refusal — a refusal is neither guilt nor innocence, and there are 5 forms of it. The full catalogue, machine-readable, is at https://check.holoweave.org/api/checks. Pure parsing — no model reads the text. The demonstration runs on our example document; a document of your own is examined by the same fixed rules, within the free allowance, and is not retained. Runs in CI on changed markdown via the citation-check-action GitHub Action. Free tier: 3 calls/day, no key. Max 200 KB. With a prepaid key sent as an Authorization: Bearer header there is no daily limit, and arguments.ground=true additionally fetches each cited source and compares the claim against what it actually says. Beyond the free tier: prepaid packs, identical checks — prices are quoted when a ceiling refusal is reached, and machine-readable prices are at https://check.holoweave.org/api/offer.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | OPTIONAL alternative to text: a public https address of the document to check — the tool fetches it (200 KB cap, 3 url-borne documents a day on their own counter) and runs the same checks. The answer names the address and byte count, because the verdict is about the fetched copy at fetch time. Send text OR url, never both. Nothing fetched is stored. | |
| text | No | The document to check (markdown or plain text). OPTIONAL: omit it and the tool runs on our own example document instead and says so — a one-call demonstration that needs nothing prepared. Your document is never stored. | |
| reach | No | FREE. Report which of the document's cited sources an automated reader can actually retrieve, and why not where not: readable, unreachable, not-text, thin (answered but carried no document), or skipped. No model reads your text. It says NOTHING about whether a claim is true or supported, and an unreachable source is not a broken link — many sites refuse automated readers and serve browsers normally. This is machine-verifiability. 3 documents/day, on its own counter. | |
| ground | No | Also fetch each cited source and compare the claim against what it actually says. Requires a key: the free tier is mechanical only and no model reads your text. WHAT THIS SENDS: when ground is true, the sentences being tested — verbatim from your document — and the retrieved source text are transmitted to a language-model provider that performs the comparison for us (Anthropic PBC, United States). Not the whole document, and never on the free pass there. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It clearly states that pure parsing means no model reads the text, that documents are not retained, and that verdicts are three types with five refusal forms. It also explains ground=true sends verbatim sentences and retrieved source text to Anthropic. The only gap is that it does not describe what the response looks like beyond 'returns convictions with line locations', but that is a minor format question and the overall behavioral disclosure is strong.
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 long, but almost every sentence adds operationally relevant information — limits, privacy behavior, the seven checks, the meaning of a refusal, and how to obtain the catalogue. It front-loads the core idea and demonstration instructions, then moves into limits and optional behaviors. It is dense rather than padded; the only inefficiency is that the ground parameter's key requirement is stated in both the description and the schema, but that repetition is arguably acceptable for prominence.
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?
There is no output schema and no sibling tools, so the description must be self-sufficient. It covers invocation, argument modes and combinations, limits, authentication, privacy, verdict types, the taxonomy of refusal reasons, the permanent catalogue URL, the CI integration, and a link to machine-readable pricing. An agent could call this tool successfully across all tiers without needing further documentation.
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 coverage is 100%, so the schema already documents every parameter. The description adds meaning by framing text's no-argument demonstration mode, explaining in plain terms what reach does (machine-verifiability, not truth), and being unusually explicit about what ground=true transmits. The URL parameter benefit of naming address and byte count is described in the schema, not the description, so the description does not add value for that one parameter, but it compensates well elsewhere.
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 opens with a concrete and unusual claim — the tool checks a document against claims it makes about itself — and then itemizes seven distinct checks, each naming a specific self-referential failure mode (miscounts, internal pointers, arithmetic, ordinal sequences). It is clearly differentiated from ordinary fact-checking or link-checking tools, and the sentence 'no other answers' reinforces that distinction.
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 explicitly says to call with no arguments for a demonstration, then send your own text the same way. It gives the free tier, limits (3/day, 200 KB), keyed authorization for higher limits, and the optional ground=true behavior. It also says send text OR url, never both, in the schema, and the description names the machine-readable catalogue URL. This is exceptionally complete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!