54ch10-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clear, distinct purpose: risk brief, paste read/write, WHOIS, DNS, TLS, URL normalization, hashing, encoding, and fetching. No two tools overlap in functionality; even the paste_read/write pair is clearly complementary. The risk brief covers a broader scope but doesn't conflict with the specific lookup tools.
Naming Consistency5/5
All tool names are lowercase and follow a consistent verb-oriented pattern (brief, fetch, hash, encode, paste_read, paste_write). The use of hyphens in normalize-url and underscores in paste_read/paste_write is uniform across compound names, and there is no mixing of camelCase or different verb styles. The naming is predictable and easy to understand.
Tool Count5/5
The server presents exactly 10 tools, squarely within the optimal 3–15 range. Each tool contributes a distinct capability without redundancy, and the count feels well-scoped for a security/analytics utility server. There is no sense of bloat or insufficiency.
Completeness5/5
The tool surface covers the core workflows implied by the server's purpose: risk assessment (brief), domain intelligence (whois, dns, tls), URL handling (normalize-url, fetch), text utilities (hash, encode), and ephemeral storage (paste_read/write). The paste implementation is appropriately minimal with TTL-based read and write, and the absence of delete/update is expected for ephemeral data. No obvious missing operations for the stated domain.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must disclose behavioral traits, but it only names the formats and calls it a utility. It does not clarify that encoding is deterministic and side-effect-free, nor does it mention input length limits (maxLength 65536) or that the output is a plain string. The description adds no insight beyond what the schema already implies.
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 and front-loads the core action and formats. However, the unnecessary '54ch10' and the redundant 'Utility' label introduce minor noise; removing them would make it tighter. Overall, it is still efficient and easy to scan.
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?
Given the tool's simplicity (two parameters, no output schema), the description is minimally adequate: it identifies the action and supported encodings. It falls short of fully contextual completeness by not explaining the return value (a string) or any constraints/limitations, and the unexplained '54ch10' creates a gap in understanding. For a basic utility, this is sufficient but not thorough.
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 coverage is 100%, so the baseline is 3. The description repeats the format parameter's enum values but adds nothing about the 'q' parameter; the phrase '54ch10' is obscure and does not clarify parameter meaning. The description does not hinder comprehension, but it also does not enrich what the schema already documents.
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 clear action 'Encode text' and explicitly lists the encoding formats (base64|hex|url), so the tool's purpose is unambiguous. The cryptic token '54ch10' is unexplained and adds noise, and 'Utility' is generic filler. It is distinct from sibling tools like hash, normalize-url, or fetch, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or situations where another sibling (e.g., hash) would be more appropriate. The single phrase 'Utility' provides no contextual direction.
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 must carry the burden of behavioral disclosure. It mentions the underlying mechanism (Cloudflare DoH) and 'fraud-signal style flags', but it does not describe the return format, whether it makes network calls, any rate limits, or what the flags mean and how to interpret them. For an unannotated tool, this is a significant gap in transparency.
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 highly concise: a single sentence that packs purpose, mechanism, and a key usage caveat. It is front-loaded with the core purpose and avoids unnecessary verbosity. Every word 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?
For a tool with a single, well-defined parameter and no output schema, the description is minimally adequate. It explains what the tool does and one usage restriction. However, the absence of an output schema and lack of explanation about the 'fraud-signal style flags' leave an agent uncertain about the result structure and interpretation, making completeness only partial.
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 100% description coverage for the single parameter (domain), providing basic semantics like 'Domain name (e.g. example.com)'. The description adds the DNS-specific context but does not provide additional syntax, formats, or edge cases beyond what the schema already states. At 100% coverage, a baseline of 3 is appropriate.
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?
Description clearly states the tool's purpose: 'DNS A/AAAA/MX/NS summary via 54ch10 (Cloudflare DoH)'. This identifies the specific resource (DNS) and typical record types, distinguishing it from siblings like whois or tls that serve different functions. However, it does not explicitly contrast with whois or other related tools, leaving some ambiguity about when to prefer this over a more general DNS lookup.
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 'Analytics-only — not clearance' gives context on intended usage and explicitly states it is not for clearance decisions. This provides a partial guideline, but it does not explain when to use this tool versus alternatives like whois or tls, nor does it mention any prerequisites or limitations beyond the analytics-only caveat.
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 must carry the behavioral burden. It discloses that output is hex + base64, which is useful, but omits details like determinism, performance, or error behavior. For a simple hash utility this is acceptable, but not comprehensive.
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 concise in a single sentence, but the unexplained '54ch10' is cryptic and may hinder comprehension. It front-loads the action but the quality is reduced by this opaque term.
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?
No output schema exists, but the description explains the return format ('hex + base64'). It lacks mention of input size limits (though schema includes maxLength) and error handling. For a simple utility, it is barely adequate but could be clearer.
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 covers 100% of parameters (q, algo) with descriptions and enum for algo. The description adds no additional parameter-specific details, so it rides on the schema's full coverage. Baseline of 3 is appropriate.
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 (hash), resource (UTF-8 text), and algorithm list (sha256, sha1, md5), clearly distinguishing it from siblings like encode. However, the cryptic '54ch10' reference adds ambiguity and could confuse an agent.
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 provides a clear when-not-to-use exclusion ('not crypto advice'), implying it is for non-security contexts. While it doesn't name an explicit alternative tool, this guidance helps agents route correctly.
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 disclose behavioral traits itself. It does mention 'ephemeral' and 'TTL-bound', which are key traits, and clarifies it is not a vault. However, it does not disclose the return format, error behavior (e.g., expired id), or any access restrictions. For a simple read tool, some disclosure exists but more could be added given the lack of 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, front-loaded sentence that states the action and key qualifier ('ephemeral', 'TTL-bound') immediately, followed by a clarifying negative. Every word earns its place, with no redundancy or filler. It is appropriately concise for a simple tool.
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 tool's simplicity (1 required parameter, no output schema, no annotations), the description is mostly complete. It conveys the core behavior (retrieve ephemeral paste) and the negative constraint. Minor gaps include not specifying the return format or behavior on expired ids, but these are not critical for a trivial read operation. Overall, it is sufficient for an agent to understand the tool's function.
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 100%, so the parameter 'id' is fully documented in the schema with min/max length and a description. The tool description adds the context 'TTL-bound' but does not provide additional semantic meaning beyond the schema. Per the baseline rule, a score of 3 is appropriate when schema covers the parameters and the description does not compensate further.
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 verb 'Retrieve' and the resource 'ephemeral 54ch10 paste by id', which is specific and distinguishes it from other sibling tools. The added 'NOT a vault' clarifies it is not a persistent storage tool, further differentiating its purpose. This is a precise, non-tautological statement.
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?
While the description implies usage (you need an id from paste_write), it does not explicitly state when to use this tool versus alternatives. It mentions 'NOT a vault' but this is a property, not a usage condition. No exclusions or comparisons to sibling tools (like paste_write) are provided, so an agent gets no guidance on selection among related tools.
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 states the output format and the analytics-only nature, which suggests a read-only operation. It does not explicitly mention side effects, authentication, or rate limits, but for a simple query tool, this is acceptable.
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 that front-load the purpose and output, then add a valuable caveat about the tool's scope. There is no redundancy or wasted wording.
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 2-parameter tool with no output schema, the description adequately covers what it does, what it returns, and its limitations. It explains the input types and the output components without omitting critical information an agent would need.
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 coverage is 100%, so both parameters are already described in the input schema. The description adds little beyond the schema, only reiterating that 'q' can be an address, token, or URL and noting the output. Baseline 3 is appropriate given the high schema coverage.
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's purpose: providing a risk brief for an EVM address, token, or URL. It lists specific output components (score, band, flags, summary, sources) and specifies the API source. This distinguishes it from siblings like whois or fetch, which serve different data-retrieval purposes.
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 provides context by noting it is 'analytics-only' and not clearance or financial advice, which implies caution about interpretation. However, it does not explicitly mention when to prefer this tool over siblings or any exclusions. The usage scenario is implied rather than stated.
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. It discloses the method (crt.sh + HTTPS reachability), which is useful behavioral context, and hints at a read-only analytics use case. However, it does not mention potential side effects (likely none), error behavior for invalid domains, rate limits, or whether external network calls may fail. The disclosure is sufficient but not comprehensive.
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 that front-loads the core action and output, with no wasted words. Every clause adds value: the source, the output fields, and the usage caveat are all packed efficiently.
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 tool with one well-documented parameter and no output schema, the description is largely complete. It explains what the tool does, what it returns, and the context for using it. The only minor gap is that it doesn't clarify the exact format of 'flags' or the reachability result, but that's not critical for the agent to call the tool, so a 4 is justified.
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 100% coverage for the single 'domain' parameter, so the description does not need to elaborate beyond the schema. It adds no additional meaning to the parameter itself, only describing the tool's overall method. The baseline of 3 is appropriate because the schema already documents the parameter adequately.
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 verb (summarize) and resource (TLS/CT certificate), and enumerates the specific outputs (issuer, validity window, flags). It also names the underlying source (54ch10, crt.sh + HTTPS reachability), which distinguishes it from siblings like whois or dns without needing to reference them explicitly.
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 'Analytics-only — not clearance' gives partial context about intended use (analytics, not security clearance checks), but it does not explicitly tell the agent when to choose this over alternatives like fetch or whois, nor does it mention exclusions. The guidance is implied rather than stated, so it falls short of a clear usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly reveals the SSRF-safety, the return payload (status, contentType, markdown|text), the size limit (200KB), and the intended scope (analytics-only). This is substantial and goes beyond a generic fetch description.
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, dense sentence that front-loads the core action and packs in all key behavioral constraints without fluff. Every clause earns its place: action, safety, return type, size cap, usage scope.
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 two-parameter fetch tool with no output schema and no annotations, the description covers the essential return information (status, contentType, content format) and constraints (SSRF-safe, 200KB cap, analytics-only). It lacks explicit details on error handling or redirects, but these are minor for this tool's simplicity.
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 100% (both url and format have descriptions). The description adds no new parameter-specific detail beyond what the schema already states (public URL, output format enum). It reinforces 'public' and the markdown|text options, but this is redundant with the schema, so baseline 3 applies.
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 action 'Fetch a public URL' and adds differentiating specifics: SSRF-safe, returns status/contentType/markdown|text, 200KB cap, and analytics-only use. This distinguishes it from siblings like whois, dns, or normalize-url without needing to name them.
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 is provided. It doesn't mention sibling tools or conditions that would route an agent to fetch instead of paste_read, whois, etc. The 'Analytics-only' note is a restriction, not usage direction. There is no 'use when' or 'not for' 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, the description must carry behavioral disclosure. It does disclose the transformations performed (lowercasing, stripping fragment, sorting query), which is helpful. However, it does not mention error handling, idempotency, or explicitly state that the operation is read-only (though 'Analytics-only' hints at a usage restriction, not side effects). A bit more context on return value would be useful.
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 leads with the verb and immediately states the core behavior and the 'Analytics-only' qualifier. There is no unnecessary padding; every word adds information.
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 utility with no output schema, the description is mostly complete. It defines the transformation and hints at its use case. However, it does not explicitly state that the output is the canonicalized URL string, which the absence of an output schema leaves open. Still, this is a minor gap given the simplicity of the function.
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 schema description for parameter 'q' merely states 'URL to normalize/canonicalize', which is generic. The tool description adds concrete meaning by explaining what normalization entails (lowercasing, fragment stripping, query sorting). This adds value beyond the schema, so it warrants a 4 despite 100% coverage.
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 canonicalizes a URL and specifies the exact transformations: scheme/host lowercased, fragment stripped, query sorted. This is a specific verb and resource that distinguishes it from all sibling tools, which are unrelated (DNS, whois, hashing, encoding, etc.).
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 'Analytics-only' implies a usage context, but no explicit when-to-use vs. alternatives is provided. Since the tool is a generic URL normalizer, usage is implied for any situation requiring a canonical URL, but there is no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral disclosure. It notes the tool is read-only ('lookup') and analytics-only, but does not disclose potential limitations like data freshness, rate limits, or how errors are handled. It adds some context but lacks comprehensive transparency.
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 concise sentence with no fluff. It front-loads the purpose and includes essential details (returned fields, usage context) without redundancy, achieving maximum clarity per word.
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 tool with one parameter and no output schema, the description is quite complete: it lists expected return fields, indicates the use case (fraud-signal helper), and warns against misuse (not clearance). It could mention error behavior or data source reliability, but these are minor for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the sole parameter (domain name) fully, including an example. The description does not add any additional semantic detail beyond what the schema already provides, so a baseline 3 is appropriate.
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 'WHOIS/RDAP domain lookup' with specific verb and resource, and lists the key outputs (registration, registrar, age_days, status, nameservers). This clearly distinguishes it from siblings like dns, tls, and encode, making the tool's purpose immediately obvious.
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 provides context ('analytics-only fraud-signal helper') and an exclusion ('not clearance'), which helps the agent understand when it is appropriate to use. However, it does not explicitly mention alternative tools or contrast with siblings, so it falls short of full guidance.
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 provided, the description carries the full burden of behavioral disclosure. It goes beyond the schema by explaining the ephemeral nature, TTL behavior (default 1h, max 24h), the backend implementation, and the explicit exclusion from being a vault. It does not mention the response format or any auth requirements, but given the simplicity and focus on 'agent handoff', this is a reasonable level of transparency.
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 exceptionally concise: two sentences that pack the core function, backend details, TTL constraints, and purpose without any fluff. Every phrase contributes meaning, and the most critical differentiator ('NOT a vault') is front-loaded clearly.
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 two-parameter tool with no output schema, the description covers the essential aspects: purpose, TTL limits, ephemerality, and usage context. It does not specify the return value (e.g., a paste ID or URL), but given the presence of paste_read as a sibling, an agent can infer the retrieval flow, and the simplicity of the tool doesn't demand more. Slightly more detail on expected output would be beneficial but not critical.
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 input schema already documents both parameters (content and ttl_seconds) with 100% coverage. The description adds human-readable TTL units (1h, 24h) and the context of 'short ephemeral paste' for content, which slightly enhances understanding. However, since the schema covers the essential semantics, the description contributes minimal additional value, keeping this at the baseline.
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 verb 'store' and the resource 'paste', and defines the scope as 'short ephemeral' with a backend ('54ch10'). It explicitly distinguishes from a vault and names the intended use case ('agent handoff'), which differentiates it from sibling tools like paste_read without opening their schemas.
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 provides clear usage context: it is for storing short ephemeral pastes for agent handoff, not for long-term storage (NOT a vault). It specifies TTL defaults and limits, which guide when to use it. However, it does not explicitly state when not to use it or name alternative tools (e.g., paste_read for retrieval), though the purpose is clear enough for an agent to infer.
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:

[![54ch10-mcp MCP server](https://glama.ai/mcp/servers/sachio222/54ch10-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sachio222/54ch10-mcp)

Score Badge

Copy to your README.md:

[![54ch10-mcp MCP server](https://glama.ai/mcp/servers/sachio222/54ch10-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sachio222/54ch10-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/sachio222/54ch10-mcp'

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