Skip to main content
Glama
Sign In
mcp-api-translator

mcp-api-translator

by krishgok
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Extend an existing generated MCP server

extend_mcp_server

Append operations from another OpenAPI or Postman spec to an existing generated MCP server, skipping duplicates and preserving hand-edited files so multiple APIs can be aggregated into one server.

Instructions

Append the operations from another spec to an already-generated project (identified by its .mcp-translator.json manifest). Idempotent: operations already present are skipped, and hand-edited tool files are preserved unless force is set. Enables aggregating multiple APIs into one MCP server.

Input Schema

NameRequiredDescriptionDefault
authNoAuth to use when the spec declares no security schemes of its own. Applied only to operations whose own security list is empty; credentials are read from env vars as usual.
specNoInline spec text (OpenAPI or Postman; JSON or YAML).
forceNoOverwrite existing tool files of the same name.
formatNoForce a format; defaults to auto-detect.
methodsNoKeep only these HTTP methods, e.g. [GET, POST].
pathGlobNoKeep only matching paths, e.g. "/v1/**".
specPathNoPath to a local spec file (JSON or YAML).
projectDirYesPath to an existing generated project.
includeTagsNoKeep only operations with these tags.
toolCatalogNoAlso write tool-catalog.json; defaults to refreshing it if the project has one.
excludeOperationsNoDrop operations by operationId, tool name, or tag.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses idempotency, that already-present operations are skipped, and that hand-edited tool files are preserved unless force is set. It omits the return/report shape and any permission or failure behavior, but the core mutation semantics are unusually well covered.

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?

Three sentences, front-loaded with the action and precondition, then the idempotency guarantees. The final sentence is mild rationale but is short and doubles as usage context, so nothing is wasted.

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 an 11-parameter mutation tool with no annotations and no output schema, the description covers purpose, preconditions, and the key destructive/preservation behavior. It stops short of describing what the call returns or how partial failures are reported, which is the main remaining gap.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying projectDir to the .mcp-translator.json manifest and clarifying that force overwrites hand-edited files specifically, which the schema's generic 'Overwrite existing tool files' does not convey.

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?

States a specific verb (append) and resource (operations from another spec) and scopes it to 'an already-generated project (identified by its .mcp-translator.json manifest)', which cleanly separates it from the sibling generate_mcp_server that creates new projects.

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 closing sentence 'Enables aggregating multiple APIs into one MCP server' implies the intended scenario, and the existing-project precondition is stated. However, no alternative is named and no when-not condition is given (e.g. 'use generate_mcp_server for a fresh project'), so usage must be inferred.

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

Deploy Server

Other Tools