specrun
Enables interaction with the GitHub API when provided with a GitHub OpenAPI specification, demonstrated by the example tool github_get_user_repos for listing user repositories.
Converts Swagger 2.0 (OpenAPI 2.0) specifications into MCP tools, enabling interaction with any API defined by a Swagger spec file alongside OpenAPI 3.0 support.
Built with FastMCP for TypeScript.
✨ Features
Zero Configuration: Filesystem is the interface - just drop OpenAPI specs in a folder
Supports OpenAPI 3.0 and 2.0: Works with both OpenAPI 3.x and Swagger 2.0 specs
Namespace Isolation: Multiple APIs coexist cleanly
Full OpenAPI Support: Handles parameters, request bodies, authentication, and responses
Run Any Tool to Interact with APIs: For example,
cars_addCarto callPOST /carsfromcars.jsonspec to create a new car, orgithub_get_user_reposto callGET /user/reposfromgithub.yamlspec to list repos.Run Any Tool with Custom Inputs: Pass structured JSON inputs for parameters and request bodies
Run Any Tool to see Spec Details: Get the original OpenAPI spec details for any tool, including parameters, request body schema, and response schema
Run Any Tool to get API responses as resources: Each tool call returns a JSON resource containing request URL, request body, and response
Run Any Tool in Batch: One
specrun_batchtool can execute any tool with multiple inputs and returns a consolidated JSON resourceAuto Authentication: Simple
.envfile with{API_NAME}_API_KEYpatternAuto .env Placeholders: Adds
{API_NAME}_SERVER_URLand{API_NAME}_BEARER_TOKENentries when missingMultiple Transports: Support for stdio and HTTP streaming
Built-in Debugging: List command to see loaded specs and tools
MCP Prompts: Built-in prompts for listing tools, generating inputs, and explaining schemas
Agent: configured agent for using SpecRun tools to explore and operate APIs in a guided way (
.github/agents/specrun.agent.md)
Related MCP server: mcpify
Quick Start
Requirements
Node.js 22 or newer
1️⃣ Install (optional)
npm install -g specrun2️⃣ Create a specs folder where the server can read OpenAPI spec files. For example:
mkdir ~/specs3️⃣ Add OpenAPI specs
Drop any .json, .yaml, or .yml OpenAPI specification files into your specs folder
4️⃣ Configure authentication (optional)
Create a .env file in your specs folder:
# ~/specs/.env
CARS_API_KEY=your_api_key_hereSpecRun will also ensure {API_NAME}_SERVER_URL and {API_NAME}_BEARER_TOKEN entries exist for each spec, adding empty placeholders when missing.
When {API_NAME}_SERVER_URL has a value, SpecRun updates the spec file on load:
OpenAPI 3.0: updates the first
serversentry.OpenAPI 2.0 (formerly Swagger 2.0): updates
host,schemes, andbasePath(noserverssection in OpenAPI 2.0).
SpecRun also watches the .env file and refreshes server URLs and auth config automatically after changes.
5️⃣ Add to MCP client configuration
Add to your MCP configuration:
If installed on your machine:
{
"mcpServers": {
"specrun": {
"command": "specrun",
"args": ["--specs", "/path/to/your/specs/folder"]
}
}
}Otherwise:
{
"mcpServers": {
"specrun": {
"command": "npx",
"args": ["-y", "specrun", "--specs", "/absolute/path/to/your/specs"]
}
}
}or with specific Node version:
{
"mcpServers": {
"specrun": {
"command": "/Users/YOUR_USER_NAME/.local/bin/mcp-npx-node22",
"args": ["specrun@latest", "--specs", "/absolute/path/to/your/specs"],
"type": "stdio"
}
}
}The mcp-npx-node22 script file uses nvm to run specrun with Node.js 22.14.0, ensuring compatibility regardless of the default Node version on your system.:
#!/bin/bash
# Set the PATH to include NVM's Node.js v22.14.0 installation
export PATH="/Users/YOUR_USER_NAME/.nvm/versions/node/v22.14.0/bin:$PATH"
# Execute npx with all passed arguments
exec npx "$@"💻 CLI Usage
🚀 Start the server
# Default: stdio transport, current directory
specrun
# Custom specs folder
specrun --specs ~/specs
# HTTP transport mode
specrun --transport httpStream --port 8080Run with Node 22 using npx
If your default node is older than 22, run SpecRun with Node 22 directly:
npx -y node@22 ...runs the Node.js runtime, so the next argument must be a script path (for example./node_modules/.bin/specrun).specrun@latestis an npm package spec and works directly withnpxonly when your current Node version already satisfies SpecRun requirements.
# Or list tools
npx -y node@22 ./node_modules/.bin/specrun list --specs ~/specs
# If your default Node is already 22+, this also works
npx -y specrun@latest --specs ~/specs📋 List loaded specs and tools
# List all loaded specifications and their tools
specrun list
# List specs from custom folder
specrun list --specs ~/specs
🔑 Authentication Patterns
The server automatically detects authentication from environment variables using these patterns:
Pattern | Auth Type | Usage |
| 🗝️ API Key |
|
| 🎫 Bearer Token |
|
| 🎫 Bearer Token |
|
| 👤 Basic Auth |
|
SpecRun also creates .env placeholders for:
Pattern | Purpose |
| Base URL for the API |
| Token placeholder if missing |
If {API_NAME}_SERVER_URL is set, SpecRun writes that value into the spec before generating tools:
OpenAPI 3.0: writes the first
serversentry.OpenAPI 2.0 (formerly Swagger 2.0): writes
host,schemes, andbasePath.
Updates to .env are applied automatically without restarting the MCP server.
The {API_NAME} is derived from the filename of your OpenAPI spec:
cars.json→CARS_API_KEYgithub-api.yaml→GITHUB_TOKENmy_custom_api.yml→MY_CUSTOM_API_KEY
🏷️ Tool Naming
Tools are automatically named using this pattern:
With operationId:
{operation_id}Without operationId:
{method}_{path_segments}
Name normalization rules:
Converted to
snake_caseLowercased
Non-alphanumeric characters normalized to
_Truncated at the end when longer than 52 characters. (For VS Code/Copilot compatibility, stays within the practical 64-char internal limit.)
Adds short suffixes only when needed to resolve collisions
Specs:
get_car_by_id(from operationId)get_user_repos(generated fromGET /user/repos)
Use the shared batch tool to run any tool with an array of inputs:
{
"toolName": "cars_getCarById",
"items": [{ "id": "123" }, { "id": "456" }],
"failFast": false
}Batch responses return a consolidated JSON resource with per-item outputs.
For batches over 200 items, SpecRun requires explicit confirmation. This is to prevent accidental large runs that could cause performance issues or unintended consequences. The server will return a message asking for confirmation, and you can retry with confirmLargeBatch: true and the provided confirmLargeBatchToken to proceed.
📦 Resource Outputs
Tool responses are returned as MCP resources with application/json content. Each resource includes:
Request URL
Request body
Response status and body
Example resource payload:
{
"requestUrl": "https://api.example.com/v1/users/123",
"requestBody": null,
"response": {
"status": 200,
"body": {
"id": "123",
"name": "Jane Doe"
}
}
}Batch runs return a single consolidated resource containing all item results.
📁 File Structure
your-project/
── specs/ # Your OpenAPI specs folder
├── .env # Authentication credentials
└── custom-api.yml # Your OpenAPI spec files🧭 MCP Prompts
SpecRun exposes MCP prompts for common workflows:
Detailed prompt guide with examples: PROMPTS_README.md
list_apis: List loaded APIs/tools and ask the user to choose an endpointgenerate_api_call: Generate a ready-to-run JSON input payload for a toolexplain_api_schema: Explain parameters and request body schema with examplesgenerate_random_data: Generate random ready-to-run JSON payload samples for a tool
📄 Example OpenAPI Spec
Here's a minimal example that creates two tools:
# ~/specs/example.yaml
openapi: 3.0.0
info:
title: Example API
version: 1.0.0
servers:
- url: https://api-server.placeholder
paths:
/users/{id}:
get:
operationId: getUser
summary: Get user by ID
parameters:
- name: id
in: path
required: true
schema:
type: string
responses:
"200":
description: User found
/users:
post:
operationId: createUser
summary: Create a new user
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
name:
type: string
email:
type: string
responses:
"201":
description: User createdThis creates tools named:
example_getUserexample_createUser
🔧 Troubleshooting
❌ No tools appearing?
Check that your OpenAPI specs are valid:
specrun list --specs /path/to/specsEnsure files have correct extensions (
.json,.yaml,.yml)Check the server logs for parsing errors
⚠️ Note: SpecRun works best when you use absolute paths (with no spaces) for the
--specsargument and other file paths. Relative paths or paths containing spaces may cause issues on some platforms or with some MCP clients.
🔐 Authentication not working?
Verify your
.envfile is in the specs directoryCheck the naming pattern matches your spec filename
Use the list command to verify auth configuration:
specrun list
🔄 Tools not updating after spec changes?
Restart the MCP server to reload the specs
Check file permissions
Restart the MCP client if needed
🛠️ Development
# Clone and install
git clone git@github.com:Pavel-Piha/specrun.git
cd specrun
npm install
# Build
npm run build
npm run dev -- list --specs ./specs🤝 Contributing
Contributions are welcome! Please feel free to submit issues and pull requests.
Available Tools
1 toolspecrun_batchC
Run any SpecRun tool in batch with multiple inputs
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| failFast | No | ||
| toolName | Yes | ||
| confirmLargeBatch | No | ||
| confirmLargeBatchToken | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits such as destructive potential, rate limits, or confirmation flows (despite parameters suggesting confirmLargeBatch). It is insufficient for safe invocation.
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 concise at one sentence, but it sacrifices necessary detail. It is front-loaded but lacks structure or elaboration, which is acceptable only for very simple tools.
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 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, batch behavior, or error handling, making it inadequate for reliable 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?
Parameter descriptions are absent in the schema (0% coverage) and the tool description provides no additional meaning for any of the five parameters, including required ones like toolName and items.
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 action ('Run') and the resource ('SpecRun tool in batch with multiple inputs'), making it understandable. However, it lacks specificity about what SpecRun tools are, which slightly reduces clarity.
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, no prerequisites, and no context for batch processing. It leaves the agent without direction on appropriate usage.
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.
1 tool update
v1.7.0- First observed
specrun_batch
TDQS
Scored across 1 tool
Only one tool exists, so there is no ambiguity in tool selection.
The single tool name follows snake_case and verb_noun convention consistently.
With only one tool, the server feels thin for its apparent scope, though the batch tool can handle multiple inputs.
The server lacks individual tools for different SpecRun operations, making it incomplete for fine-grained control.
Maintenance
Related MCP Connectors
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server for AI access to Swagger by SmartBear.
MCP server (stdio): lint OpenAPI specs with Spectral via the AgentForge API
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceAutomatically converts any OpenAPI specification into an MCP server, exposing all HTTP endpoints as callable tools with support for various authentication methods and request types.2-
- AlicenseNot gradedqualityCmaintenanceTurns any OpenAPI specification into a fully working MCP server with a single command, enabling AI agents to call APIs without writing any glue code.9 npmMIT
- AlicenseNot gradedqualityDmaintenanceAutomatically generates MCP server tools from OpenAPI specifications, enabling LLMs to interact with any API defined by an OpenAPI spec through natural language.19 npmMIT
- AlicenseNot gradedqualityDmaintenanceConverts an OpenAPI spec into an MCP server, enabling AI agents to call your API without writing tool definitions or integration code.3MIT