Skip to main content
Glama

import_api_spec

Import an OpenAPI 3.x document (as JSON), a Postman v2.x collection (JSON) or a curl command into a new collection, or into collection_id. All or nothing, and plan limits are checked first. Credentials are never imported (they become variables). Convert YAML to JSON before sending.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "format": "<format>",
      "content": "<content>"
    },
    "name": "import_api_spec"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoName for the new collection.
formatYesWhat `content` is: an OpenAPI 3.x document, a Postman v2.x collection, a HAR file or a curl command.
contentYesThe document (object or JSON string), or the curl command, e.g. curl -X POST https://api.example.com/v1/charges.
collection_idNoAdd to this collection instead of creating one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / content / description
      Previous value: -"The document (object or JSON string), or the curl command."New value: +"The document (object or JSON string), or the curl command, e.g. curl -X POST https://api.example.com/v1/charges."
    • addedInput schema / properties / content / type
      Added value: +[
      +  "object",
      +  "string"
      +]
    • addedInput schema / properties / format / description
      Added value: +"What `content` is: an OpenAPI 3.x document, a Postman v2.x collection, a HAR file or a curl command."
  2. Changed1 schema field changed
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "openapi",
      -  "postman",
      -  "curl"
      -]New value: +[
      +  "openapi",
      +  "postman",
      +  "har",
      +  "curl"
      +]
  3. Added

TDQS

A4/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing atomicity semantics ("All or nothing"), the plan-limit precheck, and that credentials are stripped and become variables. What it does not disclose is the result of the call (no output schema exists), e.g. whether the new collection id is returned.

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?

Three tight sentences, front-loaded with what is imported and where it goes, followed by the behavioral guarantees and the YAML caveat. No filler and every clause carries information.

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?

Covers formats, destination, atomicity, limits and credential handling for a 4-parameter mutation tool with full schema coverage. The remaining gap is the absence of any statement about what is returned, which matters given there is no output schema.

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

Parameters3/5

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 `name`, `format`, `content` and `collection_id` with examples and an enum. The description adds only marginal framing (that `collection_id` means append instead of create) and does not compensate with format-specific content requirements.

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?

States a specific verb (import) plus the three accepted source formats and the two destinations (new collection or `collection_id`). An agent can tell it apart from `create_api_collection` by the fact that it ingests a spec document rather than building one, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real preconditions: convert YAML to JSON first, plan limits are checked before import, and everything is all-or-nothing. The `collection_id` sentence implicitly frames the create-vs-append choice, but no explicit alternative tool is named for related tasks like exporting.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.