Clearon Source Audit is an MCP server for revision-bound source auditing, quotation matching, and prepublication evidence-control reporting.
Create source audits bound to an exact article revision SHA-256 fingerprint.
Retrieve and list audits with stored article text, sources, claims, and acknowledgments.
Register sources with classification, metadata, optional retrieved text, and identifiers.
Record or replace claim-to-source mappings with article/source excerpts and procedural posture.
Run mechanical checks for fingerprint integrity, quotation matching, procedural-language warnings, and opt-in URL availability checks.
Generate immutable prepublication reports listing unresolved and acknowledged exceptions.
Approve source-integrity findings explicitly for publish/update review.
Acknowledge claim or source-retrieval warnings after human review without converting warnings into support.
Manage local storage location via user data directories or CLEARON_SOURCE_AUDIT_ROOT.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@clearon-source-audit audit this article draft and verify its quotations against the cited sources"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for revision-bound source review, quotation matching, and prepublication evidence-control reports.
It is designed to preserve exactly what was audited. It does not publish articles, decide truth, or replace legal/editorial judgment.
Binds each audit to an exact article revision fingerprint.
Records source classifications and claim-to-source mappings.
Verifies direct quotations against retrieved source text.
Revalidates stored source-text fingerprints before trusting retrieved evidence.
Flags procedural-language risks such as stating allegations as holdings.
Generates immutable JSON reports for the audited revision.
Highlights source-integrity mismatches as explicit publish/update review items for the user.
Related MCP server: proofspec
It does not determine legal correctness or factual truth.
It does not publish or modify external systems.
It does not treat retrieval failure as proof that a source is false.
It does not convert acknowledged warnings into substantive support.
It does not treat acknowledged substantive claim gaps as publication-ready support.
It does not treat source-integrity mismatches as repaired just because the user approved a publish/update exception.
Node.js 20 or newer
A local MCP client that can launch a stdio server
Published package:
npm install -g clearon-source-audit-mcp
clearon-source-audit-mcpSource checkout:
cd tools/clearon-source-audit-mcp
npm install
npm test
npm run smokeExample stdio configuration:
Installed package via npx:
{
"mcpServers": {
"clearon-source-audit": {
"command": "npx",
"args": ["-y", "clearon-source-audit-mcp"]
}
}
}Source checkout:
{
"mcpServers": {
"clearon-source-audit": {
"command": "node",
"args": ["/absolute/path/to/clearon-source-audit-mcp/server.mjs"]
}
}
}If you want audit data somewhere specific, set CLEARON_SOURCE_AUDIT_ROOT in the client environment.
By default, audit data is stored outside the repository in a user data directory:
macOS: ~/Library/Application Support/clearon-source-audit-mcp/source-audits
Linux: ${XDG_DATA_HOME:-~/.local/share}/clearon-source-audit-mcp/source-audits
Windows: %APPDATA%\\clearon-source-audit-mcp\\source-audits
Override that location with CLEARON_SOURCE_AUDIT_ROOT.
Each audit stores:
audit.json
article.txt
reports/*.json
Files are written with owner-only permissions where the host platform supports them.
Create or obtain the exact article text to audit.
Compute its SHA-256 fingerprint.
Call create_source_audit.
Call register_source for each source.
Call record_claim_mapping for checkable factual or legal claims.
Run run_mechanical_checks.
Fix weak claims, missing excerpts, quotation mismatches, and procedural warnings in the article.
If the article text changes, create a new audit for the new revision.
Call generate_source_report.
Use acknowledge_finding only when a human has actually reviewed and accepted a claim or source-retrieval warning.
If the report lists pending_publish_update_review_findings, use approve_source_integrity_finding only when you explicitly approve that exact source-integrity mismatch for publish/update.
Treat ready_for_human_approval as blocked until every claim is substantively supported and every non-integrity warning is either resolved or explicitly acknowledged.
Treat ready_for_publish_or_update as blocked until the report has no pending source-integrity review items.
get_server_health
create_source_audit
get_source_audit
list_source_audits
register_source
record_claim_mapping
replace_claim_mapping
run_mechanical_checks
generate_source_report
approve_source_integrity_finding
acknowledge_finding
URL availability checks are opt-in. run_mechanical_checks and generate_source_report default check_urls to false.
When enabled, the server performs bounded HTTP(S) reachability checks and treats failures as warnings only. Before each request (including redirects), it rejects local/private DNS answers and pins the connection to the validated public addresses to narrow DNS-rebinding exposure. This is a convenience check, not a trust decision or a replacement for host-level egress controls.
Source-retrieval warnings use a stable acknowledgment string; transport details are preserved separately in the verification output.
Source-integrity warnings are handled differently. They appear in a dedicated publish/update review list in the report and require explicit user approval before the report becomes ready_for_publish_or_update.
npm test
npm run smoke
npm run syntax
node --check server.mjsRecord human review of an exact warning. Does not convert the underlying source or claim into support.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | ||
| slug | Yes | ||
| type | Yes | ||
| item_id | Yes | ||
| warning | Yes | ||
| acknowledged_by | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose a key non-effect: the action does not convert the underlying source or claim into support. However, it does not clarify whether the operation is idempotent, what happens on duplicates, or any permission/audit implications for a mutation-like action.
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 two short sentences with no filler. It front-loads the primary action and then adds a single, valuable clarification about what the tool does not do. Every word earns its place.
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?
Given no annotations, no output schema, and a six-parameter input schema with 0% schema coverage, the description is too thin for an agent to reliably invoke the tool. It captures the intent but omits critical operational context such as how to identify the exact warning, which identifiers are required, and what the 'note' field should represent.
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 description coverage is 0%, and the description provides no parameter-level meaning. It does not explain what 'slug', 'item_id', 'warning', or 'note' should contain, nor how to choose between the 'claim' and 'source_retrieval' enum values. With six parameters and no compensation in the description, an agent receives almost no guidance for filling the schema.
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 uses a specific verb and resource: 'Record human review of an exact warning.' It clearly states the tool's core function and adds a differentiating negative clause: it does not convert the underlying source or claim into support. It could name the sibling it complements, but the core purpose is evident.
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 the usage context: when a human has reviewed a warning and wants to record that review. The negative statement about not converting to support provides some exclusion guidance, but it does not explicitly mention when to prefer this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an audit bound to the exact SHA-256 fingerprint of an editorial revision.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| title | Yes | ||
| revision | Yes | ||
| article_content | Yes | ||
| revision_sha256 | Yes | ||
| editorial_project_slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and constraints on its own. It conveys that the audit is tied to an exact revision hash, but it omits whether the server verifies the fingerprint, what happens on mismatch, auth requirements, or any other side effects. This is a minimal write-operation description that leaves significant behavioral uncertainty.
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 a single front-loaded sentence with no filler; 'Create an audit' immediately identifies the action and the following clause adds the key constraint. It is appropriately short for the information it carries.
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?
With six parameters, five required, no annotations, and no output schema, the description is too sparse to fully support correct invocation. It leaves unclear how the server uses the SHA-256 versus article_content, whether an existing revision is required, and what the response indicates on success or failure. Essential context beyond the sentence is missing.
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 0%, so the description must compensate for undocumented parameters. It hints at the role of revision_sha256 and the revision context, but it does not explain slug, title, article_content, or editorial_project_slug, nor the relationships among them. Parameter names are somewhat self-descriptive, but the description adds only marginal semantic value.
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 opening verb 'Create' plus resource 'audit' clearly states the operation, and the qualifier 'bound to the exact SHA-256 fingerprint of an editorial revision' gives a specific scope that distinguishes it from sibling retrieval tools like get_source_audit and list_source_audits. The intended object and uniqueness condition are identifiable without opening the schema.
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 gives no guidance on when to choose this over alternatives. It does not mention prerequisites, such as whether the editorial revision or source must already be registered, nor does it name any sibling to avoid, such as register_source or run_mechanical_checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an immutable prepublication report for the bound revision, listing every unresolved or acknowledged exception. URL availability checks are opt-in.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| check_urls | No | ||
| timeout_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses several important behaviors: the report is immutable, prepublication-scoped, covers every unresolved or acknowledged exception, and URL checks are opt-in. However, with no annotations at all, it does not disclose whether the report is persisted, what side effects occur, or what failure modes exist.
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 two tight sentences with no filler. It front-loads the action and resource, then adds the report's content scope and the opt-in behavior, making every sentence informative.
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?
Given no output schema, no annotations, and three underdocumented parameters, the description is not complete enough for confident invocation. It does not explain what the 'bound revision' is, how the report is returned or stored, or what timeout_ms affects.
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 description coverage is 0%, so the description must compensate for the bare schema. It addresses check_urls by noting URL availability checks are opt-in, but it leaves slug, the only required parameter, and timeout_ms completely unexplained.
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 uses a specific verb and object ('Generate an immutable prepublication report for the bound revision') and tells the agent what the report contains ('listing every unresolved or acknowledged exception'). It is clearly distinct in intent from siblings like get_server_health or run_mechanical_checks, though it does not explicitly name an alternative tool.
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?
There is no guidance on when to use this tool versus alternatives such as create_source_audit or get_source_audit. The only usage-related note, 'URL availability checks are opt-in,' is parameter guidance rather than tool-selection guidance, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report source-audit health, storage root, and non-publishing safety boundaries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Report' implies a read-only operation, and the listed items indicate the kind of data returned. However, it does not explicitly state side-effect-freedom, permission needs, or any special behavior (e.g., whether 'safety boundaries' are computed or simply read). This is adequate but not rich.
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?
A single sentence packs three distinct aspects that are reported, with no filler or repetition. The verb 'Report' is front-loaded, making the tool's purpose immediately clear. Every phrase earns its place.
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 parameterless read-only health tool, the description covers the main output areas, and the lack of parameters means the call surface is trivial. However, without an output schema or annotations, some detail about the exact shape or semantics of 'source-audit health' and 'non-publishing safety boundaries' would improve completeness. Still, the description is sufficient for an agent to invoke it correctly and interpret the broad categories.
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 parameters, so there is no schema to document. The description adds value by explaining what the tool reports (source-audit health, storage root, safety boundaries), giving context rather than just the tool name. This aligns with the baseline expectation for a parameterless tool.
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 uses a specific verb 'Report' with concrete resources: source-audit health, storage root, and non-publishing safety boundaries. This distinguishes it from sibling tools like create_source_audit or register_source, which imply different actions. However, the terms 'health' and 'non-publishing safety boundaries' are somewhat domain-specific and could be clearer.
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 is given about when to use this tool versus the sibling tools. The context signal of 0 parameters and a health-report purpose implies it might be a preliminary check, but the description itself provides no explicit when-to-use or when-not-to-use direction. An agent is left to infer its role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read an audit, its exact bound article text, registered sources, claims, and acknowledgments.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral information. It signals a read-only operation and indicates the response scope, but it does not disclose slug semantics, error behavior, pagination, permissions, or output shape.
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 a single front-loaded sentence with no filler. Every phrase adds information about the tool's purpose or return scope.
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 tool with no output schema and no annotations, the description should provide more operational context. It names the return contents but leaves the meaning of the slug parameter, relationship to sibling tools, and failure/success behavior unspecified.
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 schema has one parameter, 'slug', with zero description coverage. The description never explicitly states that slug identifies which audit to read or what format it takes, so it fails to compensate for the missing parameter documentation.
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 uses a specific verb ('Read') and resource ('audit') and enumerates the included components: exact bound article text, registered sources, claims, and acknowledgments. This clearly distinguishes it from create_source_audit and list_source_audits.
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?
There is no guidance on when to use this tool versus siblings like list_source_audits for browsing or generate_source_report for analysis. The usage context is only implied by the verb 'Read', with no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List source audits and compact workflow counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the operation rather than disclosing behavioral traits. It does not explicitly state that the operation is read-only, whether pagination or limits apply, how 'compact workflow counts' are derived, or what the response shape is.
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 a single front-loaded sentence with no filler or redundant phrases. It states the action and resource directly and omits unnecessary elaboration.
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?
With no parameters and no output schema, the description explains the high-level return content (source audits and workflow counts) but leaves the exact structure, ordering, and meaning of 'compact workflow counts' unclear. Adequate for a no-argument invocation, but not fully complete for interpreting results.
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 parameters, so there are no parameter meanings for the description to clarify. The baseline of 4 applies because there is nothing for either the schema or the description to document.
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 uses a specific verb ('List') and identifies the resource ('source audits') plus an additional summary object ('compact workflow counts'). The plural form distinguishes it from the singular get_source_audit and from create_source_audit among the siblings.
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 plural 'List' implies this tool is appropriate for enumerating source audits rather than retrieving one (get_source_audit) or creating one (create_source_audit), but it does not explicitly state when to choose it or name an alternative. No exclusion or comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a human-reviewable claim-to-source mapping, exact article excerpt, source excerpt, quotation, and procedural posture. Does not decide truth.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| slug | Yes | ||
| status | Yes | ||
| claim_text | Yes | ||
| quote_text | No | ||
| source_ids | No | ||
| source_excerpt | No | ||
| article_excerpt | No | ||
| is_direct_quote | No | ||
| procedural_posture | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose a key trait—'Does not decide truth'—which prevents misuse. However, it does not mention side effects, whether existing mappings are updated or appended, required source existence, permissions, or what the response contains.
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?
Two short sentences with no filler. The core purpose is front-loaded, and the critical boundary ('Does not decide truth') is placed prominently at the end as a standalone clarifier. Every word earns its place.
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?
The tool has 10 parameters, no output schema, and no annotations. The description gives a high-level purpose but not enough operational context for correct invocation: it does not define how status should be chosen, whether sources must already be registered, what happens on conflict, or what the tool returns. This is a meaningful gap for a write-style tool.
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 description coverage is 0%, so the description needs to compensate. It names several parameters in prose: article_excerpt, source_excerpt, quote_text, and procedural_posture. However, it leaves required parameters like status, slug, and claim_text unexplained, and does not clarify the meaning of the status enum values or how source_ids relate to the mapping.
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 uses a specific verb ('Record') with a clear resource ('claim-to-source mapping') and explicitly enumerates the key fields it captures: article excerpt, source excerpt, quotation, and procedural posture. The final phrase 'Does not decide truth' sharply differentiates it from analytical or decision-making sibling tools.
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 establishes a clear usage context: this records human-reviewable mappings rather than deciding truth. It implies the tool is for documentation and human review, not for automated verdicts. It does not explicitly name alternative tools like run_mechanical_checks or generate_source_report, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register and transparently classify a source; optional retrieved text enables quotation matching.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| note | No | ||
| slug | Yes | ||
| title | Yes | ||
| issuer | No | ||
| source_type | Yes | ||
| retrieved_at | No | ||
| document_date | No | ||
| retrieved_text | No | ||
| docket_or_identifier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that optional retrieved_text enables quotation matching and that classification is 'transparent,' but it does not disclose side effects, idempotency, duplicate handling, required permissions, or what happens after registration.
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 a single front-loaded sentence with no filler; every word contributes to the high-level purpose. The phrase 'transparently classify' is slightly unclear, but overall the structure is appropriately compact.
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?
With 10 parameters, 0% schema description coverage, no annotations, and no output schema, the description is far from complete. It omits return behavior, side effects, parameter semantics, required workflow context, and any guidance on the source_type classification values.
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 description coverage is 0%, and only one of ten parameters (retrieved_text) receives any semantic explanation in the description ('enables quotation matching'). Required parameters like slug, url, title, and source_type are left to be interpreted from their names alone.
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 specific action ('Register') on a specific resource ('a source') and adds the useful qualifier about classification and optional quotation matching. However, it does not distinguish this tool from sibling audit/report tools, and 'transparently classify' is somewhat vague.
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?
There is no guidance on when to use this tool versus alternatives like create_source_audit, run_mechanical_checks, or generate_source_report. No prerequisites, exclusions, or context about the intended workflow are provided; the usage is only implied by the verb 'Register.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the revision fingerprint, quotation matches, and procedural-language warnings. URL availability checks are opt-in.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| check_urls | No | ||
| timeout_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It states what is checked and that URL checks are opt-in, but does not mention side effects, response format, error behavior, or whether the operation is read-only. This leaves significant behavioral ambiguity for an action that 'runs' checks.
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 concise and front-loaded with the main purpose, followed by the opt-in behavior. No filler exists, though it could add a bit more detail without becoming bloated.
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?
With no output schema and no annotations, the execution semantics, expected return values, and parameter roles are largely unspecified. The agent knows what is checked but not what a successful or failed call yields, how long it might take, or what slug refers to.
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 description coverage is 0%, so the description must compensate for the lack of parameter documentation. It hints at check_urls via 'URL availability checks are opt-in' but never names the parameter, and it gives no meaning for slug or timeout_ms. An agent cannot infer how to fill the required parameter correctly from this text.
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 uses a specific verb ('Check') and names three concrete resources: revision fingerprint, quotation matches, and procedural-language warnings. This clearly distinguishes the tool from siblings like get_server_health or list_source_audits, which address different concerns.
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 is given on when to use this tool versus alternatives, nor any prerequisites or conditions for running the checks. The only condition mentioned is that URL availability checks are opt-in, which is about a flag, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0acknowledge_findingcreate_source_auditgenerate_source_reportget_server_healthget_source_auditlist_source_auditsrecord_claim_mappingregister_sourcerun_mechanical_checksMost tools have clearly distinct purposes, but run_mechanical_checks and generate_source_report both involve opt-in URL availability checks and exception discovery, so an agent could hesitate between the check step and the report step. All other boundaries, such as registering a source versus creating an audit versus recording a claim mapping, are clear.
All nine tools consistently follow a snake_case verb_noun pattern: register_source, create_source_audit, list_source_audits, run_mechanical_checks, acknowledge_finding, and so on. There are no mixed conventions or ambiguous generic verbs.
Nine tools is well-scoped for a source-audit workflow, covering health checks, source registration, audit lifecycle, claim mapping, mechanical verification, report generation, and finding acknowledgement. Each tool occupies a meaningful workflow slot without redundancy or excessive granularity.
The core audit lifecycle is well covered: register sources, create audits, map claims, run checks, acknowledge findings, and generate reports. A minor gap is that sources and findings cannot be independently listed or managed outside of an audit, though agents can work around this through get/list audits and report output.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
49 deterministic tools for text integrity, agent control, and contextual quality evidence.
Cite the claim, not the paper: 5,033 assertions, each hash-verifiable against its source PDF
Deterministic cited disclosure drafts with verified GHG lineage and audit hashes.
Verify AI outputs against real sources. Returns a trust signal and permanent doc number.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kwgoodwin/clearon-source-audit-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
