Skip to main content
Glama
deso-protocol

DeSo MCP Server

Official
by deso-protocol
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

DeSo MCP Server v3.0 (HTTP)

A comprehensive Model Context Protocol (MCP) server for DeSo blockchain development, now with HTTP transport support.

Features

🛠️ 10 Comprehensive Tools:

  • deso_api_explorer - Complete DeSo API documentation and examples

  • deso_js_guide - deso-js SDK setup and usage guides

  • generate_deso_code - Generate code examples for DeSo operations

  • explain_deso_architecture - Architectural explanations and patterns

  • repository_search - Search DeSo repository documentation

  • read_repository_document - Read specific DeSo docs

  • deso_debugging_guide - Real debugging fixes for common issues

  • deso_implementation_patterns - Best practices from production apps

  • deso_ui_components - Complete UI component library guide

  • deso_graphql_helper - GraphQL query builder and examples

🚀 HTTP Transport:

  • RESTful HTTP API instead of stdio

  • CORS support for web integration

  • Health check endpoint

  • Easy deployment and scaling

Related MCP server: AMOCA Solana MCP Server

Quick Start

Local Development

# Install dependencies
npm install

# Start the server
npm start

# Development with auto-reload
npm run dev

The server will run on http://localhost:3000 by default.

Environment Variables

PORT=3000          # Server port (default: 3000)
HOST=localhost     # Server host (default: localhost)

Docker Deployment

# Build the image
npm run docker:build

# Run the container
npm run docker:run

# Or manually:
docker build -t deso-mcp-server .
docker run -p 3000:3000 -e HOST=0.0.0.0 deso-mcp-server

HTTP Endpoints

Health Check

curl http://localhost:3000/

MCP Tool Requests

Send JSON-RPC requests to the root endpoint.

Important:

  • MCP requires initialization first, then you can call tools

  • Always include the Accept: application/json, text/event-stream header

  • The server runs in stateless mode (no session management required)

# 1. Initialize the MCP session
curl -X POST http://localhost:3000/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "initialize",
    "params": {
      "capabilities": {},
      "protocolVersion": "2024-11-05",
      "clientInfo": {"name": "my-client", "version": "1.0.0"}
    }
  }'

# 2. List available tools
curl -X POST http://localhost:3000/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/list"
  }'

# 3. Call a specific tool
curl -X POST http://localhost:3000/ \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0", 
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "deso_api_explorer",
      "arguments": {
        "category": "social",
        "includeCode": true
      }
    }
  }'

Example Usage

JavaScript Client Example

class DesoMCPClient {
  constructor(baseUrl = 'http://localhost:3000') {
    this.baseUrl = baseUrl;
    this.initialized = false;
  }

  async request(method, params = {}) {
    const response = await fetch(this.baseUrl, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Accept': 'application/json, text/event-stream'
      },
      body: JSON.stringify({
        jsonrpc: '2.0',
        id: Date.now(),
        method,
        params
      })
    });

    const data = await response.json();
    if (data.error) throw new Error(data.error.message);
    return data.result;
  }

  async initialize() {
    await this.request('initialize', {
      capabilities: {},
      protocolVersion: '2024-11-05',
      clientInfo: { name: 'deso-client', version: '1.0.0' }
    });
    this.initialized = true;
  }

  async callTool(name, args) {
    if (!this.initialized) await this.initialize();
    return this.request('tools/call', { name, arguments: args });
  }
}

// Usage examples:
const client = new DesoMCPClient();

// Get DeSo API Information
const apiInfo = await client.callTool('deso_api_explorer', {
  category: 'social',
  endpoint: 'submit-post',
  includeCode: true
});

// Debug DeSo Integration Issues const debugInfo = await client.callTool('deso_debugging_guide', { issue: 'message-decryption', includeCode: true });

// Generate GraphQL Queries const query = await client.callTool('deso_graphql_helper', { action: 'build', question: 'How many followers does nader have?', username: 'nader' });


## Integration with MCP Clients

### Claude Desktop Configuration

Add to your Claude Desktop configuration:

```json
{
  "mcpServers": {
    "deso": {
      "command": "npx",
      "args": ["deso-mcp-server"],
      "transport": "http",
      "url": "http://localhost:3000"
    }
  }
}

VS Code Integration

Use with MCP-compatible VS Code extensions by configuring the HTTP endpoint:

{
  "mcp.servers": [
    {
      "name": "deso",
      "transport": "http",
      "url": "http://localhost:3000"
    }
  ]
}

Architecture

The server uses:

  • HTTP Transport: RESTful API with JSON-RPC over HTTP

  • CORS Support: Cross-origin requests enabled

  • Graceful Shutdown: Proper cleanup on SIGINT/SIGTERM

  • Error Handling: Comprehensive error responses

  • Health Checks: Built-in monitoring endpoint

Development

Project Structure

deso-mcp/
├── deso-mcp.js          # Main MCP server
├── package.json         # Dependencies and scripts  
├── Dockerfile          # Container configuration
└── README.md           # Documentation

Debugging

  • Enable debug logging with DEBUG=mcp:*

  • Check server health at http://localhost:3000/

  • Monitor logs for request/response details

License

MIT License - see LICENSE file for details.

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Test with HTTP requests

  5. Submit a pull request

Support

For issues and questions:

Available Tools

8 tools
deso_api_explorerC

Comprehensive DeSo API explorer with backend implementation details and deso-js SDK integration

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNoAPI category to explore
endpointNoSpecific endpoint name (optional)
includeCodeNoInclude code examples

TDQS

C2.6/5.0
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.

deso_debugging_guideC

Comprehensive debugging guide for common DeSo integration issues with solutions

ParametersJSON Schema
NameRequiredDescriptionDefault
includeCodeNoInclude code examples and fixes
issueYesSpecific issue to debug or 'all' for complete guide

TDQS

C2.9/5.0
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.

deso_implementation_patternsC

Best practices and implementation patterns learned from deso-chat and real debugging

ParametersJSON Schema
NameRequiredDescriptionDefault
frameworkNoFramework context
patternYesImplementation pattern to explore

TDQS

C2.6/5.0
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.

deso_js_guideC

Complete guide to using the deso-js SDK with setup, authentication, and transactions

ParametersJSON Schema
NameRequiredDescriptionDefault
frameworkNoFramework context (optional)
topicYesTopic to get guidance on

TDQS

C2.9/5.0
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.

explain_deso_architectureC

Explain DeSo architecture, flows, and integration patterns

ParametersJSON Schema
NameRequiredDescriptionDefault
includeCodeNoInclude code examples
topicYesArchitecture topic to explain

TDQS

C2.9/5.0
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.

generate_deso_codeB

Generate comprehensive code examples for DeSo operations using deso-js SDK

ParametersJSON Schema
NameRequiredDescriptionDefault
fullExampleNoGenerate complete working example
includeAuthNoInclude authentication setup
languageYesProgramming language/framework
operationYesDeSo operation (e.g., 'follow', 'post', 'buy-creator-coin', 'send-diamonds')

TDQS

B3.1/5.0
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.

read_repository_documentB

Read a specific document from the DeSo repository

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesRelative path to the document (e.g., 'docs/deso-tutorial-build-apps.md')
repositoryNoRepository name

TDQS

B3.1/5.0
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv1.0.0
    • First observeddeso_api_explorer
    • First observeddeso_debugging_guide
    • First observeddeso_implementation_patterns
    • First observeddeso_js_guide
    • First observedexplain_deso_architecture
    • First observedgenerate_deso_code
    • First observedread_repository_document
    • First observedrepository_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.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.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • AMOCA Solana MCP Server

    manolaz
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI models to interact with the Solana blockchain, providing RPC methods, wallet management, DeFi trading capabilities, and Helius API integration for enhanced Solana development.
    5
    MIT

  • Cyberlink MCP Server

    dasein108
    F
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server for creating, updating, and querying semantic relationships (cyberlinks) on Cosmos-based blockchains through integration with Cursor IDE and Claude Desktop.
    1
    -
  • CodeAlive MCP by CodeAlive-AI

    CodeAlive MCPofficial

    CodeAlive-AI
    A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
    89
    MIT

Latest Blog Posts

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