clearon-source-audit

by kwgoodwin

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 9 of 9 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness1/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![clearon-source-audit-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-source-audit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-source-audit-mcp)

Score Badge

Copy to your README.md:

[![clearon-source-audit-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-source-audit-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-source-audit-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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