Clearon Content Archive MCP

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 target distinct resources and actions, such as searching, exact lookup, and registering content. The main ambiguity is between list_incomplete_follow_through and list_update_candidates, which both surface records needing verification or correction, but their descriptions largely clarify the intended focus.
Naming Consistency5/5
All tool names use a consistent lower_snake_case verb_noun pattern, such as get_content_record, record_publication, and approve_voice_example. Even the longer compound names like compare_payload_to_live_state and list_incomplete_follow_through follow the same predictable action-first convention.
Tool Count4/5
The server has 16 tools, which is slightly above the typical well-scoped range, but each tool appears to support a distinct archival lifecycle concern. The count is not excessive given the breadth of content, publication, social, correction, and voice-example workflows being covered.
Completeness4/5
The tool set covers the core content archive lifecycle: register, read, search, update, verify, and append publication/social/correction outcomes. Minor gaps exist, such as no explicit unpublish or approval-revocation tool, but the append-only design and existing verification tools make those acceptable omissions.
Average 3.3/5 across 16 of 16 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior1/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 does not state whether the tool is read-only, whether it mutates workspace state, what it returns on match/mismatch, or whether it requires special permissions. 'Compare' suggests non-mutating behavior, but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, its brevity comes at the cost of missing essential information, so it is not optimally 'appropriate' in size for the tool's complexity.
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 3 parameters, no annotations, no output schema, and no usage guidance, the description is far from complete. It fails to explain what comparison means operationally, what the output looks like, the role of slug and payload_path, or how the caller's live-state response is used.
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. It roughly maps 'caller-supplied verified live-state response' to live_state and 'workspace-contained WordPress payload' to the payload concept, but slug and payload_path are left entirely unexplained. This is insufficient for an agent to understand how to populate the parameters.
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 names a specific operation ('Compare') and two clear resources: a workspace-contained WordPress payload and a caller-supplied live-state response. This is more specific than a tautology and distinguishes it from sibling lookup tools, though it does not say what aspects are compared or what the result means.
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 about when to use this tool versus alternatives like verify_archive_record or find_content_record. The description implies a comparison scenario but never states prerequisites, when the caller should supply a live-state response, or when a sibling tool would be more appropriate.
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?
The description discloses two behavioral traits: the update is additive ('Append') and guarded by optimistic revision control. This implies expected_revision is checked and stale revisions may fail, but it does not explain what happens on mismatch, whether arrays are appended or replaced, which fields are overwritten, or any side effects. With no annotations available, the operational risk is largely undisclosed.
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 sentence with no filler, and the main action is front-loaded. It is appropriately brief from a structural standpoint, though the terseness leaves some terms ('local-artifact') ambiguous.
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?
This is a high-complexity tool: 11 parameters, nested objects, required revision field, no annotations, and no output schema. A one-sentence description is not nearly enough for an agent to construct a valid call confidently. It lacks preconditions, expected_revision behavior, update semantics for partial changes, and clarification of optional fields.
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 had to compensate by explaining the 11 parameters. It only hints at the broad category ('metadata or local-artifact') and ties expected_revision to optimistic concurrency. The nested artifacts object, the semantics of fields like terminology/jurisdictions/source_urls, and how optional fields interact with the update are left 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 identifies a specific action ('Append') on a recognizable resource class ('metadata or local-artifact') and introduces the distinctive concurrency mechanism ('optimistic revision control'). It is not tautological and gives the agent a working idea of the operation, though it does not explicitly say the target is a content record identified by slug or distinguish it from sibling update/record tools.
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 explicit statement about when to use this tool versus alternatives, and no alternative tool names are mentioned. The phrase 'metadata or local-artifact update' implies an editing context rather than publication logging or social recording, but the agent must infer this from sibling names and general semantics. No when-not-to-use guidance is provided.
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 provided, so the description carries the full burden of behavioral disclosure. It only lists what can be searched; it does not describe what the tool returns, whether it returns multiple results, matching behavior, ordering, pagination, or any side effects. For an unannotated tool, this leaves important behavioral questions unanswered.
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 compact sentence with no redundancy, and it front-loads the verb and resource. It could add more structural clarity by mapping fields to parameters, but it is efficient and readable.
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 optional parameters with zero schema-level descriptions, the description is too thin to fully support correct invocation. It does not explain the purpose of each parameter, what a successful response looks like, or how this search relates to the various sibling content tools, leaving meaningful gaps.
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 by explaining parameter meanings. It partially maps to topic and jurisdiction because those terms appear in the field list, but it does not clarify the query parameter's role or how the three parameters interact. The relationship between searching by topic/jurisdiction versus filtering by those fields is ambiguous.
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 verb ('Search') and a clear resource ('archived' content), and enumerates the fields covered: titles, summaries, openings, topics, jurisdictions, and terminology. However, it does not explicitly differentiate this tool from sibling tools like find_content_record or find_content_overlap, so the boundary between them is left to the agent to infer.
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 use when searching the archive across the listed fields, giving reasonable context. But it provides no guidance on when not to use it or which sibling tool would be better suited for record lookup, overlap analysis, or verification. Usage is implicit rather than explicitly contrasted.
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 must carry the full behavioral burden. It does disclose a meaningful behavioral constraint: the tool requires an exact archived excerpt and does not infer approval. But it omits side effects, idempotency, failure behavior, or whether this is a state-changing approval record.
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 tight sentence with no filler. Both the approval action and the key non-inference constraint are front-loaded, making the tool easy to scan.
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?
Given five parameters, three required, no annotations, and no output schema, this description is nowhere near sufficient for an agent to invoke the tool correctly. The meanings of slug, expected_revision, excerpt, approved_by, and note are all undocumented, and the agent is left guessing about how approval is recorded or confirmed.
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 mentions none of the five parameters: slug, expected_revision, excerpt, approved_by, or note. The phrase 'exact archived excerpt' vaguely hints at excerpt matching, but it is far too weak to compensate for the total absence of parameter guidance.
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 ('mark... as approved') and a precise resource ('exact archived excerpt'), so the tool's core purpose is clear. It does not name any sibling tool or contrast itself with them, so it misses the top score for explicit differentiation.
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 phrase 'never infers approval' implies this tool should only be used when an explicit, exact approval is intended, which is a faint usage guideline. However, it gives no alternatives, no when-not-to-use conditions, and no context about how this relates to verification or content-management siblings.
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, the description carries the behavioral transparency burden. It discloses two important non-behaviors: it never publishes and does not infer live state from a payload. However, it does not mention side effects, idempotency, overwrite behavior, whether stale revision data is rejected, or what happens on conflicting information. The negative guarantees are useful but incomplete.
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 wasted words. The primary action is front-loaded, and the clarifying non-behaviors follow immediately. It is appropriately sized for what it attempts to convey.
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?
This is a 14-parameter tool with no annotations, no output schema, and no per-parameter documentation. The description gives only high-level framing and negative guarantees. The agent is left without guidance on required fields like expected_revision and status, optional relationship between fields, and expected behavior for statuses such as 'missing' or 'trashed'. The description is not sufficient to safely invoke this tool correctly.
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 the description does not explain any of the 14 parameters. The phrase 'verified' and 'does not infer live state' provides indirect context that fields like status, expected_revision, and verification-related fields are caller-supplied and trusted as-is, but this does not compensate for the lack of parameter-level guidance. Because the description adds only general context, not specific parameter semantics, it remains a weak performance on this dimension.
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 gives a clear verb and resource: 'Record a verified WordPress outcome.' The added statement 'This tool never publishes and does not infer live state from a payload' helps distinguish it from siblings like compare_payload_to_live_state and clarifies that the name does not imply a publishing action. However, 'outcome' remains somewhat generic, and the exact scope of what counts as an outcome is not defined.
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 tool should be used when recording an already-verified WordPress outcome, and explicitly says it is not for publishing or inferring live state. It does not explicitly state when alternatives should be chosen, nor does it name any sibling tools. Usage context is present but mostly implicit.
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, the description carries the burden of behavioral disclosure. It does disclose that results are only 'potentially' overlapping and require editorial review, which is useful. But it does not clarify whether the operation is read-only, whether it modifies anything, or what the output format looks like.
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, front-loaded sentence with no filler. It communicates action, resource, method, and a critical caveat efficiently.
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 no annotations and no output schema, so the description must explain more than it does. It omits parameter semantics, return value shape, and ranking details, leaving an agent under-equipped to invoke it correctly beyond the basic intent.
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 adds no meaning for either 'slug' or 'limit'. Readers are left to guess what slug refers to and exactly how limit affects ranking. The description does not compensate for the schema's lack of 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 states a specific verb ('Rank') and a clear resource ('potentially overlapping archived content'), and adds the distinctive method ('disclosed lexical overlap'). This distinguishes it from sibling search and record tools without needing to open 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'requires editorial review' implies this tool produces candidate results that need human judgment, giving some usage context. However, it does not explicitly state when to prefer this over sibling tools like find_content_record or compare_payload_to_live_state, nor 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Because no annotations are present, the description carries the full behavioral burden. 'Find exact' communicates exact matching and the read-only tone of 'find' implies no mutation, but it does not disclose how multiple parameters interact, whether zero parameters are allowed, or what happens when no record matches.
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, front-loaded sentence with no filler. Every clause contributes to understanding what the tool does and the identifiers it accepts.
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 annotations, no output schema, and 0% parameter coverage, the tool needs more context to be safely invokable. The description omits behavior on no match, the shape of returned records, and whether multiple provided criteria are ANDed or ORed.
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?
Schema coverage is 0%, but the description maps each property to its domain meaning: content slug, WordPress post ID, and recorded publication/social URL. This adds real value beyond bare property names, though it does not elaborate on optionality or combination rules.
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?
States a clear action ('Find') and resource ('exact archive records') and enumerates three concrete lookup keys. It implies exact-match retrieval, but does not explicitly distinguish itself from sibling get_content_record or search_content_archive, so it misses the top score.
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 says what the tool searches by but gives no when-to-use guidance or reference to alternatives. With siblings like search_content_archive, verify_archive_record, and get_content_record, the agent is left to infer when this exact-record lookup is preferred.
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 provided, so the description carries the full burden of behavioral disclosure. 'Report' weakly implies a read-only operation, but the description does not explicitly state that it makes no changes, whether authentication is required, what happens on failure, or what the report contains beyond vague category names.
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 concise sentence with the main action front-loaded. It contains no filler, though the phrase 'non-publishing safety boundaries' is jargon-heavy and slightly undermines clarity.
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, no output schema, and no annotations, the description provides a minimal but not fully complete picture. It lists three report areas but does not clarify what 'archive health' means, how results are returned, or what 'non-publishing safety boundaries' refers to, leaving an agent to guess.
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 parameter burden to carry. The baseline of 4 applies, and the description correctly omits parameter details that do not exist.
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 clear verb, 'Report', and names the target resource: archive health, storage root, and non-publishing safety boundaries. It is distinct from the sibling content-management tools, though 'non-publishing safety boundaries' is somewhat opaque and would benefit from elaboration.
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 verb 'Report' and the health-related subject imply this tool is for checking server/archive status, but there is no explicit statement of when to use it versus alternatives, nor any exclusions. Usage context is only inferred, not stated.
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 carry the behavioral disclosure burden. It does reveal the append-only nature of the record, but it does not disclose authentication requirements, duplicate-slug handling, whether artifacts can be updated later, failure modes, or what response to expect.
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. It states the core operation, the record type, and the main content categories immediately.
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 is complex: 10 parameters, nested objects, no output schema, and no annotations. One sentence is insufficient to guide an agent on required fields, artifact semantics, metadata fields, or expected behavior. The description provides a high-level purpose but not enough operational context.
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. It groups some parameters under 'local artifacts' and 'editorial retrieval metadata,' but it does not explain the required slug, title, content_type, or the nested artifacts structure. Ten parameters are largely left to the agent to infer from names alone.
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 ('Create') with a distinct resource ('append-only Clearon content record') and adds scope ('local artifacts and editorial retrieval metadata'). This differentiates it from sibling tools that get, search, update, or record publication-related events.
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 use for creating new content records and the 'append-only' wording suggests it is not for updating existing records. However, it does not explicitly state when to use this tool versus update_content_artifacts, record_publication, or search/retrieval siblings.
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 of behavioral disclosure. It communicates that the operation is a read, highlights the append-only nature of the event history, and notes the default inclusion of events. However, it does not mention authentication needs, return format, pagination, or error behavior, which are relevant for an unannotated tool.
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, efficient sentence that front-loads the core action ('Read a content snapshot') and then adds the key default behavior. There is no filler, repetition, or unnecessary explanation.
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?
For a two-parameter read tool with no output schema, the description is minimally adequate. It explains the main purpose and default event-history behavior, but it leaves return shape, slug semantics, and any operational constraints implicit. More context would be needed to make invocation fully reliable without inspecting other documentation.
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 must compensate. It partially does: 'by default, its complete append-only event history' clarifies that include_events=true controls whether history is returned. However, the required 'slug' parameter is not explained at all beyond the schema, leaving its format and role implicit.
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: 'Read a content snapshot and, by default, its complete append-only event history.' It clearly conveys that the tool retrieves a content record and optionally its event history. However, it does not explicitly differentiate itself from the similarly named sibling 'find_content_record', so it misses full sibling differentiation.
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 tool should be used when you need a content snapshot and/or its append-only event history. It gives no explicit guidance about when to prefer this tool over alternatives like find_content_record or search_content_archive, and it provides no exclusionary conditions.
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 supplied, the description carries the burden of explaining behavior. It discloses the selection criteria and the 'or' semantics among the three missing conditions, which is useful. However, it does not state whether the operation is read-only, whether verification is live or cached, or what the returned records contain beyond matching the criteria.
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 sentence with no filler. The action and criteria are front-loaded, and every word contributes to defining the tool's behavior.
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 zero-parameter listing tool, the description is largely complete: it defines exactly which records are returned. It could add detail about the output shape or ordering, but the absence of parameters and the straightforward nature of the operation keep the gap small.
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 and schema description coverage is 100%, so there are no parameter semantics to clarify. The description does not need to compensate for any schema gaps, and the baseline for a no-parameter tool applies.
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 names a specific verb ('List'), a resource ('records'), and three concrete filtering criteria (missing verified WordPress publication, featured-image verification, or completed LinkedIn/X outcomes). It is clear and helps distinguish this tool from generic list/search siblings, though it does not explicitly contrast it with list_update_candidates.
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 about when to prefer this tool over sibling tools or when not to use it. The intended use is only implied by the purpose statement, and no exclusions or prerequisites are mentioned.
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 must carry the behavioral transparency burden. It does disclose a key behavioral trait: the operation appends rather than rewrites prior history, suggesting non-destructive behavior toward existing archive records. However, it does not explain concurrency behavior around expected_revision, what happens on mismatch, whether the operation is idempotent, or what response/errors to expect.
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. It conveys the core action immediately ('append a provenance correction') and adds the most important behavioral constraint ('without rewriting the earlier archive history') in a compact way. Every word contributes value.
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 8 parameters, 6 required fields, no annotations, no output schema, and no schema descriptions, this one-sentence description is insufficient for an agent to call the tool correctly. The agent cannot determine what values are valid for field, how expected_revision is used, what source_url and corrected_at mean, or what success/failure looks like.
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 the description provides almost no parameter-level meaning. The word 'correction' loosely implies previous_value and corrected_value, but the critical fields slug, expected_revision, field, and reason are not explained. With 8 parameters and zero schema descriptions, the description should compensate far more than it does.
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 states a specific verb ('append'), a specific resource ('provenance correction'), and an important qualifier ('without rewriting the earlier archive history'). This clearly differentiates it from sibling tools like update_content_artifacts or record_publication, which imply modification or new event recording rather than append-only correction.
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 phrase 'without rewriting the earlier archive history' implies this tool is appropriate when preserving audit history matters, but it never explicitly says when to use this tool versus alternatives like update_content_artifacts or verify_archive_record. No sibling tool is named, and no when-not-to-use condition is stated, so usage guidance remains mostly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool replays the event log and does not repair, implying a non-mutating verification operation. This is meaningful behavioral context, though it does not mention potential performance costs or whether any state is touched during replay.
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, well-structured sentence that front-loads the core action and adds the key qualifier about not repairing. Every word adds value, with no filler or repetition.
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 definition lacks parameter explanations, return value details, and any notes on prerequisites or side effects. Given there is no output schema and no annotations, a single sentence is insufficient for an agent to confidently invoke this tool, especially with an ambiguous boolean parameter.
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 does not explain either parameter. 'slug' is inferable from the tool name, but 'include_rebuilt_snapshot' is completely undefined. The description must compensate for the low schema coverage and it does not.
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 clearly states a specific verb+resource: replay an append-only event log and confirm whether it matches the stored snapshot. It also distinguishes the tool from destructive or repair-oriented siblings by explicitly adding 'without repairing it.' This makes the tool's purpose unambiguous.
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 use case: verify the integrity of an archive record against its snapshot. It hints at a non-repair boundary but does not explicitly name alternatives or state when to prefer this tool over siblings like compare_payload_to_live_state or update_content_artifacts. An agent gets the general context but no explicit routing guidance.
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 behavioral disclosure burden. It does disclose a relevant behavior: the tool does not make editorial recommendations, which clarifies output intent. However, it does not explicitly state that the operation is read-only, nor does it mention pagination, limits, or other side-effect-related behavior.
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 compact sentence with no fluff. It front-loads the core listing purpose and appends the important caveat about editorial recommendations, so every part earns its place.
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?
The tool is relatively simple with one optional parameter and no output schema. The description communicates the main output categories, but it does not explain the meaning of older_than_days, the output shape, or any filtering/behavioral nuances, leaving an agent with incomplete information for a fully confident invocation.
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 coverage is 0% and the description does not mention the sole parameter older_than_days at all. The parameter name and default value 90 hint at a staleness threshold, but the description adds no semantic guidance about how the parameter affects the results, which is a significant gap.
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 enumerates three concrete resource categories: mechanically stale publications, post-publication source corrections, and image-verification gaps. It also includes a clarifying exclusion ('does not make editorial recommendations') that distinguishes this from a recommendation-oriented tool despite the 'candidates' naming.
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 tool is appropriate when the agent needs to surface stale publications, source corrections, or image-verification gaps. However, it does not explicitly state when to prefer this tool over alternatives such as list_incomplete_follow_through, nor does it provide exclusions beyond 'does not make editorial recommendations.'
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, the description carries the full behavioral burden. It does disclose the important side-effect boundary 'This tool never posts,' which helps an agent understand it won't mutate external social platforms. However, it does not explain the write semantics, what happens with expected_revision mismatches, whether it creates or updates records, or what errors/return values to expect.
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 sentences, front-loaded with the purpose and followed by the critical non-posting boundary. Every word earns its place; there is no filler or repetition.
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 the absence of annotations, lack of output schema, 11 parameters, and 4 required fields, the description is too thin. It provides a clear one-line purpose but does not cover the required concurrency-related field, return behavior, failure modes, or expected preconditions. An agent would have to guess at important invocation details.
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 11 parameters. It loosely covers 'url,' 'scheduled_at/status,' 'queued,' and 'blocker,' but it leaves required parameters like 'slug' and 'expected_revision' completely unexplained, and it also omits 'copy_path,' 'activity_id,' and 'published_at.' This is insufficient for correct invocation.
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 and resource: 'Record a LinkedIn or X outcome' and enumerates the kinds of outcomes (published URLs, schedules, queues, blockers). The explicit statement 'This tool never posts' clearly separates this from any publishing/post tool, including sibling record_publication.
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 gives clear positive context: use this to log a LinkedIn or X outcome. It also gives a when-not signal with 'This tool never posts,' implying it should not be used when the intent is to publish. It does not name explicit alternatives, so it stops short of a 5.
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 behavioral disclosure burden. It communicates that the tool produces counts across multiple content categories, implying a read-only aggregate operation, but it does not disclose whether it creates a persistent artifact, whether it performs live queries, or what the response structure looks like.
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, clear sentence that leads with the action and immediately specifies the content categories covered. Every word adds value and there is no redundant or extraneous text.
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 zero-parameter tool, the description adequately explains what is produced: a structured inventory of counts for six listed categories. Since there is no output schema, a slightly more explicit statement of the return format or that this is a read-only snapshot would improve completeness, but it is largely sufficient.
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 input schema has zero parameters, so there is no parameter documentation burden on the description. The baseline of 4 applies because the tool takes no inputs and requires no parameter explanation.
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 ('Generate') and resource ('current structured inventory') and enumerates exactly which categories are counted: archive, publication, social, topic, correction, and voice-example. This clearly distinguishes it from sibling tools that operate on individual records.
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 phrase 'current structured inventory' implies this is for obtaining an aggregate overview rather than a specific record, which gives some usage context. However, the description does not explicitly state when to use this tool vs alternatives like get_content_record or search_content_archive.
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-content-archive-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-content-archive-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-content-archive-mcp)

Score Badge

Copy to your README.md:

[![clearon-content-archive-mcp MCP server](https://glama.ai/mcp/servers/kwgoodwin/clearon-content-archive-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kwgoodwin/clearon-content-archive-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-content-archive-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server