Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@openapi-mcp-bridge list available API tools from my OpenAPI definition"
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.
Transform OpenAPI definitions into MCP (Model Context Protocol) tools for seamless LLM-API integration.
Model Context Protocol (MCP) is a standard protocol that allows AI models to interact with external tools and data sources. Unlike REST APIs that use HTTP requests, MCP uses JSON-RPC messages over stdio or WebSocket connections.
Key Differences:
REST API: HTTP requests → JSON responses
MCP: JSON-RPC messages → Tool calls and responses
Purpose: MCP bridges AI models with external systems safely and efficiently
Why OpenAPI → MCP?
Your APIs are already documented in OpenAPI format
AI models can't directly call REST APIs
MCP provides a secure, standardized way to expose API functionality to AI
Related MCP server: openapi-mcp-server
npm install -g openapi-mcp-bridge
mkdir my-api && cd my-apicat > museum-api.yaml << 'EOF'
openapi: 3.1.0
info:
title: Museum API
version: 1.0.0
servers:
- url: https://redocly.com/_mock/demo/openapi/museum-api
paths:
/museum-hours:
get:
summary: Get museum hours
operationId: getMuseumHours
parameters:
- name: date
in: query
schema:
type: string
format: date
components:
securitySchemes:
BasicAuth:
type: http
scheme: basic
EOF# Terminal 1: Start MCP server
openapi-mcp-bridge --definitions .
# Terminal 2: Test with inspector
npm install -g @modelcontextprotocol/inspector
mcp-inspector npx openapi-mcp-bridge --definitions .Result: You'll see getMuseumHours tool available in the MCP Inspector interface.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"museum-api": {
"command": "npx",
"args": ["openapi-mcp-bridge", "--definitions", "/path/to/your/api-definitions"]
}
}
}Usage: Ask Claude "What are the museum hours?" and it will automatically call your API.
Create .claude-code-mcp.json in your project:
{
"mcpServers": {
"my-api": {
"command": "npx",
"args": ["openapi-mcp-bridge", "--definitions", "./api-definitions"]
}
}
}Claude Code will automatically detect and use your API tools.
// TypeScript example with proper ES module setup
import { spawn } from 'child_process';
import { MCPClient } from '@modelcontextprotocol/client';
const serverProcess = spawn('npx', ['openapi-mcp-bridge', '--definitions', './api-definitions']);
const client = new MCPClient();
await client.connect({
stdio: {
stdin: serverProcess.stdin,
stdout: serverProcess.stdout
}
});
// List available tools
const tools = await client.listTools();
console.log('Available tools:', tools);
// Call a tool
const result = await client.callTool('getMuseumHours', { date: '2024-01-15' });
console.log('Result:', result);Use Case | Approach | Best For |
AI Model Integration | CLI ( | Claude Desktop, Claude Code, custom MCP clients |
Web Application | Express/Fastify middleware | Adding MCP endpoints to existing web apps |
Microservice | Standalone server | Dedicated MCP service, Docker deployments |
Development/Testing | MCP Inspector | Testing and debugging MCP tools |
Do you want to integrate with an AI model?
├── Yes → Use CLI approach
│ ├── Claude Desktop → Update claude_desktop_config.json
│ ├── Claude Code → Use `claude mcp add` command
│ └── Custom client → Use stdio connection
└── No → Use HTTP approach
├── Existing Express app → Use Express middleware
├── New microservice → Use standalone server
└── Testing → Use MCP InspectorTransport | Use Case | Pros | Cons | Best For |
stdio | AI model integration | Simple, secure, no network config | Single process, local only | Claude Desktop, Claude Code, development |
HTTP | Web applications | Multi-user, remote access, familiar | Network setup, security concerns | Production APIs, microservices |
WebSocket | Real-time updates | Bi-directional, low latency | Complex setup, connection management | Streaming, live data |
stdio is the recommended transport for AI model integration because:
✅ Security: No network exposure or authentication needed
✅ Simplicity: Direct process communication
✅ Performance: Lower overhead than HTTP
✅ Reliability: No network connectivity issues
✅ Lifecycle: Automatic process management
# ❌ Error: Cannot find module 'openapi-mcp-bridge/express'
import { createExpressMiddleware } from 'openapi-mcp-bridge/express';
# ✅ Solution: Use the correct package exports
import { createExpressMiddleware } from 'openapi-mcp-bridge/express';Root Cause: Package uses ES modules. Ensure your package.json has "type": "module".
# ❌ Wrong: Trying to make HTTP requests to MCP endpoint
curl -X POST http://localhost:3000/mcp
# ✅ Right: Use MCP Inspector or MCP client
mcp-inspector http://localhost:3000/mcpRoot Cause: MCP is not a REST API. It uses JSON-RPC over stdio/WebSocket.
# ❌ Error: EADDRINUSE: address already in use :::3000
npm start
# ✅ Solution: Use a different port
PORT=3001 npm start
# or
npx openapi-mcp-bridge --definitions . --port 3001# ❌ Warning: --port is not yet implemented in stdio mode
openapi-mcp-bridge --definitions . --port 3000
# ✅ Solution: Don't use --port with CLI (stdio mode)
openapi-mcp-bridge --definitions .Root Cause: CLI runs in stdio mode for MCP clients. Use standalone server for HTTP mode.
// ❌ CommonJS in ES module project
const { createExpressMiddleware } = require('openapi-mcp-bridge/express');
// ✅ ES modules syntax
import { createExpressMiddleware } from 'openapi-mcp-bridge/express';Setup for TypeScript projects:
// package.json
{
"type": "module",
"scripts": {
"start": "tsx src/server.ts"
}
}// tsconfig.json
{
"compilerOptions": {
"module": "ES2022",
"moduleResolution": "node",
"target": "ES2022",
"esModuleInterop": true,
"allowSyntheticDefaultImports": true
}
}Enable detailed logging:
# CLI
openapi-mcp-bridge --definitions . --debug
# Environment variable
DEBUG=true openapi-mcp-bridge --definitions .
# Programmatic
const config = {
logging: { consoleFallback: true },
debug: true
};# Check if OpenAPI file is valid
npx @redocly/cli lint your-api.yaml
# Force cache regeneration
OPENAPI_FORCE_REGEN=true openapi-mcp-bridge --definitions .
# Test tool generation
mcp-inspector npx openapi-mcp-bridge --definitions .// server.ts
import express from 'express';
import { createExpressMiddleware } from 'openapi-mcp-bridge/express';
const app = express();
// Add MCP endpoint
app.use('/mcp', createExpressMiddleware({
definitionsDirectory: './api-definitions',
defaultCredentials: {
username: process.env.API_USERNAME,
password: process.env.API_PASSWORD
}
}));
// Add health check
app.get('/health', (req, res) => {
res.json({ status: 'healthy' });
});
app.listen(3000, () => {
console.log('MCP server: http://localhost:3000/mcp');
});import { MCPServer } from 'openapi-mcp-bridge';
const server = new MCPServer({
definitionsDirectory: './api-definitions',
port: 3000,
mountPath: '/mcp',
defaultCredentials: {
username: process.env.API_USERNAME,
password: process.env.API_PASSWORD
}
});
await server.start();
console.log('MCP server running on http://localhost:3000/mcp');interface Config {
definitionsDirectory: string;
cacheDirectory?: string;
defaultCredentials?: {
username?: string;
password?: string;
token?: string;
apiKey?: string;
};
logging?: {
winston?: any;
pino?: any;
consoleFallback?: boolean;
};
mcpOptions?: {
serverName?: string;
serverVersion?: string;
};
}The library generates predictable tool names from OpenAPI operations:
OpenAPI Operation | Generated Tool Name | Rule |
|
| Uses operationId when available |
|
| Uses operationId when available |
|
| Auto-generated: |
|
| Auto-generated: |
|
| Auto-generated: handles nested paths |
Override generated names using customization:
# museum-api.custom.yaml
toolAliases:
"getMuseumHours": "get-hours"
"createSpecialEvent": "create-event"
"get-events-by-eventId": "get-event-details"List available tools programmatically:
# Using MCP Inspector
mcp-inspector npx openapi-mcp-bridge --definitions ./api-definitions
# In Claude Code
"What tools are available?"
# In Claude Desktop
"List all museum API tools"your-project/
├── api-definitions/
│ ├── museum-api.yaml # OpenAPI specification
│ ├── museum-api.custom.yaml # Optional customization
│ └── .cache/ # Auto-generated cache
├── src/
│ └── server.ts # Your server code
├── package.json # {"type": "module"}
└── tsconfig.json # ES2022 modulesSupports HTTP Basic, Bearer tokens, and API keys:
# museum-api.custom.yaml
authenticationOverrides:
- endpoint: "*"
credentials:
username: "${API_USERNAME}"
password: "${API_PASSWORD}"# Test tool generation
npm install -g @modelcontextprotocol/inspector
mcp-inspector npx openapi-mcp-bridge --definitions ./api-definitions
# Validate OpenAPI specs
npx @redocly/cli lint api-definitions/*.yaml
# Test with real API calls
node -e "
import { MCPClient } from '@modelcontextprotocol/client';
// ... client code
"Fork the repository
Create a feature branch
Add tests for new functionality
Ensure all tests pass
Submit a pull request
MIT License - see LICENSE file for details.
Model Context Protocol for the MCP specification
OpenAPI Initiative for the OpenAPI specification
ReadMe OpenAPI Parser for robust OpenAPI parsing
Need help? Check our troubleshooting guide or open an issue.
Buy museum tickets
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only implies a transaction but does not mention side effects, authentication needs, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (3 words) but at the expense of clarity and completeness. Under-specification is not true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a purchase action with minimal schema coverage and no output schema, the description is severely inadequate. No details on expected input, behavior, or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'body' has no type or description in schema, and the description does not explain what the body should contain. Critical information missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'buy' and resource 'museum tickets', distinguishing it from sibling tools focused on events and hours. However, it does not specify ticket type or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Lacks context for prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create special events
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states 'Create special events' without disclosing side effects, permissions, or whether the operation is idempotent. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just three words, which is too brief to be helpful. While conciseness is valued, this lacks essential information and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is wholly incomplete. It fails to explain event structure, required fields, return value, or any constraints, making it nearly useless for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'body', has an empty schema ({}), and schema description coverage is 0%. The description adds no meaning about what the body should contain, leaving the agent completely uninformed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create special events' uses a clear verb and resource, distinguishing it from siblings like update-event, list-events, and delete-event. However, the word 'special' is vague and could confuse an agent about what constitutes a special event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update-event or get-event-details. An agent has no criteria to decide between creation and modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete special event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | Identifier for a special event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Delete' without disclosing irreversibility, permission requirements, or cascading effects. Full burden falls on description, which fails to provide behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (4 words) but at the cost of missing essential details. While no wasted words, it is under-specified for a multi-tool context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no annotations or output schema, the description should at least mention if deletion is permanent or requires confirmation. It is incomplete for safe tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (eventId described as 'Identifier for a special event'). Description adds no additional parameter meaning, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete special event' uses a specific verb ('Delete') and resource ('special event'), clearly distinguishing it from siblings like create-event or update-event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., update-event for modifications, get-event-details for viewing). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get special event
| Name | Required | Description | Default |
|---|---|---|---|
| eventId | Yes | Identifier for a special event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only says 'Get special event' without mentioning any side effects, permissions, rate limits, or response nature. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is underspecification rather than conciseness. It lacks necessary details to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no output schema, the description should explain what details are returned. It fails to provide any context about the response, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'eventId' parameter. The tool description adds no additional meaning beyond what's in the schema, thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get special event' includes a verb ('Get') and a resource ('event'), but it's vague as it doesn't clarify what 'special event' means or distinguish from similar tools like 'list-events'. It's minimally adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'list-events' or 'get-ticket-qr'. There are no prerequisites, when-not-to-use, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ticket QR code
| Name | Required | Description | Default |
|---|---|---|---|
| ticketId | Yes | Identifier for a ticket to a museum event. Used to generate ticket image. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as side effects, required permissions, or output format. The parameter description hints at image generation, but the tool's behavior (e.g., if it returns an image file or URL) is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, extremely concise with no redundancy. However, it is slightly terse and could be expanded to include output hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is minimally adequate. It covers the basic purpose but lacks detail on the return format, which may be needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter fully described in the input schema. The tool description does not add meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get ticket QR code' uses a specific verb ('get') and resource ('ticket QR code'), clearly indicating the tool's purpose. It is distinct from siblings which focus on events, museum hours, and ticket purchasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context for choosing this tool over siblings, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List special events
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number to retrieve. | |
| limit | No | Number of days per page. | |
| endDate | No | End of a date range to retrieve special events for. Defaults to 7 days after `startDate`. | |
| startDate | No | Starting date to retrieve future operating hours from. Defaults to today's date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It does not mention that the tool is read-only, paginated, or that date parameters have defaults. The schema provides some parameter details, but overall behavioral context is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At only three words, the description is too concise and under-specified. It could benefit from a brief sentence explaining the tool's purpose and key parameters without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the four parameters, no output schema, and no annotations. It does not explain what the returned data contains, how pagination works, or what qualifies as 'special events'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides (e.g., date range, pagination).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List special events' clearly states it lists special events, but it is a minimal restatement of the tool name without specifying the scope or differentiating from siblings like list-museum-hours or get-event-details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings like update-event, create-event, and get-event-details exist, but the description does not clarify that list-events is for retrieving multiple events with optional date and pagination filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get museum hours
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number to retrieve. | |
| limit | No | Number of days per page. | |
| startDate | No | Starting date to retrieve future operating hours from. Defaults to today's date. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to mention that this is a read-only operation, lacks any side-effect details, and does not describe return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but too terse to be effective. It could benefit from a bit more structure or detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 3 parameters, the description is too minimal. It does not explain the return format, the concept of museum hours, or how parameters like pagination work together. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with each parameter having a description. The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get museum hours', which is a clear verb-resource pair, but is vague. It does not specify which museum or differentiate from sibling tools like list-events. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Sibling tools like list-events or buy-tickets could overlap in context, but the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update special event
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| eventId | Yes | Identifier for a special event. |
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 only states 'Update', which implies mutation, but does not describe side effects, permissions, idempotency, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is too minimal. While concise, it lacks structure and fails to convey key details. It would benefit from front-loaded, informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and no annotations, the description is incomplete. It does not mention what 'body' should contain, update semantics (e.g., partial vs full replacement), or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 50% coverage: 'eventId' has a description, but 'body' does not. The description does not add meaning to the parameters, especially 'body', leaving the agent to guess its structure or content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update special event' clearly identifies the verb (update) and the resource (special event). It distinguishes from sibling tools like 'create-event' and 'delete-event', indicating that it modifies an existing event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, limitations, or scenarios. Sibling tool names imply a CRUD context, but the description itself lacks explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.6buy-ticketscreate-eventdelete-eventget-event-detailsget-ticket-qrlist-eventslist-museum-hoursupdate-eventEach tool targets a distinct function: CRUD for events, listing hours, and ticket operations. No overlap between tools.
All tool names follow a consistent verb_noun pattern with underscores, e.g., update-event, list-museum-hours, buy-tickets.
8 tools is well-scoped for a museum domain covering events, hours, and ticket purchase/QR retrieval.
Events have full CRUD, museum hours listed, tickets covered for purchase and QR. Missing cancellation or history of tickets, but core is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Point Gecko at an OpenAPI spec; get first-call-correct, auth-hidden agent tools.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ephrin/openapi-mcp-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
