Which integrations are available for this server?

Provides an example UTCP manual for the GitHub REST API, enabling AI agents to interact with repositories and issues through a standardized tool calling protocol. Integrates with OpenAI's API to power an expert agent that answers questions about UTCP, leveraging LLM capabilities for documentation search and code generation. Provides an example UTCP manual for the SendGrid email API, allowing AI agents to send emails with authentication via the SendGrid service.

How do I use UTCP Documentation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UTCP Documentation MCP Server How do I authenticate with bearer tokens?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

UTCP Documentation MCP Server

by edujuan

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

UTCP Documentation MCP Server

A comprehensive MCP server that helps AI coding agents understand and implement the Universal Tool Calling Protocol (UTCP)

TypeScript MCP License: MIT

🚀 Features

🤖 LLM-Powered Expert Agent: Ask questions in natural language to an OpenAI-powered agent with deep UTCP knowledge
📚 Documentation Search: Semantic search across complete UTCP specification
✅ Manual Validation: Validate UTCP manuals against v1.0.1 spec with detailed errors
🎨 Code Generation: Generate UTCP manual templates for HTTP, CLI, MCP, SSE protocols
🔄 OpenAPI Conversion: Convert OpenAPI 3.0 specs to UTCP manuals automatically
📝 Examples Library: Ready-to-use examples for weather APIs, GitHub, databases, CLI tools
💡 Best Practices: Built-in guidance for naming, authentication, and implementation

Related MCP server: Specmatic MCP Server

📦 Installation

NPM

npm install -g utcp-docs

From Source

git clone https://github.com/yourusername/utcp-docs-mcp-server.git
cd utcp-docs-mcp-server
npm install
npm run build
npm link

🔧 Configuration

For Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "utcp-docs": {
      "command": "utcp-docs",
      "env": {
        "DOCS_PATH": "/path/to/utcp-docs",
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

For Cursor IDE

Add to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "utcp-docs": {
      "command": "npx",
      "args": ["utcp-docs"],
      "env": {
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

Environment Variables

Create a .env file or set in your MCP config:

# OpenAI API Key (required for ask_utcp_expert tool)
OPENAI_API_KEY=sk-...

# Documentation path (default: current directory)
DOCS_PATH=.

# Server configuration
SERVER_NAME=utcp-docs
SERVER_VERSION=1.0.0
LOG_LEVEL=info

🛠️ Available Tools

🆕 1. Ask UTCP Expert (LLM Agent)

NEW! Ask an OpenAI-powered agent any question about UTCP:

{
  "tool": "ask_utcp_expert",
  "arguments": {
    "question": "How do I authenticate with bearer tokens?"
  }
}

The agent:

Has deep knowledge of the entire UTCP specification
Retrieves relevant documentation automatically
Provides detailed explanations with code examples
Includes source references
Offers best practices and guidance

Example Questions:

"What is body_template and when should I use it?"
"Show me a complete HTTP tool example with OAuth2"
"How do I chain CLI commands together?"
"Why is my tool name failing validation?"

Requires: OpenAI API key (set OPENAI_API_KEY environment variable)

2. Search UTCP Documentation

Search the complete UTCP specification:

{
  "tool": "search_utcp_docs",
  "arguments": {
    "query": "how to implement HTTP authentication",
    "section": "protocols",  // optional: introduction, protocols, guides, api
    "limit": 5               // optional: max results
  }
}

Example Response:

# Search Results for "HTTP authentication"

## Result 1: HTTP Protocol Authentication
**Section:** protocols
**Relevance:** 45

Authentication in HTTP protocols can be configured using the auth field...

3. Validate UTCP Manual

Validate your UTCP manual against the specification:

{
  "tool": "validate_utcp_manual",
  "arguments": {
    "manual": {
      "manual_version": "1.0.0",
      "utcp_version": "1.0.1",
      "tools": [...]
    }
  }
}

Response:

✅ Valid UTCP Manual
The manual passes all validation checks and conforms to UTCP v1.0.1 specification.

Or with errors:

❌ Invalid UTCP Manual

## Errors
- /tools/0/name: Tool name "GetWeather" must use snake_case
- /tools/0/tool_call_template: HTTP template requires a URL

## Warnings
- /tools/0/description: Tool description should be at least 10 characters

4. Generate UTCP Manual

Generate a UTCP manual template:

{
  "tool": "generate_utcp_manual",
  "arguments": {
    "tool_name": "get_weather",
    "description": "Get current weather for a location",
    "protocol": "http",
    "endpoint": "https://api.openweathermap.org/data/2.5/weather",
    "method": "GET",
    "parameters": {
      "location": {
        "type": "string",
        "description": "City name",
        "required": true
      }
    },
    "include_auth": true
  }
}

Supported Protocols:

http - RESTful HTTP APIs
cli - Command-line tools
mcp - Model Context Protocol servers
sse - Server-Sent Events
streamable_http - Streaming HTTP responses

5. Convert OpenAPI to UTCP

Convert OpenAPI 3.0 specifications to UTCP manuals:

{
  "tool": "convert_openapi_to_utcp",
  "arguments": {
    "openapi_spec": {
      "openapi": "3.0.0",
      "info": { "title": "My API", "version": "1.0.0" },
      "paths": {
        "/users": {
          "get": {
            "operationId": "getUsers",
            "summary": "List users"
          }
        }
      }
    }
  }
}

6. Get UTCP Examples

Get ready-to-use example UTCP manuals:

{
  "tool": "get_utcp_examples",
  "arguments": {
    "use_case": "weather"  // weather, github, database, cli-tool
  }
}

Available Examples:

weather - OpenWeatherMap API integration
github - GitHub REST API (repos, issues)
database - Database query tools via MCP
cli-tool - Git command-line wrapper

7. Get Best Practices

Get UTCP implementation best practices:

{
  "tool": "get_best_practices",
  "arguments": {
    "topic": "naming"  // naming, authentication, error-handling, testing, general
  }
}

📖 Resources

The server provides these resources via MCP:

Resource URI	Description
`utcp://docs/full`	Complete UTCP documentation (9700+ lines)
`utcp://docs/introduction`	UTCP introduction and overview
`utcp://docs/protocols`	All protocol documentation
`utcp://examples/weather`	Weather API example manual
`utcp://examples/github`	GitHub API example manual
`utcp://schema/manual`	UTCP JSON Schema for validation

🧪 Usage Examples

Example 1: Creating a New UTCP Manual

// 1. Generate a template
const result = await callTool("generate_utcp_manual", {
  tool_name: "send_email",
  description: "Send an email via SendGrid API",
  protocol: "http",
  endpoint: "https://api.sendgrid.com/v3/mail/send",
  method: "POST",
  parameters: {
    to: { type: "string", description: "Recipient email", required: true },
    subject: { type: "string", description: "Email subject", required: true },
    body: { type: "string", description: "Email body", required: true }
  },
  include_auth: true
});

// 2. Validate the generated manual
const validation = await callTool("validate_utcp_manual", {
  manual: JSON.parse(result)
});

// 3. Get best practices for authentication
const practices = await callTool("get_best_practices", {
  topic: "authentication"
});

Example 2: Converting Existing OpenAPI Spec

// 1. Read your OpenAPI spec
const openApiSpec = JSON.parse(fs.readFileSync("api-spec.json"));

// 2. Convert to UTCP
const utcpManual = await callTool("convert_openapi_to_utcp", {
  openapi_spec: openApiSpec
});

// 3. Validate the result
const validation = await callTool("validate_utcp_manual", {
  manual: JSON.parse(utcpManual)
});

Example 3: Searching Documentation

// Search for specific implementation details
const results = await callTool("search_utcp_docs", {
  query: "how to handle streaming responses",
  section: "protocols",
  limit: 3
});

// Get an example to reference
const example = await callTool("get_utcp_examples", {
  use_case: "github"
});

🏗️ Development

Setup

# Clone repository
git clone https://github.com/yourusername/utcp-docs-mcp-server.git
cd utcp-docs-mcp-server

# Install dependencies
npm install

# Build
npm run build

# Run in development mode
npm run dev

Testing

# Run all tests
npm test

# Run tests in watch mode
npm run test:watch

# Generate coverage report
npm run test:coverage

Project Structure

utcp-docs/
├── src/
│   ├── index.ts              # Entry point
│   ├── server.ts             # MCP server implementation
│   ├── types/
│   │   └── utcp.ts           # TypeScript types
│   ├── services/
│   │   ├── documentation.ts  # Documentation search
│   │   ├── validator.ts      # UTCP validation
│   │   ├── generator.ts      # Manual generation
│   │   └── converter.ts      # OpenAPI conversion
│   └── schemas/
│       └── utcp-manual.schema.json
├── docs/
│   └── examples/             # Example UTCP manuals
├── tests/
│   └── services/             # Unit tests
├── llms.txt                  # Complete UTCP documentation
└── package.json

📋 Requirements

Node.js: 20.x or higher
TypeScript: 5.3 or higher
MCP SDK: 1.0.4 or higher

🤝 Contributing

Contributions are welcome! Please follow these steps:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Development Guidelines

Write tests for new features
Follow TypeScript best practices
Update documentation for API changes
Ensure all tests pass before submitting PR

📚 Resources

UTCP Resources

MCP Resources

🐛 Troubleshooting

Server Not Starting

Issue: Error: Cannot find module 'ajv-formats'

Solution:

npm install ajv-formats
npm run build

Documentation Not Loading

Issue: Error loading llms.txt

Solution: Ensure DOCS_PATH environment variable points to the correct directory:

export DOCS_PATH=/path/to/utcp-docs

Validation Errors

Issue: Tool names failing validation

Solution: Use snake_case naming:

✅ get_user_data
❌ GetUserData
❌ getUserData

📄 License

MIT License - see LICENSE file for details

🙏 Acknowledgments

UTCP Team for creating the Universal Tool Calling Protocol
Anthropic for the Model Context Protocol
All contributors to this project

📞 Support

Issues: GitHub Issues
Discussions: GitHub Discussions
Email: support@example.com

Built with ❤️ for the AI development community

Making UTCP implementation easier, one tool at a time.

Available Tools

8 tools

ask_utcp_expertA

Ask a UTCP expert agent (powered by OpenAI) any question about UTCP. The agent has deep knowledge of the entire UTCP specification and will provide detailed, accurate answers with examples and relevant documentation.

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes	Your question about UTCP in natural language (e.g., "How do I authenticate with bearer tokens?", "What is body_template used for?", "Show me an example of SSE protocol")
`performance_mode`	No	Performance mode: "fast" (5 RAG results, 800 char excerpts, ~2-3s), "balanced" (7 results, 1200 chars, ~3-5s), "accurate" (10 results, 2000 chars, ~5-8s, default)	accurate

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It mentions 'powered by OpenAI' and 'deep knowledge' but fails to mention latency, cost, or scope limitations. Performance mode parameter hints at speed but description omits this.

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 concise sentence with key information. It is well-structured and front-loaded, though could be slightly more detailed without becoming verbose.

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 2 parameters, no output schema, and no annotations, the description provides sufficient context: it explains the expert nature, coverage, and output type (answers with examples and documentation). Missing info on return format is minor.

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 describes both parameters. The description adds minimal value beyond schema, which is adequate. Baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for asking a UTCP expert agent any question about UTCP, with deep knowledge of the specification. It distinguishes from sibling search tools by emphasizing detailed, accurate answers with examples and documentation.

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 (ask any question about UTCP) but does not explicitly guide when to use this tool over siblings like search_utcp_docs or semantic_search_docs. It lacks exclusions or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

convert_openapi_to_utcpA

Convert an OpenAPI 3.0 specification to a UTCP manual. Automatically maps endpoints, parameters, and authentication.

ParametersJSON Schema

Name	Required	Description	Default
`openapi_spec`	Yes	OpenAPI 3.0 specification JSON

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must handle transparency. It mentions 'automatically maps' but does not disclose output format, error handling, limitations (e.g., only OpenAPI 3.0), or side effects. Adequate but lacks detail expected for a conversion tool.

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 main action, and no extraneous words. Every sentence adds value.

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?

The tool is complex (conversion with parameter nesting), but the description lacks details on output (no output schema), error states, and steps after conversion. It is adequate for a simple purpose but incomplete for production 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?

Schema coverage is 100% with one parameter fully described. The description adds minimal value beyond the schema, restating that the input is an OpenAPI 3.0 specification. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Convert' and the resource 'OpenAPI 3.0 specification to UTCP manual'. It mentions specific mappings (endpoints, parameters, authentication) and distinguishes from siblings like 'generate_utcp_manual' which builds a manual from scratch, and 'validate_utcp_manual' for validation.

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?

Usage is implied (use when you have an OpenAPI spec to convert), but there is no explicit guidance on when not to use this tool, prerequisites, or alternatives. For example, it doesn't mention if the spec must be valid or if other conversion tools exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_utcp_manualB

Generate a UTCP manual template for a specific protocol (HTTP, CLI, MCP, SSE, Streamable HTTP)

ParametersJSON Schema

Name	Required	Description
`tool_name`	Yes	Tool name (snake_case)
`description`	Yes	Tool description (what it does)
`protocol`	Yes	Communication protocol type
`endpoint`	No	API endpoint URL (for HTTP/MCP protocols)
`method`	No	HTTP method (for HTTP protocols)
`parameters`	No	Tool parameters definition
`include_auth`	No	Include authentication section

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description lacks behavioral details such as whether it overwrites files, what the output format is, or any side effects. Minimal disclosure.

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?

A single, front-loaded sentence with no wasted words. Earning its place.

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 tool with 7 parameters, nested objects, and no output schema, the description is too brief. It doesn't explain what a UTCP manual template is or how the output is structured, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond listing protocol examples, which are already in the enum. Adequate but no additional value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Generate'), the resource ('UTCP manual template'), and the scope ('for a specific protocol') with examples. It distinguishes from sibling tools like 'validate_utcp_manual' or 'get_utcp_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?

No guidance on when to use this tool versus alternatives like 'ask_utcp_expert' or 'get_best_practices'. The context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_best_practicesC

Get UTCP best practices and recommendations for implementation

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No	Specific topic for best practices	general

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description should disclose behavior, but it only says 'Get best practices' without addressing output format, scope, or any restrictions.

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?

Single sentence is concise but lacks necessary details; brevity sacrifices completeness.

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?

With 1 optional parameter and no output schema, description is minimally complete but would benefit from specifying return style or 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 covers parameter fully with description and enum, so baseline of 3 applies. Description adds no extra meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it retrieves UTCP best practices and recommendations, distinguishing it from sibling tools like ask_utcp_expert or get_utcp_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?

No guidance on when to use this tool versus alternatives like search_utcp_docs or ask_utcp_expert. Missing context for optimal usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_utcp_examplesA

Get example UTCP manuals for common use cases (weather API, GitHub API, database, CLI tools)

ParametersJSON Schema

Name	Required	Description	Default
`use_case`	Yes	Example use case to generate

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the basic purpose without disclosing any behavioral traits, such as output format, error handling, or potential side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the verb and resource, and efficiently lists the use cases without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one enum parameter), the description is adequate but lacks details on output format or content, which could be helpful since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear description for the single parameter. The description adds minimal value by listing examples, which is consistent with the enum values.

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 'Get' and the resource 'example UTCP manuals', and lists specific use cases, distinguishing it from sibling tools like generate_utcp_manual or get_best_practices.

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 use when needing example manuals for the listed use cases, but provides no explicit guidance on when to use alternatives or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_utcp_docsB

Search UTCP documentation for specific topics, protocols, or concepts. Returns relevant documentation sections with excerpts.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (e.g., "http protocol", "authentication", "cli tools")
`section`	No	Optional: Limit search to specific documentation section
`limit`	No	Maximum number of results to return (default: 5, max: 15)
`excerpt_length`	No	Length of excerpt in characters (default: 700, min: 200, max: 2000). Use larger values for more context.

TDQS

B3.1/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 only indicates a read operation returning excerpts, but lacks details such as search algorithm (keyword vs semantic), pagination, rate limits, or any side effects. This minimal transparency leaves the agent with incomplete understanding.

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 with only two sentences, both front-loaded with the core purpose. Every part is essential and there is no verbose or redundant content.

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 that the schema thoroughly describes all parameters and the tool has no output schema, the description adequately covers basic intent. However, it lacks contextual details like return format structure, error handling, or behavior when no results match, leaving some gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage with descriptive parameter descriptions. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate. The description does not compensate for any missing schema 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 verb ('Search'), resource ('UTCP documentation'), and output ('relevant documentation sections with excerpts'). It is specific and effectively communicates what the tool does. However, it does not explicitly differentiate from the sibling tool 'semantic_search_docs', which might have similar 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, nor does it mention when not to use it. The agent must infer usage from the name and basic purpose, which is insufficient for optimal tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

semantic_search_docsA

Advanced semantic search using RAG (Retrieval-Augmented Generation) over UTCP documentation. Provides enhanced relevance scoring, query expansion, and detailed match reasons. Use this for more sophisticated searches than the basic search_utcp_docs tool.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query - can be natural language or keywords
`limit`	No	Maximum number of results to return (default: 10)
`excerpt_length`	No	Length of excerpt in characters (default: 2000)
`section`	No	Optional: Limit search to specific documentation section
`min_relevance`	No	Minimum semantic relevance score (0-100+, default: 0)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It indicates the tool performs 'search' and 'RAG', implying read-only operation, but does not explicitly state it is non-destructive or mention other behaviors like rate limits or authentication. The description adds some context but lacks explicit safety disclosure.

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—two sentences that immediately convey the tool's advanced nature and usage guidance. Every sentence adds value, and no unnecessary words are used. It is well front-loaded.

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?

The tool has five parameters and no output schema. The description mentions 'detailed match reasons' and 'relevance scoring', partially addressing return value. However, it does not fully describe the output structure (e.g., whether results include snippets, scores, etc.). Given the absence of an output schema, slightly more detail would enhance completeness.

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 all parameters are already documented in the schema. The description does not add any additional semantic meaning beyond what the schema provides (e.g., explaining the semantics of 'min_relevance' or the enum values). 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 tool performs 'advanced semantic search using RAG over UTCP documentation' and lists specific features (relevance scoring, query expansion, match reasons). It distinguishes itself from the sibling 'search_utcp_docs' by calling it 'basic', making the purpose and differentiation explicit.

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 advises to use this tool for 'more sophisticated searches than the basic search_utcp_docs tool', providing direct guidance on when to use it instead of a sibling. While it doesn't explicitly state when not to use it (e.g., for simple keyword lookups), the contrast implies the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

validate_utcp_manualA

Validate a UTCP manual against the v1.0.1 specification. Returns validation errors and warnings.

ParametersJSON Schema

Name	Required	Description	Default
`manual`	Yes	The UTCP manual JSON object to validate

TDQS

A3.5/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. It only states it returns errors and warnings but does not disclose side effects (e.g., read-only), dependencies, or deeper behavioral traits.

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?

Single sentence that is front-loaded with the action. Efficient but could slightly improve by including a read-only note. No 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?

For a simple tool with one parameter and no output schema, the description adequately covers purpose and return value. However, it omits specifics like error format or validation criteria, which would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for the only parameter. The tool description adds no additional meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Validate a UTCP manual against the v1.0.1 specification' with specific verb and resource, and distinguishes from sibling tools like generate_utcp_manual or convert_openapi_to_utcp.

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?

Implies usage for validation but does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives. The context of sibling tools helps, but the description lacks direct guidance.

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.

8 tool updatesv1.0.0May 26, 2026
- First observedask_utcp_expert
- First observedconvert_openapi_to_utcp
- First observedgenerate_utcp_manual
- First observedget_best_practices
- First observedget_utcp_examples
- First observedsearch_utcp_docs
- First observedsemantic_search_docs
- First observedvalidate_utcp_manual

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but search_utcp_docs and semantic_search_docs overlap significantly, both serving documentation search with only detail-level differences. This could cause an agent to misselect.

Naming Consistency4/5

Names follow a verb_noun pattern consistently (ask_, convert_, generate_, get_, search_, validate_). However, semantic_search_docs deviates slightly by including an adjective before the verb, and the two search tools differ in naming scheme while still being recognizable.

Tool Count5/5

8 tools is appropriate for a documentation and specification server. Each tool addresses a specific need: expert Q&A, conversion, generation, examples, best practices, validation, and two search variants. No tool seems superfluous, and the count is well within the ideal 3-15 range.

Completeness4/5

The tool set covers the core workflows of interacting with UTCP documentation: asking questions, converting from OpenAPI, generating manuals, retrieving examples and best practices, searching, and validating. Missing a tool for updating or comparing manuals, but the set is largely complete for the server's stated purpose.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
Tseha AFeatured
io.tseha
Serves your design system and coding standards to coding agents, so they stop guessing.
Developer Tools Documentation Access
93
AI Design Blueprint A
com.aidesignblueprint
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
AI & Machine Learning Autonomous Agents
292
gjallaOAuth
io.gjalla
Production-readiness for your AI coding agents.
Coding Agents Agent Orchestration
22

Related MCP Servers

Swagger MCP Server
Developer Tools API Testing Documentation Access
nksmkj7
F
license
Not graded
quality
D
maintenance
Brings OpenAPI/Swagger documentation into AI assistants, enabling endpoint discovery, deep inspection, cURL generation, and TypeScript type generation.
Updated 3 months ago (2026-06-09 02:06 UTC)
-
Specmatic MCP Serverofficial
API Testing Testing & QA Tools
specmatic
A
license
A
quality
D
maintenance
Exposes Specmatic's API contract testing, resiliency testing, and mocking capabilities to AI coding agents via natural language, enabling automated validation and simulation of API behaviors.
Updated 3 months ago (2026-06-10 01:12 UTC)
3
21
12
MIT
OpenAPI Specification Docs MCP
Documentation Access Developer Tools
a-zara-n
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with OpenAPI documents for analysis, validation, and management through structured interfaces.
Updated a year ago (2025-07-11 18:27 UTC)
322
3
ISC
LockSpec
Developer Tools API Testing Documentation Access
LockSpec
A
license
Not graded
quality
C
maintenance
Provides AI coding agents with accurate OpenAPI contract details to prevent hallucinated API calls, supporting multi-version pinning, endpoint discovery, and request validation.
Updated 3 months ago (2026-06-10 23:03 UTC)
74
Apache 2.0

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/edujuan/utcp-docs-server'

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

UTCP Documentation MCP Server

🚀 Features

📦 Installation

NPM

From Source

🔧 Configuration

For Claude Desktop

For Cursor IDE

Environment Variables

🛠️ Available Tools

🆕 1. Ask UTCP Expert (LLM Agent)

2. Search UTCP Documentation

3. Validate UTCP Manual

4. Generate UTCP Manual

5. Convert OpenAPI to UTCP

6. Get UTCP Examples

7. Get Best Practices

📖 Resources

🧪 Usage Examples

Example 1: Creating a New UTCP Manual

Example 2: Converting Existing OpenAPI Spec

Example 3: Searching Documentation

🏗️ Development

Setup

Testing

Project Structure

📋 Requirements

🤝 Contributing

Development Guidelines

📚 Resources

UTCP Resources

MCP Resources

🐛 Troubleshooting

Server Not Starting

Documentation Not Loading

Validation Errors

📄 License

🙏 Acknowledgments

📞 Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Specmatic MCP Serverofficial

Latest Blog Posts

MCP directory API