DeSo MCP Server

Official

by deso-protocol

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some overlap in purpose, particularly between deso_api_explorer, deso_js_guide, and generate_deso_code, which all involve code/API guidance, but their descriptions help differentiate them. However, tools like deso_debugging_guide and deso_implementation_patterns could be confused as they both address integration issues and best practices, creating ambiguity in selection.
Naming Consistency4/5
Most tools follow a consistent snake_case pattern with a 'deso_' prefix, such as deso_api_explorer and deso_js_guide, which aids readability. However, there are minor deviations like read_repository_document and repository_search, which use a different naming style without the prefix, slightly breaking the pattern but not severely impacting usability.
Tool Count5/5
With 8 tools, the count is well-scoped for a server focused on DeSo integration, documentation, and code generation. Each tool appears to serve a distinct educational or operational purpose, avoiding bloat while covering key aspects like API exploration, debugging, and repository access, making the set manageable and purposeful.
Completeness3/5
The tool set covers documentation, guidance, and repository operations well, but there are notable gaps in direct DeSo API interactions, such as creating or updating blockchain transactions or user data. While tools like generate_deso_code and deso_js_guide provide code examples, they lack actual execution capabilities, which limits the server's operational completeness for real-time integration tasks.
Average 2.9/5 across 8 of 8 tools scored.
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 passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'backend implementation details' and 'deso-js SDK integration' which suggests it might provide implementation insights, but doesn't clarify what 'explorer' actually does - is it read-only documentation browsing, interactive testing, or something else? It doesn't address permissions, rate limits, side effects, or response format, which are critical for a tool with 'API' in its name.
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 packs multiple concepts. It's appropriately sized for a tool with three parameters and establishes the core purpose upfront. However, it could be more front-loaded by starting with the primary action ('Explore DeSo APIs') before mentioning implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an API exploration tool with three parameters and no output schema, the description is insufficient. It doesn't explain what the tool returns (documentation, interactive interface, code snippets?), how results are structured, or what 'comprehensive' means in practice. With no annotations and siblings that might overlap, more context about the exploration mechanism and output format is needed for the agent to use this effectively.
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 documents all three parameters thoroughly with descriptions and an enum for 'category'. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples of endpoint names, or clarify what 'includeCode' examples might look like. Baseline 3 is appropriate when schema does the heavy lifting.
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 this is a 'Comprehensive DeSo API explorer' which indicates it explores APIs, but it's vague about what 'explore' means - does it list endpoints, test them, or provide documentation? It mentions 'backend implementation details and deso-js SDK integration' which adds some specificity but doesn't clearly distinguish it from siblings like 'deso_js_guide' or 'explain_deso_architecture'. The verb 'explore' is imprecise compared to more specific alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the seven sibling tools. The description doesn't mention alternatives, prerequisites, or typical use cases. With siblings like 'deso_js_guide', 'explain_deso_architecture', and 'generate_deso_code' that might overlap in API-related functionality, the absence of differentiation leaves the agent guessing about appropriate selection contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'best practices and implementation patterns learned from deso-chat and real debugging', which hints at educational or informational output but doesn't specify whether this tool retrieves, explains, or generates content, nor does it describe any constraints like rate limits, permissions, or output format. This leaves significant gaps in understanding how the tool behaves.
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 directly states the tool's purpose without unnecessary words. It is front-loaded with the core idea, making it easy to parse. However, it could be slightly more structured by explicitly mentioning the tool's action (e.g., 'Retrieve best practices...'), but overall, it earns its place without waste.
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 has no annotations and no output schema, the description is incomplete for understanding its full context. It lacks details on what the tool returns (e.g., text explanations, code examples, links), how it handles parameters like 'all', and how it differs from siblings. For a tool with two parameters and educational intent, more completeness is needed to guide effective use.
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 has 100% description coverage with clear enums for both parameters, so the schema does the heavy lifting. The description adds no additional meaning beyond what the schema provides, such as explaining how 'framework' and 'pattern' interact or what 'all' means for the pattern parameter. With high schema coverage, the baseline score is 3, as the description doesn't compensate but also doesn't detract.
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 provides 'best practices and implementation patterns learned from deso-chat and real debugging', which gives a general purpose but lacks specificity. It doesn't clearly distinguish this tool from siblings like 'deso_debugging_guide' or 'deso_js_guide', making the differentiation vague. The description is better than a tautology but doesn't specify what action the tool performs (e.g., retrieves, explains, or generates patterns).
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 any context, prerequisites, or exclusions, and fails to differentiate from sibling tools like 'deso_debugging_guide' or 'generate_deso_code'. Without explicit or implied usage instructions, users must infer when this tool is appropriate based on the vague purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'solutions' but doesn't specify what the tool actually does behaviorally—e.g., whether it returns step-by-step instructions, references documentation, or provides interactive debugging. This leaves significant gaps in understanding how the tool operates.
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 key information ('Comprehensive debugging guide') without any wasted words. It's appropriately sized for the tool's purpose and structured to convey the essence immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of debugging tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., text guide, structured data, links) or how it handles different issues, leaving the agent with insufficient context to use it effectively beyond basic parameter input.
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 documents both parameters ('issue' and 'includeCode') with descriptions and enums. The description doesn't add any meaningful semantic context beyond what the schema provides, such as explaining the relationship between parameters or typical use cases, resulting in a baseline score of 3.
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 a 'debugging guide for common DeSo integration issues with solutions', which specifies the verb ('debugging guide') and resource ('DeSo integration issues'). However, it doesn't explicitly differentiate from sibling tools like 'deso_js_guide' or 'explain_deso_architecture' which might also address debugging or integration topics, keeping it from a perfect 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 doesn't mention sibling tools or contexts where other tools might be more appropriate, such as using 'deso_api_explorer' for API exploration or 'generate_deso_code' for code generation instead of debugging guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a 'guide' which implies informational/read-only behavior, but doesn't disclose whether it generates code, provides step-by-step instructions, or returns documentation. No mention of rate limits, authentication needs, or output format. Significant behavioral gaps remain.
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 main purpose ('complete guide to using the deso-js SDK'). It could be slightly more structured by separating key components, but it wastes no words and clearly communicates scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a guidance tool with 2 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what kind of guidance is provided (e.g., code snippets, explanations, tutorials), how results are formatted, or what depth of information to expect. Users cannot predict the tool's behavior from this description alone.
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 documents both parameters thoroughly with enums and descriptions. The description mentions 'setup, authentication, and transactions' which aligns with some enum values in the 'topic' parameter, but adds no additional semantic context beyond what the schema provides. Baseline 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 clearly states the tool provides a 'complete guide to using the deso-js SDK' covering specific areas like setup, authentication, and transactions. It distinguishes from siblings by focusing on SDK usage guidance rather than API exploration, debugging, or code generation. However, it doesn't explicitly differentiate from 'deso_implementation_patterns' which might overlap.
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 like 'deso_api_explorer' or 'deso_debugging_guide'. It mentions the scope (setup, authentication, transactions) but doesn't specify use cases, prerequisites, or exclusions. Users must infer usage from the title alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool explains topics but doesn't describe how it behaves—e.g., whether it generates text, returns structured data, has rate limits, or requires specific permissions. For a tool with no annotations, 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 extremely concise and front-loaded, using a single phrase that directly states the tool's purpose without any wasted words. Every part of the description earns its place by clearly communicating the core function.
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 complexity of explaining architecture and integration patterns, the description is incomplete. It lacks details on output format (no output schema provided), behavioral traits, or usage context. Without annotations or output schema, the agent has insufficient information to understand what the tool returns or how it operates.
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 has 100% description coverage, with clear documentation for both parameters ('includeCode' and 'topic'). The description adds no additional meaning beyond the schema, such as examples of valid topics or how code examples are formatted. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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: to explain DeSo architecture, flows, and integration patterns. It uses specific verbs ('explain') and resources ('DeSo architecture'), but it doesn't explicitly distinguish itself from sibling tools like 'deso_implementation_patterns' or 'deso_js_guide', which might cover overlapping topics. This makes it clear but not fully differentiated from alternatives.
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 'deso_implementation_patterns' or 'generate_deso_code', nor does it specify contexts or prerequisites for usage. This lack of comparative or contextual advice leaves the agent with minimal 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?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't describe what type of search is performed (full-text, metadata, etc.), whether results are paginated, what format documents are returned in, or any authentication requirements. The description merely states the basic function without operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, front-loading the core functionality with zero wasted language. Every word earns its place by communicating the essential purpose without unnecessary elaboration.
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 purpose (searching a repository), the absence of annotations, and no output schema, the description is insufficiently complete. It doesn't explain what constitutes a 'document' in this context, what search capabilities exist, or what results look like. For a search tool with no structured behavioral information, more context is needed about the search behavior and results format.
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 with the single 'query' parameter documented as 'Search query'. The description adds no additional parameter semantics beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info 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 action ('Search for documents') and target resource ('in the DeSo repository'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'read_repository_document', which suggests potential overlap in functionality without explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 a sibling tool named 'read_repository_document' that likely serves a related purpose, there's no indication of when search is appropriate versus direct document reading, nor any mention of prerequisites or constraints for using this search functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive code examples' but doesn't specify what that entails (e.g., output format, length, whether examples are tested or just snippets). It also doesn't cover potential limitations like rate limits, authentication requirements beyond the 'includeAuth' parameter, or error handling. The description is too vague for a tool with no annotation support.
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 without unnecessary details. Every word earns its place, making it easy for an agent to parse quickly. No fluff or redundancy is present.
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 4 parameters with full schema coverage but no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks depth on behavioral aspects and usage context. For a code-generation tool, more detail on output expectations would be helpful, but the schema covers inputs well.
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 documents all parameters thoroughly. The description doesn't add any meaning beyond what's in the schema—it doesn't explain relationships between parameters (e.g., how 'fullExample' interacts with 'includeAuth') or provide usage examples. Baseline 3 is appropriate since the schema does the heavy lifting.
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 comprehensive code examples for DeSo operations using deso-js SDK'. It specifies the verb ('generate'), resource ('code examples'), and technology context ('deso-js SDK'). However, it doesn't explicitly differentiate from sibling tools like 'deso_js_guide' or 'deso_implementation_patterns', which might also involve code examples.
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 or other contexts where code generation might be needed, nor does it specify prerequisites or exclusions. The agent must infer usage based solely on the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool reads a document, implying a read-only operation, but doesn't specify what 'read' entails (e.g., returns raw content, metadata, or formatted output), whether there are authentication requirements, rate limits, error handling, or performance characteristics. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. There's no redundancy or fluff, earning its place as a model of conciseness.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format. Without annotations or an output schema, the description should do more to explain what the tool returns and how it behaves, but it meets a bare minimum for a read operation.
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 coverage is 100%, with clear descriptions for both parameters ('path' and 'repository'), including an example for 'path' and an enum for 'repository'. The description adds no additional parameter semantics beyond what the schema provides, such as explaining path conventions or repository purposes. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 action ('Read') and resource ('a specific document from the DeSo repository'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'repository_search' or 'deso_api_explorer', which might also involve document access. The description is specific but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 this tool is appropriate (e.g., for retrieving known documents by path) versus when to use 'repository_search' (for finding documents by content) or other siblings. There's no context about prerequisites, exclusions, or comparative use cases.
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:

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

Score Badge

Copy to your README.md:

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

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