Self MCP Server

Server Quality Checklist

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

Latest release: v0.0.1
Disambiguation4/5
Most tools have distinct purposes, but there is some potential overlap between 'explain_sdk_setup' and 'explain_self_integration' as both provide explanatory guidance, and 'generate_verification_code' and 'generate_eu_id_verification' both generate code examples. However, their specific scopes (general vs. EU ID) and the clear descriptions help differentiate them effectively.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., 'check_self_status', 'fetch_self_docs', 'generate_scope_hash'), but there are minor deviations like 'guide_to_tools' (noun_verb) and 'read_hub_config' (verb_noun_noun). These inconsistencies are slight and do not significantly hinder readability or predictability.
Tool Count5/5
With 15 tools, the count is well-scoped for a server focused on Self protocol integration, documentation, and code generation. Each tool appears to serve a specific, non-redundant purpose within this domain, making the set comprehensive without being overwhelming.
Completeness4/5
The toolset covers key aspects of Self protocol integration, including status checks, documentation access, configuration generation, and code examples. Minor gaps exist, such as the lack of tools for direct write operations (e.g., deploying contracts or updating configurations), but the 'guide_to_tools' tool helps redirect users appropriately, mitigating this issue.
Average 3.4/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 indicate readOnlyHint=true, suggesting a safe read operation, but the description's use of 'generate' could imply creation or mutation. However, it does not explicitly contradict annotations, as 'generate' might align with read-only data generation. The description adds no behavioral context beyond annotations—no details on rate limits, authentication needs, or output behavior—resulting in minimal added value.
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, efficient sentence with no wasted words, making it appropriately concise. It is front-loaded with the core action, though it lacks depth. While under-specified, its brevity is not a flaw in structure, earning a high score for conciseness.
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 tool's complexity (with nested objects and an output schema), the description is incomplete. It does not explain what a 'verification configuration' is, how it relates to siblings, or what the output entails. Although an output schema exists, the description fails to provide necessary context for effective use, leaving significant gaps in understanding.
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 and one parameter ('requirements'), the description does not compensate for the lack of schema details. It mentions 'based on requirements' but provides no insight into what these requirements entail, their structure, or examples. This leaves the parameter meaning unclear, failing to add meaningful semantics beyond the bare schema.
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 'Generate a complete verification configuration based on requirements' restates the title almost verbatim, making it tautological. It specifies the verb 'generate' and resource 'verification configuration' but lacks specificity about what this configuration entails or how it differs from sibling tools like 'generate_eu_id_verification' or 'generate_config_id'. This minimal differentiation results in a vague purpose.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, and fails to differentiate from siblings such as 'generate_eu_id_verification' or 'generate_config_id'. Without any implied or explicit usage instructions, it leaves the agent guessing about appropriate scenarios.
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 provide readOnlyHint=true, indicating this is a read-only operation. The description adds context by specifying 'for write operations', which suggests it guides users toward write-related features without performing writes itself. This aligns with annotations and adds useful behavioral context, though it doesn't detail rate limits, authentication needs, or output format beyond what annotations cover.
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, efficient sentence that front-loads the core purpose without unnecessary elaboration. It avoids redundancy and waste, making it appropriately concise for its function. However, it could be slightly more structured by explicitly separating guidance from context.
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 complexity is low, annotations cover read-only behavior, schema coverage is complete, and an output schema exists, the description is reasonably complete. It adds value by specifying the write-operation focus, though it could enhance completeness by mentioning output expectations or sibling tool relationships.
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%, with clear documentation for the 'action' enum and 'parameters' object. The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the enum values or parameter usage. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
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 states the tool 'guides users to appropriate tools.self.xyz features for write operations', which provides a general purpose but lacks specificity about what 'guide' entails. It mentions 'write operations' but doesn't specify the exact resource or distinguish it from sibling tools like 'explain_sdk_setup' or 'fetch_self_docs' that might also provide guidance. The purpose is vague rather than clearly defined.
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 includes 'for write operations', which implies usage context but doesn't explicitly state when to use this tool versus alternatives. There's no guidance on prerequisites, exclusions, or comparisons to sibling tools like 'generate_config_id' or 'generate_verification_code' that might handle specific write operations. Usage is implied but not clearly defined.
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 provide readOnlyHint=true, indicating this is a safe read operation. The description adds value by specifying it returns 'Detailed explanation of the problem and how to fix it,' which goes beyond annotations by describing output behavior. However, it doesn't disclose other traits like rate limits, auth needs, or error handling, relying on annotations for safety.
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 well-structured with clear sections: purpose statement, Args, and Returns. It's front-loaded with the core purpose. However, the 'Args:' and 'Returns:' labels are slightly redundant with the schema, and the context parameter explanation could be more concise, but overall it's efficient with minimal waste.
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 complexity (diagnostic with 2 parameters), annotations cover safety, and an output schema exists (implied by 'Returns:'), the description is reasonably complete. It explains the purpose, parameters, and return value. However, it lacks usage guidelines and deeper parameter semantics, which could improve completeness for a debugging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It lists parameters in 'Args:' with brief explanations: 'error_message: The error message you're encountering' and 'context: Optional hint about the error type.' This adds basic meaning beyond the schema's titles and enum, but doesn't detail format, examples, or how context enum values relate to error types, leaving gaps.
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's purpose: 'Diagnose Self verification errors and provide solutions.' It specifies the verb ('diagnose') and resource ('Self verification errors'), but doesn't explicitly differentiate from sibling tools like 'explain_sdk_setup' or 'explain_self_integration' which might also address verification issues. The title reinforces this purpose but doesn't add differentiation.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'check_self_status' (which might check status without debugging) or 'explain_sdk_setup' (which might explain setup rather than errors). There's no context about prerequisites, error types, or exclusions, leaving usage unclear.
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 provide readOnlyHint=true, indicating this is a safe read operation. The description adds value by specifying that it returns 'Detailed explanation with code examples,' which clarifies the output format beyond annotations. However, it doesn't disclose other behavioral traits like potential rate limits, authentication needs, or logging details, so it's adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by structured 'Args' and 'Returns' sections. Each sentence serves a clear purpose without redundancy. It could be slightly more concise by integrating the 'Args' and 'Returns' into a single paragraph, but overall it's efficient and well-organized.
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 complexity is low (one parameter, read-only operation) and an output schema exists, the description is reasonably complete. It covers the purpose, parameters, and return value, though it lacks usage context and deeper parameter explanations. With annotations and output schema handling safety and structure, the description adds sufficient value for an explanatory tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing the 'topic' parameter and its enum values in the 'Args' section, adding meaning beyond the bare schema. However, it doesn't explain what each topic entails (e.g., differences between 'config-storage' and 'full-setup'), leaving some semantics unclear. With one parameter and partial documentation, it meets the baseline for minimal viability.
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's purpose: 'Explain Self SDK backend setup requirements and configuration.' It specifies the verb 'explain' and the resource 'Self SDK backend setup requirements and configuration,' making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'explain_self_integration' or 'fetch_self_docs,' which might cover overlapping topics, so it doesn't reach the highest 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 provides no guidance on when to use this tool versus alternatives. It lists possible 'topic' values but doesn't explain scenarios for choosing this over sibling tools such as 'explain_self_integration' or 'fetch_self_docs.' There's no mention of prerequisites, exclusions, or context for usage, leaving the agent without clear direction.
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 provide readOnlyHint=true, indicating this is a safe read operation. The description adds minimal behavioral context beyond that—it mentions replication of a smart contract function, which hints at blockchain/verification context but doesn't detail side effects, rate limits, or authentication needs. Since annotations cover the safety aspect, the description meets a baseline but lacks rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose in the first sentence and additional context in the second. Both sentences are relevant, with no wasted words. However, it could be slightly more structured by explicitly linking to sibling tools or use cases.
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 complexity (4 parameters, 0 required), 100% schema coverage, annotations (readOnlyHint), and the presence of an output schema (implied by context signals), the description is reasonably complete. It states the purpose and implementation context, though it lacks usage guidelines. The output schema means the description doesn't need to explain return values, keeping it adequate for the context.
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%, with all parameters well-documented in the input schema (e.g., 'minimum_age' as 'Minimum age requirement (0 to disable)'). The description adds no parameter-specific information beyond what the schema provides. According to scoring rules, with high schema coverage, the baseline is 3 even without param details in the description.
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's purpose: 'Generate a configuration ID for Self protocol verification.' It specifies the verb ('Generate') and resource ('configuration ID'), and the second sentence adds implementation context ('replicates the generateConfigId function from the smart contract'). However, it doesn't explicitly differentiate this tool from sibling tools like 'generate_verification_config' or 'generate_scope_hash', which appear related to verification/config generation.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'generate_verification_config' or 'check_self_status', nor does it specify prerequisites, use cases, or exclusions. The agent must infer usage from the tool name and parameters alone.
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 declare readOnlyHint=true, indicating this is a safe read operation. The description adds that this generates 'complete code examples' and mentions 'FastMCP context for logging' (though 'ctx' parameter isn't in the schema), providing some behavioral context. However, it doesn't disclose important traits like whether generated code is production-ready, includes dependencies, or has security considerations.
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 reasonably concise with clear sections (purpose, args, returns). However, the 'Args' section includes a parameter ('ctx') not in the schema, wasting space. The first sentence could be more front-loaded with key information. The structure is functional but could be more efficient.
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 has annotations (readOnlyHint), output schema exists (implied by 'Returns' statement), and parameters are mostly enumerated, the description provides adequate context. It explains what the tool generates and the basic parameter meanings. However, with 0% schema description coverage and no output schema details provided, it doesn't fully compensate for the schema gaps, particularly around the 'ctx' parameter discrepancy.
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 carries full burden for parameter documentation. It lists 'component', 'language', and 'ctx' parameters with some semantic explanation (e.g., 'Which part to generate', 'Programming language'). However, it doesn't fully explain the meaning of 'frontend' vs 'backend' vs 'smart-contract' components or why 'solidity' is only for 'smart-contract'. The 'ctx' parameter is mentioned but not in the schema, creating confusion.
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's purpose: 'Generate code for EU ID card verification' with specific resource (EU ID card verification code) and verb (generate). It distinguishes from siblings like 'generate_verification_code' by specifying 'EU ID card' scope and 'V2 feature' context. However, it doesn't explicitly differentiate from 'generate_verification_config' which might be related.
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 guidance on when to use this tool versus alternatives. With siblings like 'generate_verification_code' and 'generate_verification_config', there's no indication of when this specific EU ID card verification code generator is appropriate versus other verification tools. The 'V2 feature' mention provides some context but no explicit usage boundaries.
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 provide readOnlyHint=true, indicating a safe read operation. The description adds that it searches 'across all documentation files' and returns 'relevant information,' which gives some context about scope and output. However, it doesn't detail behavioral aspects like search algorithm, ranking, or performance characteristics that aren't covered 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences that directly state the tool's function. It's front-loaded with the core purpose and avoids unnecessary details. However, the second sentence slightly repeats the first without adding significant new information, preventing a perfect score.
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 (search function), 100% schema coverage, readOnlyHint annotation, and presence of an output schema, the description is reasonably complete. It covers the basic purpose and scope. A higher score would require addressing usage guidelines or more behavioral context, but it's adequate for this context.
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%, with clear descriptions for both parameters ('query' and 'max_results'). The description mentions 'specific terms' and 'relevant information,' which loosely relates to the query parameter, but adds minimal semantic value beyond what the schema already provides. Baseline 3 is appropriate given high schema coverage.
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's purpose as 'search through Self protocol documentation for specific terms' and specifies it searches 'across all documentation files.' This provides a specific verb ('search') and resource ('Self protocol documentation'), but doesn't explicitly differentiate from sibling tools like 'fetch_self_docs' or 'list_docs_topics' beyond the search functionality.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'fetch_self_docs' (which might retrieve specific documents) or 'list_docs_topics' (which might list topics without searching), nor does it specify prerequisites or exclusions for using this search tool.
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 provide readOnlyHint=true, indicating a safe read operation. The description adds context about what's checked ('deployment status and contract addresses'), which is useful beyond the annotation. However, it doesn't disclose behavioral traits like rate limits, authentication needs, or what specific status information is returned. With annotations covering safety, this earns a baseline score for adding some value.
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 purpose. Every word earns its place with no redundancy or fluff. It matches the title closely but avoids tautology by being slightly more specific.
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 one parameter with full schema documentation, annotations covering safety, and an output schema (implied by context signals), the description is reasonably complete. It states the purpose clearly but lacks usage guidelines. For a simple read operation with good structured support, this is adequate though not comprehensive.
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%, but the description doesn't mention the 'network' parameter at all. The schema fully documents the parameter with enum values and a default, so the baseline is 3. The description adds no parameter semantics beyond what the schema provides, failing to compensate for the coverage gap.
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's purpose: 'Check Self protocol deployment status and contract addresses' - a specific verb ('Check') and resource ('Self protocol deployment status and contract addresses'). It distinguishes from most siblings (e.g., fetch_self_docs, explain_sdk_setup) by focusing on network/contract status rather than documentation or explanations. However, it doesn't explicitly differentiate from tools like read_hub_config which might overlap in checking configuration status.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare to siblings like read_hub_config or debug_verification_error. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection in this sibling-rich context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating this is a safe read operation. The description adds value by specifying it returns 'complete, working code example with comments', which gives behavioral context about output format and quality. However, it doesn't disclose other traits like rate limits, authentication needs, or whether the code is customizable versus static templates.
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 appropriately sized with three sentences: purpose statement, parameter explanation, and return value description. It's front-loaded with the core function and uses bullet-like formatting for parameters. Every sentence adds value, though the 'Args:' and 'Returns:' labels could be integrated more smoothly into prose.
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 has an output schema (implied by 'Returns:' statement), the description doesn't need to detail return values. It covers the essential purpose and parameters adequately for a code-generation tool with read-only annotations. However, it lacks integration context hints mentioned in the title ('after understanding the integration'), which could help agents use it appropriately.
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?
With 0% schema description coverage, the description carries full burden for parameter semantics. It effectively explains both parameters: 'component' defines which part to generate (frontend-qr, backend-verify, smart-contract) and 'language' specifies programming language (typescript, javascript, solidity). This adds clear meaning beyond the bare enum values in the schema, though it doesn't detail what each component entails.
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 generates 'ready-to-use Self verification code for different components' with specific verbs ('generate', 'verify') and resources ('code', 'components'). It distinguishes from siblings like 'explain_sdk_setup' or 'generate_verification_config' by focusing on code generation rather than explanation or configuration. However, it doesn't explicitly differentiate from 'generate_eu_id_verification' which might be similar in purpose.
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 guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'generate_verification_code' over sibling tools like 'explain_sdk_setup' for learning or 'generate_verification_config' for configuration. There's no context about prerequisites, integration understanding requirements, or typical use cases beyond the basic function.
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 include readOnlyHint: true, indicating this is a safe read operation. The description adds value by specifying that it provides 'step-by-step guidance' and 'detailed explanation with steps and code examples,' which goes beyond the annotations to describe the tool's output behavior. However, it doesn't disclose additional traits like rate limits, authentication needs, or potential side effects, so it's adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the main purpose in the first sentence. The additional details about args and returns are structured clearly, but the inclusion of 'Args:' and 'Returns:' sections, while helpful, adds some redundancy since the input and output schemas already cover this information, slightly reducing efficiency.
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 complexity (a single parameter with enums and an output schema), the description is reasonably complete. It explains the purpose, lists parameter options, and describes the output format. With annotations covering safety and an output schema likely detailing the return structure, the description provides sufficient context for an agent to understand and use the tool effectively, though it could benefit from more sibling differentiation.
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%, meaning the schema doesn't describe the parameter. The description compensates by listing the three possible values for 'use_case' ('airdrop', 'age-verification', 'humanity-check') and labeling it as 'The integration scenario,' which adds meaning beyond the bare schema. However, it doesn't elaborate on what each use case entails or provide examples, so it partially fills the gap but not fully.
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's purpose: 'Explain how to integrate Self for a specific use case with step-by-step guidance.' This specifies the verb ('explain') and resource ('Self protocol integration'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'explain_sdk_setup' or 'fetch_self_docs', which likely cover related aspects of Self integration, so it doesn't reach the highest score.
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 by mentioning 'for a specific use case' and listing the three possible use cases, suggesting it should be used when guidance on integrating Self for those scenarios is needed. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'explain_sdk_setup' or 'guide_to_tools', nor does it mention any exclusions or prerequisites, leaving usage somewhat inferred rather than clearly defined.
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 readOnlyHint=true, so the agent knows this is a safe read operation. The description adds 'with full decoding', which provides useful context about the output format, but does not disclose other behavioral traits like rate limits, authentication needs, or error handling. No contradiction with annotations exists.
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 is front-loaded with the core purpose ('Read configuration from Self protocol Hub contract') and adds a clarifying detail ('with full decoding'). There is no wasted wording, making it highly concise and well-structured.
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 that annotations cover safety (readOnlyHint), schema coverage is high, and an output schema exists, the description is reasonably complete. It adds value with 'full decoding' but could improve by mentioning when to use this tool over siblings or clarifying parameter nuances. For a read operation with good structured data, it's mostly adequate.
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 schema fully documents both parameters (config_id and network). The description does not add any meaning beyond what the schema provides, such as explaining the format of config_id beyond '0x...' or the implications of network choice. Baseline 3 is appropriate given 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 specific action ('Read configuration') and resource ('from Self protocol Hub contract'), with the additional detail 'with full decoding' that distinguishes it from simple data retrieval. It precisely communicates what the tool does without being tautological.
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 guidance on when to use this tool versus alternatives. While sibling tools exist (e.g., 'generate_config_id', 'generate_verification_config'), there is no mention of them or any context for choosing this tool over others, leaving usage decisions unclear.
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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds minimal behavioral context beyond that—it mentions the tool lists topics 'and their descriptions' and references fetch_self_docs, but doesn't disclose details like response format, pagination, or rate limits. With annotations covering the safety profile, a 3 is appropriate as the description adds some value but not rich behavioral context.
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 core purpose and followed by a brief usage note. Every sentence earns its place by clarifying the tool's function and its relationship to another tool, with zero wasted words.
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 low complexity (0 parameters, read-only operation), annotations covering safety, and the presence of an output schema (which handles return values), the description is reasonably complete. It explains what the tool does and hints at its usage context, though it could be more explicit about differentiation from siblings like 'search_docs'.
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 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters. A baseline of 4 is given for tools with no parameters, as the description correctly avoids unnecessary parameter details.
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's purpose: 'List all available documentation topics and their descriptions.' It specifies the verb ('List') and resource ('documentation topics'), though it doesn't explicitly differentiate from sibling tools like 'search_docs' or 'fetch_self_docs' beyond mentioning the latter in a second sentence.
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 implied usage guidance by stating 'This tool shows you all the documentation topics you can fetch with the fetch_self_docs tool.' This suggests a relationship between listing topics and fetching them, but it doesn't explicitly state when to use this tool versus alternatives like 'search_docs' or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about the return format ('ISO 3166-1 alpha-3 country codes with their names'), which isn't covered by annotations. However, it doesn't mention pagination, rate limits, or authentication requirements beyond what annotations imply.
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 with zero waste. First sentence states purpose and context, second sentence specifies return format. Every word earns its place, and the most important information (what the tool does) is front-loaded.
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 this is a simple read operation with readOnlyHint annotation, 100% schema coverage, and an output schema (implied by context signals), the description provides exactly what's needed. It explains what the tool returns without needing to detail parameters or safety concerns that are already covered elsewhere.
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 schema already fully documents the single optional 'search' parameter. The description doesn't add any parameter-specific information beyond what's in the schema. With high schema coverage, the baseline score of 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 clearly states the verb ('List') and resource ('available country codes'), specifies the context ('for exclusion in Self protocol'), and distinguishes from siblings by focusing on country codes rather than documentation, configuration, or verification tools. It provides specific format information ('ISO 3166-1 alpha-3 country codes with their names').
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 ('for exclusion in Self protocol') but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, timing, or specific scenarios where this tool is preferred over other country-related operations (though none exist in 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?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds useful context beyond this by specifying the source ('GitHub') and the freshness guarantee ('latest'), but does not disclose other behavioral traits like rate limits, authentication needs, or response format details. No contradiction with annotations exists.
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 front-loaded with the core purpose in the first sentence, followed by supporting details in a structured list of topics. Every sentence earns its place by enhancing clarity without redundancy, and the bulleted list efficiently organizes information without unnecessary verbosity.
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 low complexity (read-only, two parameters), high schema coverage (100%), and the presence of an output schema (implied by context signals), the description is complete enough. It covers purpose, source, freshness, and available topics, addressing all necessary context without needing to explain return values or redundant schema details.
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 schema fully documents the 'topic' and 'section' parameters. The description adds value by listing available topics (e.g., 'quickstart', 'backend-sdk'), which clarifies the 'topic' parameter's semantics beyond the schema's enum-like list, but does not provide additional details on 'section' or parameter interactions.
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 specific action ('fetch', 'retrieves') and resource ('Self protocol documentation from GitHub'), distinguishing it from siblings like 'search_docs' (which likely searches within docs) or 'list_docs_topics' (which likely lists topics). It explicitly mentions 'latest' to highlight freshness, setting it apart from static documentation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining up-to-date documentation, but does not explicitly state when to use this tool versus alternatives like 'search_docs' or 'list_docs_topics'. It provides clear context (e.g., 'ensuring you always have the latest information') but lacks explicit exclusions or named alternatives.
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 provide readOnlyHint=true, and the description doesn't contradict this. It adds valuable context about the tool's purpose (replicating hashEndpointWithScope) and output format (dictionary with scope_hash, validation status, input type), which goes beyond the annotations' safety declaration.
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 efficiently structured with a clear purpose statement, parameter details in a formatted Args section, and return value explanation. Every sentence serves a distinct purpose without redundancy.
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, 100% schema coverage, annotations covering safety, and an output schema (implied by 'Returns'), the description provides complete context. It explains what the tool does, its inputs, and output structure adequately.
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 schema already fully documents both parameters. The description repeats the parameter information but doesn't add meaningful semantic context beyond what's in the schema, such as examples or edge cases.
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 specific action ('Generate a scope hash') and purpose ('for Self verification'), with explicit reference to replicating 'hashEndpointWithScope'. It distinguishes from siblings by focusing on hash generation rather than status checking, debugging, or documentation tasks.
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 for Self verification contexts but doesn't explicitly state when to use this tool versus alternatives like 'generate_verification_code' or 'generate_verification_config'. No exclusions or specific prerequisites are mentioned, leaving usage context somewhat open-ended.
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:

[![self-mcp MCP server](https://glama.ai/mcp/servers/selfxyz/self-mcp/badges/card.svg)](https://glama.ai/mcp/servers/selfxyz/self-mcp)

Score Badge

Copy to your README.md:

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

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