charactercheck-mcp

Server Quality Checklist

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

Latest release: v0.6.2
Disambiguation3/5
Several tools (derive, report, stance, seatpack, intake) all produce some form of character assessment, but their descriptions specify distinct focuses (deterministic values, trust reports, pre-combat context, privacy-minimized context, pre-session prep). qa and quiz both involve questions but differ in coverage inventory vs. finding prompts. With detailed descriptions an agent can likely disambiguate, but the boundaries are not immediately obvious.
Naming Consistency2/5
Tool names are all lowercase single words, but mix verbs (derive, diff), nouns (stance, report), and cryptic compounds (seatpack, selftest) without a consistent verb_noun pattern. This makes it hard to predict what a tool does from its name. There is no discoverable naming scheme.
Tool Count4/5
At 11 tools, the count is within the reasonable 3-15 band, but includes two maintenance/diagnostic tools (selftest, doctor) that seem tangential to the core character-checking purpose. Slightly heavy, but each character-focused tool earns its place.
Completeness4/5
For a read-only character validation domain, the set covers observation (snapshot), comparison (diff), assessment (derive, report), context (stance, seatpack, quiz, intake), and self-testing (selftest, doctor). Minor gaps: no batch processing or field-level catalog, but core workflows are complete.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on August 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and open-world behavior, which the description doesn't contradict. The description adds the report's content categories, but terms like 'canonical trust' and 'field assessments' remain undefined. It doesn't disclose output format or other behavioral nuances, but with annotations covering safety, this is a modest contribution.
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 short sentence with no unnecessary words, so there is no fluff. However, it is under-specified rather than appropriately concise—it omits critical details such as the action the tool performs and the meaning of the 'ref' parameter, making the brevity a disadvantage.
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?
Even though an output schema exists, the description is too sparse to understand the tool's purpose or input. With one required parameter that is completely unexplained and a vague behavioral description, the agent cannot confidently select or invoke the tool. The description is not complete enough for a tool of this complexity.
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?
The only required parameter 'ref' is a plain string with no description in the schema, and the tool description provides zero information about what it refers to (e.g., a repository ref, a file reference, or an ID). With 0% schema description coverage, the description fails to compensate, leaving the agent completely in the dark about the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase listing content categories ('Canonical trust and field assessments plus unhandled and lint findings') without a verb or explicit action. It doesn't clearly state that the tool produces a report or any other operation, and it doesn't distinguish this from sibling tools like stance or qa. This is vague rather than a complete tautology.
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. The description mentions no scenarios, prerequisites, or exclusions, and the sibling tools are not referenced. An agent gets no information about when 'report' is the appropriate choice.
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?
Annotations already indicate read-only, non-destructive behavior. The description adds context about pre-combat and a requirement for confirmation from a player or session-host, which gives some behavioral insight beyond the annotations. However, it remains ambiguous whether the tool itself performs the confirmation or just reports the need for it.
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 short, consisting of two sentences, but the first is an awkward noun phrase that sacrifices clarity for brevity. It is not efficiently structured, though there is no excess wordiness.
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?
Despite having an output schema and annotations, the description leaves the tool's core purpose ambiguous and fails to explain the 'ref' parameter. The pre-combat context is a hint but not enough to understand the tool's operation or invocation correctly.
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?
The schema has one parameter 'ref' with no description, and the description provides no explanation of the parameter. Schema description coverage is 0%, and the description does not compensate at all, leaving the agent without any guidance on what 'ref' refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks an explicit verb or action. "Pre-combat context with canonical assessment" is a noun phrase that does not clearly state what the tool does. It is vague and does not distinguish the tool from siblings like derive, qa, or report.
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 guidance on when to use this tool versus alternatives. The second sentence mentions a domain requirement (confirmation of hand/equipment state) but does not connect it to the tool's usage or mention any exclusions or alternative tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context about the packet contents (e.g., supported-coverage state, questions to resolve, player-declared fields), which helps the agent understand the tool's output. However, it does not explain behavioral aspects like whether a valid 'ref' is required for existing sessions.
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 sentence with a colon-separated list, making it compact but dense. It uses unexplained jargon like 'supported-coverage state' and 'baseline-snapshot hint', which reduces readability. It is not front-loaded with the most essential information and does not clearly state what the tool does.
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 one required parameter that is completely undocumented, and the description gives no clue about its purpose. It also lacks usage context and sibling differentiation. While an output schema exists, the description still fails to explain the input, making the tool incomplete for an agent to invoke correctly.
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?
The schema has one required parameter 'ref' with no description, and schema description coverage is 0%. The description does not mention 'ref' at all, so the agent has no idea what value to provide. With zero compensation from the description, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists the contents of a 'pre-session packet' but lacks an explicit verb like 'generates' or 'returns'. It is specific about the resource but does not clearly distinguish itself from siblings like 'snapshot' or 'report' that might also provide state summaries.
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 phrase 'pre-session' implies use before a session, but the description gives no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tools are mentioned, leaving the agent to 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable context: the persona is never exposed, and mutable player-authority state is marked rather than trusted. This goes beyond the annotations and provides useful behavioral disclosure. No contradiction with annotations.
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 two sentences totaling about 22 words, with no redundant phrasing. It is compact and front-loaded with the 'privacy-minimized read-only' qualifier, though the first sentence's vagueness slightly detracts from immediate comprehension.
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?
Despite having an output schema, the description lacks essential context: it does not explain the input parameter 'ref', provide usage scenarios, or relate to sibling tools. The minimal description is insufficient for an agent to confidently invoke the tool correctly.
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?
The schema has one required parameter 'ref' with 0% description coverage. The tool description does not explain what 'ref' means, leaving the agent to guess whether it is a character ID, a reference, or something else. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a noun phrase 'character context' without a clear verb, making it ambiguous whether the tool fetches, lists, or computes context. It emphasizes privacy and read-only but does not distinguish itself from sibling tools like 'snapshot' or 'derive'.
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 explicit guidance on when to use this tool versus alternatives. It implies use for character context needs but does not state when NOT to use it or reference sibling tools like 'qa' or 'stance'.
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?
Annotations already declare the tool as read-only, non-destructive, and open-world. The description adds behavioral context by stating that each answer carries its question and a 'closed trust state' and that the output is not a validity score. This goes beyond the annotations and helps the agent understand the output semantics, though it does not address prerequisites or side effects.
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 sentences, front-loaded with the command and immediately followed by output clarification. Every word contributes meaning, with no redundant or filler content. It is appropriately sized for the tool's complexity.
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 presence of an output schema covers return values, but the description lacks parameter semantics and provides minimal context for the domain-specific 'Coverage Inventory'. An agent would need additional information about what inputs are required and when this tool is appropriate, making the description incomplete despite the concise structure.
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?
The input schema includes two parameters ('ref' and 'full') with no descriptions, and the schema description coverage is 0%. The tool description does not mention either parameter, leaving the agent with no information about what 'ref' refers to or what 'full' controls. This is a critical gap for correct invocation.
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 clearly states a specific action ('Run') and a specific resource ('the 100-question extraction Coverage Inventory'), and it clarifies that the output is not a validity score. However, the term 'Coverage Inventory' is undefined and the description does not explicitly distinguish this tool from siblings like 'quiz' or 'report', so it falls short of full clarity.
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 provides no explicit guidance on when to use this tool versus alternatives. The phrase 'this is not a validity score' hints at a distinction from something else, but it does not name an alternative or explain under what conditions this tool should be chosen. Without this, an agent cannot reliably decide between this and sibling tools.
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?
The description adds value beyond the annotations by disclosing that 'expected answers exist only for canonical trusted fields; mutable or uncertain fields remain null.' This provides insight into output behavior and field handling that the annotations (readOnlyHint, openWorldHint) do not fully capture.
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 concise, consisting of two short sentences that each convey meaningful information. It is front-loaded with the primary purpose and adds a critical behavioral detail without any redundant or unnecessary wording.
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?
While the output schema exists and annotations are present, the description fails to explain the 'ref' parameter or provide usage context. For a tool with a single required parameter and zero schema coverage, the description leaves significant gaps in understanding how to invoke it correctly.
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?
The input schema contains one parameter 'ref' with no description, and schema description coverage is 0%. The description does not mention 'ref' or explain its meaning, format, or possible values, leaving the agent without necessary parameter semantics.
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 clearly identifies the tool as providing 'settlement and sheet-specific finding prompts' in a 'read-only' manner, which conveys its purpose. However, it lacks an explicit verb like 'returns' or 'provides,' and does not distinguish itself from sibling tools beyond the topic.
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 guidance on when to use this tool versus alternatives. The description only states what the tool is, without mentioning situations where it should or should not be used, nor any reference to sibling tools.
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?
Beyond the annotations (readOnlyHint, destructiveHint), the description adds behavioral details: 'No mutation is applied' reinforces the read-only nature but also explains the output behavior 'unclassified changes are named.' The phrase 'supported subset' discloses a limitation, which is valuable context not captured by annotations.
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, tightly worded sentence. It front-loads the action ('Classify') and immediately specifies the scope, with no unnecessary words or repetition.
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?
Given the annotations and presence of an output schema, the description is largely complete for understanding the tool's core function. It covers the input concept, the behavior, and a key limitation. However, the lack of explicit parameter mapping and any mention of error scenarios or prerequisites leaves minor gaps, so it does not earn a 5.
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?
With 0% schema_description_coverage, the description must compensate by explaining the parameters. It mentions a 'supplied CharacterSnapshotV1 object' and a 'freshly observed public character,' but does not map these to the actual parameter names 'ref' and 'baseline.' This leaves ambiguity about which parameter is which, especially since 'ref' is a string and 'baseline' is an object.
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 'Classify' and a precise resource: 'changes between a supplied CharacterSnapshotV1 object and a freshly observed public character.' This clearly distinguishes it from sibling tools like 'snapshot' or 'derive' by focusing on difference classification rather than creation or derivation.
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 usage context—when you need to classify changes between a saved snapshot and a current public character—but it does not explicitly state when to choose this tool over alternatives or provide exclusion criteria. Sibling tool names are present but not referenced.
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?
The description goes beyond annotations by specifying which fields are omitted (account identifiers, linked images, persona) and highlighting the versioned nature of the snapshot. This useful context is not present in the annotations, and there is no contradiction.
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 concise sentences, front-loaded with the main action, and contains no redundant information. Every word adds value.
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 simple single-parameter tool with output schema and rich annotations, the description covers the key return behavior and privacy filtering well. However, the unclear 'ref' parameter and lack of usage guidance leave minor gaps, preventing a perfect score.
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 only parameter 'ref' is completely undocumented in the schema, and the description does not explain what 'ref' refers to. With 0% schema coverage and no compensating description, the agent lacks essential parameter semantics.
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 identifies the action ('Observe a public character once') and the return type ('CharacterSnapshotV1'), with specific details about privacy filtering and omitted fields. This distinguishes it from sibling tools like derive or diff, making its 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 a read-only, one-time snapshot use case but does not explicitly compare with alternatives or state when not to use. It lacks explicit alternatives or exclusions, so the agent must infer when to choose this over siblings.
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?
Despite readOnlyHint=true already covering safety, the description adds 'deterministic' and 'unsupported/unknown findings,' which disclose output behavior beyond the annotation. It also clarifies the partial scope beyond any annotation info.
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 extremely concise, using only two sentences to convey purpose, scope, and input requirements. Every phrase 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description covers the necessary context: what it does, its scope, and input format. The output schema handles return value details, so the description is complete for its complexity.
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?
Input schema already describes 'ref' as a DDB URL or id at 100% coverage, but the description adds 'exact public' as a constraint not present in the schema. This extra semantic detail helps the agent understand acceptable inputs.
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 clearly states the tool compiles selected character fields into specific outputs (deterministic values, trust states, provenance, lint). It includes a scoping note about partial read-only context, which differentiates it from full rules validation, though it does not explicitly distinguish from 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'partial read-only context, not complete rules validation,' suggesting it is for lighter checks rather than full validation. It does not explicitly name alternatives or state when-not-to-use, so guidance is implied rather than explicit.
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?
Annotations already convey read-only and non-destructive behavior. The description adds valuable behavioral details: each check reports PASS/FAIL, the first failure carries a remedy, and providing a ref enables an additional reachability check. This goes beyond the annotations without contradicting them.
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 that lists all checks and the output behavior without unnecessary words. It is concise and structured effectively for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of an output schema, and annotations declaring read-only behavior, the description is complete. It covers the full scope of checks, the PASS/FAIL output format, and the remedy behavior, leaving no significant gaps.
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?
The schema has one optional 'ref' parameter with no description (0% coverage). The description adds meaning by stating that 'with a ref' reachability of that character is checked, but it does not fully specify the expected format or what 'ref' refers to. Partial compensation for low schema coverage warrants a 3.
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 the tool diagnoses why something is not working, listing specific checks (python, DNS, outbound HTTPS, and reachability of a character with a ref). This distinguishes it from sibling tools by specifying exact diagnostic resources and implied use case.
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 implies when to use it (when something is not working in these specific areas) but does not explicitly mention alternatives or when not to use it. It provides clear context without exclusions, which fits the 'clear context, no exclusions' level.
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?
Annotations already declare read-only and idempotent. The description adds context: no network or D&D Beyond account needed, and it operates against a bundled sample. This enriches the safety profile beyond the annotations without contradicting them.
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: the first defines the action and constraints, the second provides usage sequencing. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with a bundled-sample check and rich annotations, the description covers the essential context: purpose, prerequisites, and diagnostic role. The output schema handles return-value details.
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; the baseline for 0 params is 4. The description mentions the bundled sample character, which provides context on what the check uses, but no parameter semantics are needed.
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 explicitly states the tool's function: 'Check the offline installation against a bundled sample character.' It clarifies scope (offline, no network/account/character) and differentiates it from tools that require external resources, making the purpose distinct.
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 when-to-use guidance: 'Run this first when bootstrapping' and provides a decision heuristic ('separates the tool is broken from I cannot reach that character'). It does not name alternative sibling tools explicitly but implies prerequisites are unnecessary.
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:

[![charactercheck MCP server](https://glama.ai/mcp/servers/chaoz23/charactercheck/badges/card.svg)](https://glama.ai/mcp/servers/chaoz23/charactercheck)

Score Badge

Copy to your README.md:

[![charactercheck MCP server](https://glama.ai/mcp/servers/chaoz23/charactercheck/badges/score.svg)](https://glama.ai/mcp/servers/chaoz23/charactercheck)

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/chaoz23/charactercheck'

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