Skip to main content
Glama
ghively

Any-API MCP Server

by ghively
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Any-API MCP Server Template

A minimal, configurable Model Context Protocol (MCP) server you can use to adapt any HTTP API into an MCP toolset. It focuses on safety, clarity, and fast onboarding.

What You Get

  • Generic HTTP tools: api_probe, api_get, api_post, api_put, api_delete

  • Pluggable auth (header, bearer, basic, query param)

  • Safe defaults: retries for GET only, rate-limit awareness (Retry-After), STDERR logging with redaction

  • Zero-boilerplate startup via STDIO (MCP)

  • TypeScript, strict mode, ESM

Related MCP server: ControlAPI-MCP

Quick Start

  1. Use this repo as your starting point:

  • This repository root is the template — there is no separate templates/ subdirectory to copy from.

  • Clone it, then rename/fork it for your own project (e.g. mcp-any-api).

  1. Install and build

npm ci
npm run build

  1. Configure environment (two simple options) Option A — API key/token you already have: Create .env.local (auto-loaded by scripts) with your API details:

API_BASE=https://api.example.com/v1
AUTH_MODE=bearer              # one of: none|bearer|header|basic|query
AUTH_TOKEN=YOUR_TOKEN         # bearer token or header value depending on mode
AUTH_HEADER=Authorization     # used if AUTH_MODE=header (default Authorization)
AUTH_QUERY_KEY=api_key        # used if AUTH_MODE=query
ALLOW_DESTRUCTIVE=false       # guard writes

Option B — OAuth 2.0 (automated helpers):

Client Credentials (service-to-service):

TOKEN_URL=https://auth.example.com/oauth/token \
CLIENT_ID=... CLIENT_SECRET=... SCOPE="api.read api.write" \
npm run oauth2:client

This writes AUTH_MODE/AUTH_TOKEN into .env.local.

Device Code (user sign-in on a second device):

DEVICE_AUTH_URL=https://auth.example.com/oauth/device/code \
TOKEN_URL=https://auth.example.com/oauth/token \
CLIENT_ID=... SCOPE="api.read" \
npm run oauth2:device

Follow the printed verification URL and code. Upon success, the script updates .env.local.


4) Run in dev
```bash
npm run dev

  1. Add to your MCP client (example Claude Desktop)

{
  "mcpServers": {
    "any-api": {
      "command": "node",
      "args": ["/absolute/path/to/dist/server.js"],
      "env": {
        "API_BASE": "https://api.example.com/v1",
        "AUTH_MODE": "bearer",
        "AUTH_TOKEN": "YOUR_TOKEN",
        "ALLOW_DESTRUCTIVE": "false"
      }
    }
  }
}

Tools

  • api_probe (safe):

    • Inputs: path (string), method (string), optional headers (record)

    • Executes a single request and returns status, content-type, body preview (first N bytes)

  • api_get (safe):

    • Inputs: path, optional query (record), optional headers

    • Retries on 429/502/503/504 with backoff; honors Retry-After

  • api_post (guarded), api_put (guarded), api_delete (guarded):

    • Inputs: path, optional payload (any), optional headers

    • DELETE supports optional payload if API expects a body

All tools auto-join API_BASE with path and attach auth based on AUTH_MODE.

Auth Modes

  • none: no auth header

  • bearer: Authorization: Bearer <AUTH_TOKEN>

  • header: <AUTH_HEADER>: <AUTH_TOKEN>

  • basic: Authorization: Basic <AUTH_TOKEN> (you provide base64)

  • query: appends ?<AUTH_QUERY_KEY>=<AUTH_TOKEN> (or & when query exists)

Rate Limiting

  • GETs retry on 429/502/503/504 using exponential backoff with jitter

  • Retry-After header is honored when present

  • Scripts accept PROBE_DELAY_MS to pace probes

Examples

Probe a path safely:

{
  "path": "/users",
  "method": "OPTIONS"
}

GET with query:

{
  "path": "/search",
  "query": { "q": "widgets", "page": 2 }
}

POST (guarded):

{
  "path": "/widgets",
  "payload": { "name": "Example", "price": 100 }
}

Customizing

  • Add typed, domain-specific tools by creating new handlers in src/server.ts

  • Keep ALLOW_DESTRUCTIVE=false until you’re ready to allow writes

  • To support OAuth2 flows, fetch tokens outside the server and set AUTH_MODE=bearer with AUTH_TOKEN

Scripts

  • npm run validate:endpoints (safe): probes a set of paths/methods via GET/OPTIONS; pacing + Retry-After; dynamic delay adaptation

  • npm run probe:get (safe): throttled GET probe for a given list

  • npm run discover:openapi (safe): tries common OpenAPI/Swagger URLs, lists endpoints/methods, and saves raw spec

  • npm run scan:wordlist (safe): OPTIONS-scan using a small default wordlist or a provided file; dynamic delay adaptation

  • npm run inventory:api (safe): one-command inventory; tries OpenAPI first, then wordlist; writes JSON to reports/

  • npm run openapi:to:tools (safe): converts an OpenAPI JSON file to tools.json for dynamic tool registration

  • npm run scan:to:tools (safe): converts a wordlist scan report to tools.json

  • npm run oauth2:client / npm run oauth2:device: obtain OAuth tokens and update .env.local

Environment knobs:

  • PROBE_DELAY_MS: pacing between requests (default 800–1500ms)

  • OUTPUT / OUTPUT_DIR: where to save reports

  • WORDLIST: path to a custom wordlist (for scan:wordlist)

All scripts auto-load .env.local.

Dynamic Tools (No Code Changes)

This server auto-registers tools from tools.json (if present in the working directory). You can generate tools.json from discovery output:

From OpenAPI:

OPENAPI_FILE=reports/openapi_*.json TOOLS_FILE=tools.json npm run openapi:to:tools

From wordlist scan:

SCAN_FILE=reports/wordlist_*.json TOOLS_FILE=tools.json npm run scan:to:tools

Once tools.json exists, restart the server and the generated tools are available automatically. GET tools are safe; mutating tools are guarded (require ALLOW_DESTRUCTIVE=true).

Example: Hexnode API

Use the provided example tools file and Hexnode credentials:

  1. Copy example to working tools file

cp examples/hexnode.tools.json tools.json

  1. Configure Hexnode env in .env.local (header auth)

API_BASE=https://<portal>.hexnodemdm.com/api/v1
AUTH_MODE=header
AUTH_HEADER=Authorization
AUTH_TOKEN=<your-hexnode-api-key>
ALLOW_DESTRUCTIVE=false

  1. Start the server

npm run build && npm start

Note: Some Hexnode tenants use singular policy paths (/policy/…) and others plural (/policies/…). The example includes both; use whichever works for your tenant or remove non-applicable entries from tools.json.

File Layout

  • src/server.ts: MCP entrypoint

  • src/lib/*.ts: helpers (qs, retry, logger)

  • scripts/*: verification probes

  • dist/*: compiled output

License

MIT — see LICENSE.

Available Tools

5 tools
api_deleteC

Generic DELETE against API_BASE (guarded).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
headersNo
payloadNo

TDQS

C2.8/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. 'Guarded' hints at access protection, but the tool does not disclose that DELETE is destructive, what happens on success or failure, whether authentication is required, or any side effects. The transparency is minimal.

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?

The description is very short and front-loaded with the core action, containing no fluff or repetition. However, it is so terse that it sacrifices useful context, resembling under-specification rather than deliberate efficient structuring.

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 three parameters, nested objects, no output schema, and no annotations, the description is insufficient for an agent to invoke the tool with confidence. It lacks parameter semantics, return-value expectations, error behavior, and clearer auth or safety guidance. The word 'guarded' raises more questions than it answers.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate for the three parameters. It does not explain the path format, how headers should be structured, or what payload is expected. The only implicit clue is 'against API_BASE', which suggests path is relative to a base URL, but headers and payload remain completely unexplained.

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 a specific verb ('DELETE') and a resource scope ('API_BASE'), and the word 'Generic' indicates it is a general-purpose delete wrapper. It is distinguishable from siblings like api_get, api_post, api_put, and api_probe by the HTTP method, so an agent can infer what this tool does.

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 phrase 'Generic DELETE' implies the tool is for performing HTTP DELETE requests against the base API, which gives some usage context relative to the sibling method-based tools. However, there is no explicit guidance on when not to use it, no mention of alternatives by name, and no conditions or prerequisites beyond the vague 'guarded'.

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

api_getB

Generic GET against API_BASE (safe).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
queryNo
headersNo

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations present, the description carries the behavioral transparency burden. It adds only the claim '(safe)', which is useful for a GET-based tool, but it does not explain API_BASE resolution, response behavior, error handling, or whether authentication is required.

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 one compact sentence with no filler. 'Generic' and '(safe)' add useful meaning, though the overall brevity sacrifices informational richness.

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 three parameters, no output schema, no annotations, and zero schema description coverage, this description is far from complete. It never defines API_BASE, explains how path/query/headers are combined, or describes what the response looks like, leaving the agent to guess at important invocation details.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no direct guidance for 'path', 'query', or 'headers'. The phrase 'against API_BASE' weakly implies that path is relative to the base URL, but query and header semantics are left entirely to inference.

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 identifies a concrete operation: a generic GET against API_BASE, which distinguishes it from the method-specific siblings api_post, api_put, and api_delete. However, API_BASE is left undefined and the relationship to api_probe is not addressed, so the purpose is clear but not fully specified.

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 word 'Generic' implies this is the catch-all for raw GET requests, and '(safe)' suggests it is appropriate for read-only operations. Still, it provides no explicit guidance about when to use this tool versus api_probe, nor any exclusions or conditions.

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

api_postC

Generic POST against API_BASE (guarded).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
headersNo
payloadNo

TDQS

C2.6/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral disclosure burden. It only says 'guarded', which is too vague to convey auth requirements, side effects, idempotency, error behavior, or whether the call modifies data, and POST's mutation semantics are left implicit.

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?

The description is brief and front-loaded, stating the method and target in one sentence. However, the parenthetical 'guarded' is vague and its brevity comes at the expense of missing details that other dimensions need.

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 3-parameter generic HTTP tool with no annotations and no output schema, the description leaves path construction, headers/payload semantics, response handling, and the meaning of 'guarded' unspecified. It gives the agent only enough to know that a POST request is made.

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

Parameters2/5

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

Schema description coverage is 0% and the description does not compensate. 'Against API_BASE' hints that 'path' is relative to the base URL, but headers and payload are entirely unexplained in both the schema and description, forcing the agent to rely on HTTP conventions.

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 identifies a concrete operation—sending a POST request to API_BASE—and the HTTP verb distinguishes it from the GET/PUT/DELETE siblings at a basic level. However, it remains generic and doesn't specify the kind of resource or action POST is used for beyond the method itself.

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?

There is no explicit guidance about when to use this tool versus api_get, api_put, api_delete, or api_probe. The verb 'POST' implies use for POST-style requests, but no context, prerequisites, or exclusions are provided.

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

api_probeC

Probe an API path with any method (safe).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
methodNoGET
headersNo
max_bytesNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral disclosure burden, but the only behavioral claim is the vague word 'safe'. It does not clarify whether arbitrary methods can still cause mutations, what the response looks like, how max_bytes affects the response, authentication requirements, or error behavior.

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, front-loaded sentence with no filler. Every phrase carries meaning, but it is so brief that it sacrifices critical behavioral and parameter context.

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 no annotations, no output schema, and four parameters, the description is too thin. It omits return semantics, the meaning of 'safe', response size behavior, header usage, and explicit guidance for choosing between this and sibling tools. An agent could select the tool but would not know what to expect from calling it.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only adds minimal meaning: 'path' is an API path and 'method' can be anything. The headers and max_bytes parameters are completely unexplained, leaving the agent to guess their purpose and interaction with the request.

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 identifies a specific action ('Probe') and resource ('API path') and stresses that any HTTP method is accepted. The 'any method' qualifier distinguishes it from the fixed-method sibling tools (api_get, api_post, etc.), though 'probe' is somewhat generic and does not fully define the operation's outcome.

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 phrase 'with any method (safe)' implies this tool is for flexible or non-standard HTTP method probing, contrasting with the specific method siblings. However, it never explicitly states when to prefer this over api_get/api_post/etc., nor does it mention exclusions or caveats for potentially destructive methods.

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

api_putC

Generic PUT against API_BASE (guarded).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes
headersNo
payloadNo

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden, but 'guarded' is the only behavioral hint and it is not explained. The description does not disclose side effects, idempotency, error behavior, or what the guard protects against. This is insufficient for a mutating operation.

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?

The description is compact and front-loaded with the operation, but the words 'generic' and 'guarded' add little concrete meaning. It is concise but under-specified, so the brevity does not meaningfully support correct invocation.

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

Completeness1/5

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

The tool has three parameters, no annotations, no output schema, and zero parameter coverage, yet the description only states that it is a generic PUT to API_BASE. Essential context about path construction, payload expectations, header behavior, and return values is missing. The description is far from complete for safe invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description provides no information about path, headers, or payload. An agent must infer parameter semantics solely from the property names in the schema. The description adds no value beyond the 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?

The description states a clear operation: a generic PUT request against API_BASE. It distinguishes itself from siblings (api_get, api_post, api_delete, api_probe) by the HTTP method. The qualifiers 'generic' and 'guarded' add some ambiguity but do not obscure the core purpose.

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 given on when to use this tool versus the sibling HTTP-method tools. The description relies entirely on the name and method to imply suitability for update operations. It does not state prerequisites, alternatives, or conditions where another tool should be chosen.

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

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

TDQS

B3.2/5.0
Disambiguation4/5

The five tools map cleanly to distinct HTTP operations (probe, GET, POST, PUT, DELETE), so an agent can generally tell them apart. The only mild overlap is api_probe with any method potentially covering the same requests as the specific verb tools, but its 'safe probe' intent separates it clearly enough.

Naming Consistency5/5

All tools follow a consistent api_<verb> pattern, with lowercase snake_case throughout. The verbs are standard HTTP operations, making the naming predictable and easy to infer.

Tool Count5/5

Five tools is well-scoped for a generic API interaction server. Each tool covers a necessary HTTP operation without redundancy or bloat.

Completeness4/5

The common HTTP methods are covered, along with a safe probing option, which handles most API interaction needs. The surface has a minor gap: PATCH is missing, and the descriptions don't explicitly show how custom paths, headers, or bodies are specified.

Maintenance

ActivityMaintained
ResponsivenessSyncing

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

  • OpenAPI MCP Server

    luciVuc
    A
    license
    Not graded
    quality
    C
    maintenance
    A generic MCP server that dynamically converts OpenAPI-defined REST APIs into tools for LLMs like Claude. It supports multiple authentication methods and transport protocols, enabling seamless interaction with any OpenAPI-compliant API.
    21
    MIT

  • ControlAPI-MCP

    dili414
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that dynamically converts any OpenAPI or REST API into MCP tools, allowing for real-time server switching and schema reloading. It supports variable substitution for headers and bodies, enabling seamless authentication and interaction with multiple API environments.
    MIT

  • OpenAPI MCP Server

    cloudwarriors-ai
    A
    license
    A
    quality
    D
    maintenance
    A generic MCP server that dynamically exposes any OpenAPI-documented REST API to LLMs by auto-discovering endpoints. It provides tools for exploring API capabilities and making authenticated requests directly through natural language interfaces.
    2
    14
    MIT

  • REST API MCP Server

    nifetency
    A
    license
    Not graded
    quality
    D
    maintenance
    A dynamic MCP server that automatically discovers and generates tools from any REST API using OpenAPI/Swagger specifications, enabling instant endpoint access with zero manual configuration.
    MIT

Appeared in Searches

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/ghively/API2MCP-creator'

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