Skip to main content
Glama
v01dst

mcp-forge

by v01dst
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mcp-forge

Turn any docs URL into lean, callable MCP tools. No more pasting 1M-token API dumps into context.

Install

npx mcp-forge

Requires Node >= 20.

Related MCP server: openapi-to-mcp

Claude config

Add to your Claude Desktop / Claude Code MCP config:

{
  "mcpServers": {
    "forge": {
      "command": "node",
      "args": ["dist/index.js"]
    }
  }
}

If installed globally, point args at your install path (e.g. /path/to/mcp-forge/dist/index.js). Then restart Claude.

30-sec demo

Point Forge at an OpenAPI URL, list what it forged, then call one:

forge_add({ "sourceUrl": "https://petstore3.swagger.io/api/v3/openapi.json" })
// -> { "tools": ["listPets", "getPetById", ...] }

forge_list()
// -> [{ "name": "listPets", "tokens": 312 }, ...]

forge_call({ "toolName": "getPetById", "args": { "petId": 1 } })
// -> { "status": 200, "body": "{...}", "truncated": false }

Works with OpenAPI / Swagger JSON, llms.txt, and plain HTML docs pages. Forged tools are saved to a local store and executed with timeout + truncation guards.

Why: token table

Blog-era bloat vs. forged tools (per widely cited ecosystem reports — your mileage varies by API):

Source

Tokens in context

Forge (per forged tool)

< 3K

GitHub API surface

~45K

Cloudflare API surface

~1.17M

Forge fetches the docs once, extracts lean tool definitions (method + path + args), and only the small definition enters context — never the full spec.

Token figures cite known ecosystem reports about MCP server token costs, not benchmarks run by this repo. No fake claims: measure your own API before quoting numbers.

Security notes

  • SSRF block: private/loopback/link-local hosts and non-http(s) schemes are rejected before fetch.

  • 15s timeout: both docs fetch and forged-tool execution abort after 15 seconds (AbortController).

  • 10KB truncate: execution response bodies are cut at 10,240 chars with truncated: true — context never fills with a giant dump.

  • No secrets stored: the local store holds only tool definitions (name, method, path, source URL). No API keys, tokens, or response bodies are persisted.

License

MIT.

Available Tools

3 tools
forge_addA

Fetch a docs URL (OpenAPI / llms.txt / HTML) and forge lean callable tools from it. Returns {tools: names}.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceUrlYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It tells the agent the tool fetches a remote docs URL, supports OpenAPI/llms.txt/HTML, creates tools, and returns names. However, it does not clarify whether this is a persistent mutation, whether authentication is required, or how failures are surfaced.

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 one compact sentence that front-loads the action and return value. There is no filler or redundant restatement of the tool name.

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 one-parameter tool with no output schema and no annotations, the description covers the input format, the core operation, and the return shape. It could additionally mention how the created tools relate to forge_call/forge_list or describe side effects, but the essential invocation contract is present.

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

Parameters4/5

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

The schema provides only a URI field with no description, so the description must add semantic value. It does by identifying sourceUrl as a docs URL in OpenAPI, llms.txt, or HTML format, which materially helps the agent choose a valid input. For a single-parameter tool, this is adequate.

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 action and resource: fetch a docs URL and create callable tools from it, and it notes the return shape. It distinguishes itself as a creation/registration tool versus the sibling list/call tools, though it does not name the siblings explicitly.

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 explicit guidance on when to use this tool versus forge_list or forge_call, and no prerequisites or exclusions are given. The intended usage is only implied by the verb 'forge' and the tool name, leaving the agent to infer selection context.

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

forge_callB

Call a forged tool by name with args. Loads tool JSON from store then executes with timeout + truncation.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNo
toolNameYes

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden, and it does add real behavioral traits: a store lookup precedes execution, and timeout + truncation are applied. However, it does not quantify the timeout/truncation, describe error behavior when the tool is missing, or warn that the executed tool's side effects are unknown to the agent. The disclosure is meaningful but incomplete.

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?

Two short sentences with the action front-loaded before the mechanism; there is no filler or redundancy. Every clause earns its place, though the behavioral specifics could be expanded without hurting structure.

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 dynamic dispatch tool with nested args, no output schema, and no annotations, the description omits several things an agent needs: return format, error/not-found behavior, the prerequisite that the tool must exist in the store, and the fact that args are validated against the target tool's schema. The mechanism is sketched, but the call contract is incomplete.

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 maps 'by name' to toolName and 'with args' to args. It never explains that args must conform to the target tool's schema or that toolName must reference a tool already in the store. This leaves the agent guessing about how to construct a valid invocation.

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 specific verb+resource: 'Call a forged tool by name with args,' which clearly identifies this as the dispatcher in the forged-tool trio and contrasts with the sibling add/list operations. The mechanism clause ('loads tool JSON from store') adds further specificity. However, it never explicitly names the siblings, so differentiation is left to inference from the tool-name set.

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?

No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The clause 'loads tool JSON from store' implies the tool must already be registered (via forge_add), which is useful only as implied usage context. An explicit note about prerequisite registration and listing available tools via forge_list would make this actionable.

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

forge_listA

List forged tools in the local store.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are present, so the description carries the behavioral disclosure burden. 'List' clearly signals a read-only operation against the local store, which is sufficient for a parameterless tool with no evident 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?

One short sentence with no filler. The action and scope are front-loaded, making the tool's purpose immediately clear.

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 parameterless read-only list operation, the description covers the essential use case. It does not describe the return format or ordering, but 'List...tools' strongly implies the output, and there is no output schema to provide additional structure.

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

Parameters4/5

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

The tool has zero parameters, so the schema is already complete and the description has nothing to add. This matches the baseline for parameterless tools.

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 states exactly what the tool does: list forged tools in the local store. The sibling names forge_add and forge_call make the distinction obvious, so an agent can identify this as the read-only enumeration tool without ambiguity.

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?

No explicit when-to-use guidance or mention of alternatives, but the verb 'List' plus the sibling names add/call makes the intended use clear by implication. It does not say when not to use it, such as when creating or invoking a forged tool.

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. 3 tool updatesv0.1.0
    • First observedforge_add
    • First observedforge_call
    • First observedforge_list
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct role: forge_add creates tools from a URL, forge_list enumerates them, and forge_call executes them. There is no overlap or ambiguity between the three operations.

Naming Consistency5/5

All tools share the forge_ prefix followed by a lowercase imperative verb: add, list, call. The naming is completely consistent and predictable.

Tool Count5/5

Three tools is appropriate for this focused server's scope: one to create tools, one to list them, and one to call them. Each tool earns its place and no extra tool is needed for the core workflow.

Completeness4/5

The add/list/call workflow covers the essential lifecycle of dynamically forged tools. However, there is no delete or refresh operation, so stale or outdated forged tools cannot be removed.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • openapi-to-mcp

    The-Swarm-Corporation
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables MCP clients to call any OpenAPI-defined API by automatically converting its operations into tools, with built-in support for authentication, rate limiting, and response handling.
    7
    Apache 2.0

  • agentmd-mcp

    djrobson5
    A
    license
    A
    quality
    A
    maintenance
    Convert PDF, DOCX, HTML, and URLs into clean, LLM-ready markdown with tables preserved and boilerplate stripped, through three MCP tools (URL, local file, or raw bytes). Hosted API with no local dependencies; 50 free conversions with a self-serve key, then $0.002 per call.
    3
    30 npm
    MIT