What can you do with this server?

This server is an OpenAPI MCP Gateway exposing the Petstore API as MCP tools, allowing you to manage pets, store orders, and user accounts. Pet Management * Add, update, or delete pets * Find pets by status (available, pending, sold) or by tags * Retrieve a specific pet by ID * Update a pet via form data or upload a pet image Store / Order Management * Retrieve inventory by status * Place, retrieve, or delete purchase orders User Management * Create single or multiple user accounts * Log users in and out * Fetch, update, or delete user accounts by username Gateway Features * Authentication: Supports bearer tokens, API keys, and OAuth2 (authorization code & client credentials) * Flexible Exposure: Exposes API operations as individual tools (static) or meta-tools (dynamic) for large APIs; promotes eligible read-only GET operations to MCP resources * Customization: Override default tool names, descriptions, and resource settings without modifying the original OpenAPI spec * FastAPI Integration: Seamlessly exposes routes from existing FastAPI applications as MCP tools * Multiple Transports: Supports streamable-http, sse, and stdio

Which integrations are available for this server?

Allows interaction with Asana's API, enabling management of tasks, projects, workspaces, and other Asana resources. Allows interaction with GitHub's REST API, enabling management of repositories, issues, pull requests, and other GitHub resources.

How do I use OpenAPI MCP Gateway?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenAPI MCP Gateway mount Petstore API from https://petstore3.swagger.io/api/v3/openapi.json" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

OpenAPI MCP Gateway

by mroops0111

Overview Schema Related Servers Score Discussions

Python

Hybrid

OpenAPI MCP Gateway

PyPI version PyPI Downloads Python Version License: MIT

Mount any OpenAPI (Swagger) spec as a Model Context Protocol (MCP) server, or expose an existing FastAPI app the same way. Multiple APIs in one process, each with its own mount path and auth.

uvx openapi-mcp-gateway --spec https://petstore3.swagger.io/api/v3/openapi.json
# Server live at http://127.0.0.1:8000/api/mcp

Multi-Spec, Multi-Auth. Mount GitHub, an OAuth2 SaaS, and your internal API side by side, each with its own auth and token namespace.
Spec-Compliant Authorization. The gateway runs its own OAuth server and mints audience-bound upstream tokens, so the MCP client's credential is never replayed against a third party.
Tool Shaping. Rename ugly operationIds, hide knobs the model should never touch, and rewrite requests and responses with JSONata, all in YAML with no fork required.
Dynamic Exposure. Front a 1,200-operation spec with three list → get → call meta-tools, so connecting to it does not spend the LLM's whole context window on tool schemas.
Resources, Not Just Tools. Eligible read-only GETs register as MCP resources instead, addressable by URI and surfaced by the client rather than guessed at by the model.
FastAPI-Native. Decorate routes with @mcp_tool to expose them in-process over ASGI, no extra hop and no second spec to maintain.

Installation

uv add openapi-mcp-gateway
uv add "openapi-mcp-gateway[redis]"   # optional, Redis token store for multi-replica OAuth

Requires Python 3.11+. To skip the install entirely, uvx openapi-mcp-gateway runs the published package directly.

Related MCP server: FastMCP OpenAPI

Quick Start

Every example below uses uv run, which assumes the install above.

1. Public API, No Auth

uv run openapi-mcp-gateway --spec https://petstore3.swagger.io/api/v3/openapi.json --name petstore

Connect an MCP client to http://127.0.0.1:8000/petstore/mcp.

2. Bearer Token or API Key

export GITHUB_TOKEN="ghp_..."
uv run openapi-mcp-gateway \
    --spec https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json \
    --name github \
    --auth-type bearer \
    --auth-token '${GITHUB_TOKEN}'

Use a config file so the header name is explicit:

servers:
  - name: petstore
    spec: https://petstore3.swagger.io/api/v3/openapi.json
    auth:
      type: api_key
      token: ${PETSTORE_API_KEY}
      api_key_header: api_key

3. OAuth2

Rather than asking you to paste an upstream token into config, the gateway obtains one per caller. authorization_code runs the gateway as the authorization server and mints each end-user their own upstream token. client_credentials shares a single service token across every client. token_exchange hands issuance to an identity provider you already run. See Authorization for how each pairs a check on the MCP endpoint with a credential for the API.

export ASANA_CLIENT_ID="..." ASANA_CLIENT_SECRET="..."
uv run openapi-mcp-gateway \
    --spec https://raw.githubusercontent.com/Asana/openapi/master/defs/asana_oas.yaml \
    --name asana \
    --auth-type oauth2 \
    --auth-client-id '${ASANA_CLIENT_ID}' \
    --auth-client-secret '${ASANA_CLIENT_SECRET}' \
    --auth-upstream-scopes "openid,email,profile,users:read,workspaces:read"

For the service-token flow, add --auth-flow client_credentials. Those two are what the CLI reaches. token_exchange needs an issuer and an audience, so it is configured per server under auth: in YAML, described in Authorization.

4. Multiple APIs at Once

Mix public, bearer, and OAuth2 services in a single config. Each server is mounted at /{name}/mcp:

# servers.yml
url: http://127.0.0.1:8000   # public base URL for OAuth callbacks

servers:
  # Resource auto-promotion: eligible GETs become MCP resources, the rest stay tools.
  - name: petstore
    spec: https://petstore3.swagger.io/api/v3/openapi.json
    base_url: https://petstore.swagger.io/v2
    exposure:
      promote_resources: true

  # Dynamic exposure: ~1,200 GitHub ops behind three meta-tools instead of 1,200 tool schemas.
  - name: github
    spec: https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json
    exposure:
      style: dynamic
    auth:
      type: bearer
      token: ${GITHUB_TOKEN}

  # Per-user OAuth2 with audience-bound tokens, no passthrough.
  - name: asana
    spec: https://raw.githubusercontent.com/Asana/openapi/master/defs/asana_oas.yaml
    auth:
      type: oauth2
      upstream:
        client_id: ${ASANA_CLIENT_ID}
        client_secret: ${ASANA_CLIENT_SECRET}
        scopes: [openid, email, profile, users:read, workspaces:read]

That one file serves 13 tools with 3 concrete resources and 3 resource templates at /petstore/mcp, three meta-tools fronting ~1,200 endpoints at /github/mcp, and per-user OAuth2 against Asana's IdP at /asana/mcp. No spec edits anywhere. Run it with uv run openapi-mcp-gateway --config servers.yml.

5. Local Desktop Client (stdio)

For Claude Desktop, IDE integrations, or any MCP client that prefers stdio:

{
  "mcpServers": {
    "petstore": {
      "command": "uvx",
      "args": [
        "openapi-mcp-gateway",
        "--spec", "/abs/path/to/openapi.json",
        "--transport", "stdio"
      ]
    }
  }
}

More Examples

Runnable configs for every scenario above live in examples/, each with its prerequisites documented at the top.

Authorization

Every request crosses two boundaries, and one auth: block settles both of them. One is who may call the MCP endpoint, the other is what credential reaches the API behind it. Setting auth.type, plus auth.flow under oauth2, picks a pairing of the two. Everything the gateway sends upstream lives under auth.upstream, so the indentation separates the two directions.

`auth.type` / `auth.flow`	MCP Endpoint	Credential Sent Upstream
`none`	open	none
`bearer`, `api_key`	open	a fixed one from config, shared by every caller
`passthrough`	open	the caller's own header, forwarded unchanged
`oauth2` + `client_credentials`	open	one service token, shared by every caller
`oauth2` + `authorization_code`	the gateway is the authorization server	a per-user token the gateway obtained on their behalf
`oauth2` + `token_exchange`	an external issuer is the authorization server	a per-user token exchanged from the caller's

Only the last two put a check in front of the MCP endpoint. The others suit a gateway on localhost or inside a private network, and leave it open to anyone who can reach the port.

token_exchange verifies JWT signatures, so it needs the oidc extra. Run the gateway as uvx --from "openapi-mcp-gateway[oidc]" openapi-mcp-gateway. Without it the gateway refuses to start and says so.

The MCP spec requires a server to accept only tokens minted for itself, and forbids relaying one to an upstream API. So under both protected flows the upstream is reached with a second, separately obtained credential rather than the one the caller presented. See Access Token Privilege Restriction.

passthrough is the one exception, and it exists for the FastAPI integration, where the gateway runs in-process as part of the app it exposes. There is no separate upstream to be confused about. Setting it against a genuinely separate API is the confused-deputy pattern the spec forbids, which is why nothing selects it automatically.

An API with no authorization server of its own, which accepts tokens from a provider the deployment already runs, needs the gateway to say which API its upstream token is for. Point the OAuth URLs at that provider and name the API:

servers:
  - name: internal
    spec: https://internal.example.com/openapi.json
    auth:
      type: oauth2
      flow: authorization_code
      upstream:
        authorization_url: https://you.auth0.com/authorize
        token_url: https://you.auth0.com/oauth/token
        client_id: ${GATEWAY_CLIENT_ID}
        client_secret: ${GATEWAY_CLIENT_SECRET}
        audience: https://internal.example.com

Without it the provider mints for its own default audience and the API refuses the result. The parameter rides on the authorization request and on every token request, refreshes included, so a rotated token stays usable.

Authorization servers disagree on the spelling. upstream.audience is what Auth0 expects, upstream.resource is the RFC 8707 parameter.

Set the one yours reads, or set both. A server that does not recognise a parameter ignores it silently rather than refusing, so Keycloak given only upstream.resource returns a perfectly ordinary token whose audience is wrong, and the upstream then rejects it for reasons that look unrelated. Sending both is legal, since RFC 8707 §2.1 defines both names, and it is the portable choice.

MCP clients still authorize against the gateway and receive a gateway-issued token, while the provider-issued one is a second credential held on their behalf. End users see whatever login the provider federates to, so this works on any plan and needs nothing of the upstream but that it accept what the provider issues.

The Auth0 Management API is a worked example of exactly this shape, since its own audience differs from the tenant that issues for it. See examples/auth0-management.yml.

authorization_code leaves the gateway issuing credentials of its own, so revoking someone at the provider has no effect until the gateway's token expires. token_exchange removes that second issuer. The provider mints tokens for the MCP endpoint directly, the gateway validates them, and each call exchanges one under RFC 8693 for a second token naming the upstream:

servers:
  - name: internal
    spec: https://internal.example.com/openapi.json
    auth:
      type: oauth2
      flow: token_exchange
      issuer: https://auth.example.com/realms/internal
      upstream:
        audience: https://internal.example.com
        client_id: ${GATEWAY_CLIENT_ID}
        client_secret: ${GATEWAY_CLIENT_SECRET}

The gateway serves no /authorize or /token here. Its protected resource metadata names the issuer, clients authorize there, and the JWKS comes from the issuer's own metadata so key rotation needs no restart.

The endpoint identifies itself as {url}{mount_path}/mcp, built from the gateway's url and the server's mount path, so the example above is https://gw.example.com/internal/mcp. That exact string is what an inbound token's aud must contain, so you need it when creating the matching client and audience mapping at the issuer.

Two things to check before committing to this mode. Token exchange support varies:

Authorization Server	Token Exchange
Keycloak	generally available, enabled by default
authentik	2026.8 and later
Zitadel	can only narrow an audience the token already carries
Auth0	Custom Token Exchange, on Professional and Enterprise plans, with an Action to write
Logto	not implemented

Keycloak is generally available in the sense that the feature flag is on, but a working realm still needs three things that its documentation does not connect to this use case:

The inbound aud comes from an audience mapper, added to a client scope. Keycloak ignores resource and audience on the authorization and token endpoints, so without a mapper the token's audience is just account and the gateway rejects it.
The client performing the exchange must itself be in the subject token's audience, or the exchange fails with access_denied: Client is not within the token audience. The tidiest arrangement is to make the MCP endpoint a client whose clientId is its canonical URI, so it is both the audience target and the exchanging client.
The exchange target must exist as a client and be reachable from the exchanging client's scopes, or the exchange fails with invalid_request: Requested audience not available.

And because the issuer is the authorization server for this endpoint, MCP clients register there rather than with the gateway. Check whether yours supports dynamic client registration, or whether each client needs pre-registering. If it does support it, set required_scopes so the advertised scopes_supported tells a registering client what to ask for. Leave it empty and a client may register with a minimal scope set whose tokens then carry neither the audience nor the claims the upstream needs.

Under authorization_code the gateway's own access token lives 1 hour and its refresh token 24 hours. Each refresh issues a fresh refresh token, so the refresh TTL is the practical re-authorization cadence. A client refreshing within it never signs in again, while one idle past it must re-authorize. Tune both with auth.mcp_access_token_ttl and auth.mcp_refresh_token_ttl.

token_exchange mints nothing, so neither applies. Lifetimes are the issuer's to set.

Tool Results

Every registered tool carries a protocol-native title and annotations (readOnlyHint, destructiveHint, idempotentHint), so an agent can judge a tool before calling it. Results carry structuredContent, so a client reads a typed body and structured error payloads without re-parsing text. None of this needs configuration.

Configuration

Run uv run openapi-mcp-gateway --help for the CLI reference. The Quick Start covers most setups, and the full field reference is below.

Configuration merges in this order, with each layer overriding the previous one. Defaults → YAML (--config) → CLI flags → Gateway.run(...) kwargs. A layer only overrides the fields it actually sets, so --log-level=DEBUG won't reset logging.format from your YAML. Nested objects like logging and per-server auth merge field-by-field. The servers list is the exception, replaced wholesale rather than merged entry-by-entry.

${ENV_VAR} and ${ENV_VAR:-default} work in any string field, resolved at request time. An unrecognised key is refused at startup rather than ignored, so a typo in a field that narrows access fails closed. For OAuth2, authorizationUrl / tokenUrl / scopes are auto-detected from the spec's securitySchemes, and the auth.* fields below override them when the spec is incomplete.

Field	Type	Default	Description
`host`	string	`0.0.0.0`	Bind address (`0.0.0.0` = all interfaces). Clients on the same machine usually open `http://localhost:{port}` or `http://127.0.0.1:{port}`.
`port`	int	`8000`	Bind port
`url`	string	(empty)	Public base URL for OAuth redirects and discovery. When unset: `http://localhost:{port}` if `host` is `0.0.0.0`, otherwise `http://{host}:{port}`. Override when your registered redirect URI uses another host (tunnel, reverse proxy, etc.).
`transport`	string	`streamable-http`	`streamable-http`, `stdio`, or `sse` (deprecated)
`store.type`	string	`memory`	`memory` or `redis`. Redis shares OAuth credential state across replicas. It holds OAuth tokens and client registrations, never MCP protocol sessions, so single-replica or non-OAuth deployments can stay on `memory`.
`store.redis_url`	string	`redis://localhost:6379`	Redis URL when `store.type: redis`
`logging.level`	string	`INFO`	`DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL`
`logging.format`	string	`text`	`text` or `json`
`logging.file`	string		Mirror logs to this file
`servers`	list	required	List of per-server config entries

Field	Type	Default	Description
`name`	string	required	Unique identifier. Mount path defaults to `/{name}`
`spec`	string	required	Path or URL to OpenAPI document (JSON or YAML)
`base_url`	string	from spec	Override the upstream base URL
`auth.type`	string	`none`	`none`, `bearer`, `api_key`, `oauth2`, or `passthrough`. Says where the upstream credential comes from: a fixed one, one the gateway obtains, or the caller's own forwarded
`auth.token`	string		Required for `bearer` / `api_key`
`auth.api_key_header`	string	`X-API-Key`	Header name for `api_key`
`auth.flow`	string	from spec	`authorization_code` for per-user delegation, `client_credentials` for a shared service token, `token_exchange` to delegate this endpoint's authorization to an external issuer. When unset the gateway prefers the spec's declared `authorizationCode` flow, falling back to whatever else it declares.
`auth.issuer`	string		Required for `token_exchange`. The authorization server that mints tokens for this MCP endpoint
`auth.required_scopes`	list		For `token_exchange`, what an inbound token must already carry. Advertised as `scopes_supported`, so a client doing dynamic registration knows what to ask for
`auth.upstream.client_id`, `auth.upstream.client_secret`	string		Required for `oauth2`. The gateway's own credential at the upstream authorization server
`auth.upstream.scopes`, `auth.upstream.authorization_url`, `auth.upstream.token_url`		from spec	What the gateway requests from the upstream authorization server, and where. The URLs override an incomplete `securitySchemes`
`auth.upstream.resource`, `auth.upstream.audience`	string		Names the API the upstream token is for, when the API and its authorization server are different parties. `resource` is the RFC 8707 parameter, `audience` is the spelling Auth0 uses. Only what you set is sent
`auth.mcp_access_token_ttl`	int	`3600`	Lifetime in seconds of the MCP access token the gateway mints for `authorization_code`
`auth.mcp_refresh_token_ttl`	int	`86400`	Lifetime in seconds of the MCP refresh token. This is the practical re-authorization cadence, since each refresh slides the window forward
`policy.allow`	list		Only expose matching operations
`policy.deny`	list		Exclude matching operations
`timeout`	float	`90`	HTTP timeout in seconds
`exposure`	string	`static`	`static` registers one MCP tool per operation. `dynamic` registers three meta-tools (`list_operations`, `get_operation`, `call_operation`) for the LLM to walk on demand.
`mode`	string	`tool_only`	`tool_only` forces every operation to a tool and ignores any `resource` declaration. `auto` promotes eligible GETs (no required non-path parameter) to MCP resources, and spec-side `resource` opt-ins still apply as explicit overrides.
`operations`	map	`{}`	YAML-side `x-mcp-integration` overrides, keyed by `operationId`. Fully replaces (does not merge) the spec-side `x-mcp-integration` on that operation. Useful when you do not control the upstream spec.

Filtering Operations

Use policy.allow and policy.deny with fnmatch syntax against operation IDs (getUsers, create*) or method + path (GET /users/*).

policy:
  allow: ["GET /repos/*"]
  deny:  ["GET /repos/*/actions/secrets*"]

Operations can also be opted in from the spec side with x-mcp-integration: {tool: {}} plus policy.annotated_only: true. Filters apply in the order annotated_only, then allow, then deny.

Resource Exposure

Read-only GET operations are a better fit for the MCP resource primitive than for a tool. Tools are model-controlled, so the LLM decides when to call one. Resources are application-controlled, surfaced by the client or picked by the user. A GET that is fully identified by its URL is a thing that exists at an address, which is what a URI is for.

Set exposure.promote_resources: true and every eligible GET promotes automatically. Eligible means no required query, header, or body parameter. Required path parameters are fine and turn the operation into a resource template. Against the vanilla Petstore3 spec that yields 13 tools, 3 concrete resources, and 3 resource templates with zero spec edits.

Keeping those endpoints off the tool list also saves context, since most clients do not auto-load resources. Resource support is uneven across the ecosystem, though, and an agent framework that ignores resources entirely will not reach a promoted operation at all. Stay on the default mode: tool_only when that is your target.

To rename a resource, set a custom URI template, or set a non-JSON MIME type, use the operations map keyed by operationId:

servers:
  - name: petstore
    spec: https://petstore3.swagger.io/api/v3/openapi.json
    exposure:
      promote_resources: true
    operations:
      getPetById:
        resource:
          name: pet
          mime_type: application/json
      getInventory:
        resource:
          name: inventory

If you own the upstream spec, write the same opt-in inline instead:

paths:
  /pets/{petId}:
    get:
      operationId: getPet
      x-mcp-integration:
        resource:
          name: pet
          mime_type: application/json
          # uri_template: petstore://v2/pets/{petId}  # optional, must start with "<server>://"

Declaring both tool and resource registers the operation on both surfaces. Each entry fully replaces (does not merge with) the spec-side x-mcp-integration. A runnable demo lives at examples/petstore-override.yml.

An unknown operationId raises at startup so typos do not silently no-op. Resource declarations are validated there too, so non-GET methods, required non-path parameters, and uri_template values that do not start with <server>:// abort Gateway.from_config with a concrete error. Subscriptions are not implemented because REST has no native push.

Tool Shaping

A raw operation rarely makes a good tool. Its operationId is ugly (GitHub's actions/list-jobs-for-workflow-run-attempt), its description is empty (most of gists/*), it takes a cryptic filter DSL alongside a dozen knobs the model should never touch, and it wraps the few useful fields in a large envelope. x-mcp-integration.tool fixes all of that without forking the spec. name and description fix how the tool presents itself, while params, params_strategy, request, and response reshape the interface behind it.

servers:
  - name: github
    spec: https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json
    operations:
      pulls/list-files:
        tool:
          name: list_pull_request_files
          description: |
            List files changed in a pull request. Returns up to 3000 files,
            each with status (added / modified / removed), patch text, and
            line counts.

If you own the upstream spec, write the same block inline as x-mcp-integration.tool on the operation.

The input layer is declarative and the value transforms are JSONata expressions.

params and params_strategy shape what the model sees. Each params entry is a JSON Schema fragment (type, enum, default, description, format, minimum, items, and so on) plus two flags. required lifts the parameter into the schema's required list, and hidden removes a spec parameter from the surface. params_strategy is mandatory whenever params is set:

merge: tweaks the operation's existing parameters and keeps the rest visible, so declaring a parameter the spec does not define is an error.
replace: makes the declared entries the whole schema and drops every spec parameter, so it always needs a request to route the friendly arguments upstream.

operations:
  searchIssues:
    tool:
      params_strategy: merge
      params:
        internal_flag: { hidden: true }
        per_page: { default: 30 }
        sort: { description: "One of comments, created, updated." }

request and response transform the values. Both are optional and independent of each other. request builds the entire upstream request, and response reshapes a successful body before it reaches the client.

operations:
  searchIssues:
    tool:
      request: |
        $merge([$, { "per_page": 30, "state": "open" }])
      response: |
        [items.{ "title": title, "url": html_url }]

Routing: a key that names a path placeholder fills the path, and the rest become query parameters for a body-less method or the JSON body otherwise.
Passthrough: $merge([$, { ... }]) forwards the incoming arguments and overrides only the keys you name, as above.
Lists: wrapping a mapping in [ ... ] keeps the result an array even when a single item matches.
Errors: a broken expression is rejected at startup, and a runtime failure returns an isError result naming the side that broke.

For a full replace example, where the declared params are the entire surface and request maps a friendly enum onto the raw query with $lookup, see examples/movie-shaping.yml.

Dynamic Exposure

For APIs with hundreds of operations (GitHub, Stripe, etc.), registering each as its own tool can blow the LLM's context window before the agent does anything. Set exposure.style: dynamic and the client sees three meta-tools instead, which the LLM walks as list → get → call to discover and invoke operations on demand. It is per-server, so /github/mcp can run dynamic while /petstore/mcp runs static in the same process.

list_operations() returns [{name, description}, ...] for every operation on this server.
get_operation(name) returns one operation's JSON Schema for input arguments.
call_operation(name, arguments) invokes that operation against the upstream.

Auth, path templating, and per-operation request shape match static mode, so only the surfacing changes. See examples/github-dynamic.yml for a runnable config.

Logging

Configure via the logging.* YAML keys or via CLI flags (--log-level, --log-format, --log-file). -v and -q are shortcuts for DEBUG and WARNING. CLI flags override YAML field-by-field, following the precedence rule above.

Authoring Configs with AI

generate-config is a companion Claude Code skill that writes a config.yml from a plain-language request, deriving the operations, auth, and shaping for you. This repo doubles as its plugin marketplace:

/plugin marketplace add mroops0111/openapi-mcp-gateway
/plugin install openapi-mcp-gateway

/generate-config connect our GitHub so my assistant can manage issues

Python API

The gateway works as a library, either standalone or wrapped around an app you already run.

from openapi_mcp_gateway import Gateway

gateway = Gateway()
gateway.add_server(
    name="petstore",
    spec="https://petstore3.swagger.io/api/v3/openapi.json",
)
gateway.add_server(
    name="github",
    spec="./github-openapi.json",
    auth={"type": "bearer", "token": "${GITHUB_TOKEN}"},
    policy={"allow": ["GET /repos/*"]},
)
gateway.run(port=8000)

FastAPI Integration

If you already run FastAPI, decorate the routes you want exposed with @mcp_tool and the gateway picks them up. No second spec, no separate process, and no extra network hop, since calls go in-process through httpx.ASGITransport. Auth is auto-detected from the app's securitySchemes, and passing an explicit auth=AuthConfig(...) to Gateway.from_fastapi overrides it.

from fastapi import FastAPI
from openapi_mcp_gateway import Gateway, mcp_tool

app = FastAPI()

@app.get("/items/{item_id}")
@mcp_tool()
def read_item(item_id: int):
    return {"id": item_id}

@app.get("/internal/health")  # not decorated → not exposed
def health():
    return {"ok": True}

Gateway.from_fastapi(app, name="myapp").run()

Because the gateway runs in-process and routes through httpx.ASGITransport, gateway and upstream share the same OAuth audience, so the MCP client's Authorization header passes through verbatim (auth.type: passthrough, set automatically for this integration only). For client_credentials schemes the gateway mints upstream tokens from its own credentials instead.

Mounting into an Existing App

To serve MCP alongside your own routes, build a Gateway and mount it onto your app. mount attaches every MCP sub-app at its configured path and also registers the OAuth authorization-server and .well-known discovery routes those servers own, so an OAuth flow works end to end.

from fastapi import FastAPI
from openapi_mcp_gateway import Gateway, GatewayConfig, ServerConfig

app = FastAPI()

gateway = Gateway.from_config(
    GatewayConfig(
        url="https://your-app.example.com",  # public URL, used for discovery and redirect URLs
        servers=[ServerConfig(name="petstore", spec="petstore.json")],
    )
)
gateway.mount(app)  # mounts /petstore/mcp plus its OAuth and .well-known routes

Set GatewayConfig.url to the host app's public URL so discovery documents and OAuth redirect URLs point at the right origin. The upstream OAuth callback for a server named <server> is fixed at /<server>/auth/callback, so keep it clear of your app's own callback paths.

License

MIT

Available Tools

19 tools

add_petAdd a new pet to the store.D

Add a new pet to the store.

ParametersJSON Schema

Name	Required	Description
`id`	No
`name`	Yes
`tags`	No
`status`	No	pet status in the store
`category`	No
`photoUrls`	Yes

TDQS

D1.5/5.0

Behavior1/5

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

The description reveals no behavioral traits beyond the obvious write operation. Annotations only include openWorldHint, with no readOnlyHint or destructiveHint, so the description carries the full burden for disclosure. It does not mention permissions, side effects, or response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence but it merely repeats the title without adding value. It is under-specified rather than concise, lacking substantive content that would help an agent.

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?

With 6 parameters, nested objects, no output schema, and a sparse description, the tool is severely under-documented. The description completely fails to provide context about return values, error cases, or operational details.

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 only 17%, and the description adds no parameter meaning. It fails to clarify required fields, optional fields, or how values like status or photoUrls should be provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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 alternatives. There is no mention of scenarios, prerequisites, or distinctions from similar pet-related operations.

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

create_userCreate user.B

This can only be done by the logged in user.

ParametersJSON Schema

Name	Required	Description
`id`	No
`email`	No
`phone`	No
`lastName`	No
`password`	No
`username`	No
`firstName`	No
`userStatus`	No	User Status

TDQS

B3.1/5.0

Behavior3/5

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

The description reveals that authentication is required, which is a behavioral constraint beyond the openWorldHint annotation. However, it does not disclose what happens after creation, whether it's idempotent, or any side effects beyond the obvious user record creation. Given openWorldHint is set, there's potential for external interactions, but the description doesn't elaborate. So it adds some but not much.

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 a single, short sentence that is directly relevant to the tool's usage. There is no redundancy or wasted words, but it's extremely brief. For a tool with 8 parameters, this brevity might be seen as an under-specification rather than conciseness, as it doesn't even state the basic action.

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?

The tool has 8 optional parameters, no output schema, and only an openWorldHint annotation. The description provides only an authentication prerequisite. It lacks information about required credentials, what fields are needed, behavior on success/failure, differences from bulk creation, or any side effects. This is inadequate for an agent to decide when to invoke it.

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?

The input schema has 8 parameters with only 13% having descriptions, and the description provides no parameter information whatsoever. Since the schema coverage is low, the description should compensate, but it doesn't. All field semantics rely solely on names and examples, so the description adds no value here.

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 tool name and title clearly indicate it creates a user. The description, while not restating the action, adds a necessary constraint (logged-in requirement), and the action is distinct from sibling tools like update_user, delete_user, and create_users_with_list_input. This makes it easy for an agent to identify when this tool is the right one for creating a single user.

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 description states a clear prerequisite: only the logged-in user can perform this action. This tells the agent to use this tool only when there is a logged-in user, but it doesn't provide guidance on when to use create_user vs alternatives like create_users_with_list_input, which serves bulk creation, or update_user. So there's partial context but no comparative guidance.

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

create_users_with_list_inputCreates list of users with given input array.C

Creates list of users with given input array.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.4/5.0

Behavior2/5

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

The description only states the action ('creates list of users') without disclosing any behavioral details such as required permissions, idempotency, failure modes, or the structure of the input array. With no safety-related annotations (readOnlyHint/destructiveHint), the description carries the full burden but fails to provide meaningful transparency.

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 a single, short sentence with no redundant wording. It is front-loaded and efficient, making it easy to parse, though the brevity comes at the expense of necessary detail.

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?

This tool likely handles batch user creation, yet the schema is empty, there is no output schema, and the description provides only a vague reference to an input array. An agent would have no idea what parameters to pass, how to format the request, or what the response looks like. This is severely inadequate for correct invocation.

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?

The input schema is empty, so the description's mention of a 'given input array' adds a minimal hint that some input is expected. However, it does not explain the array's contents, structure, or format. With schema coverage considered high (vacuously), a baseline of 3 is appropriate, but the description barely compensates for the lack of schema details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tautological: description restates name/title.

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 guidance on when to use this tool versus the singular 'create_user' or other user-related operations. No alternatives, prerequisites, or context are mentioned, leaving the agent without any decision support.

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

delete_orderDelete purchase order by identifier.A

DestructiveIdempotent

For valid response try integer IDs with value < 1000. Anything above 1000 or non-integers will generate API errors.

ParametersJSON Schema

Name	Required	Description	Default
`orderId`	Yes	ID of the order that needs to be deleted

TDQS

A4/5.0

Behavior4/5

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

The description discloses that values above 1000 or non-integers will generate API errors, which is a behavioral trait beyond the annotations. However, it does not describe the success response or any side effects beyond the destructiveHint already provided. No contradiction with annotations.

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 a single concise sentence that immediately conveys the key usage caveat. It contains no fluff and earns its place.

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 simple delete operation with annotations and full schema coverage, the description covers the essential caveat about ID values. It does not mention the success response or behavior for valid deletions, but this is partially covered by the tool's known effect and annotations.

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% with a basic description of orderId, but the description adds a critical valid-range constraint (integer, < 1000). This clarifies parameter semantics in a way the schema does not.

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 title 'Delete purchase order by identifier.' clearly states the action and resource. The schema's parameter description reinforces this. It is easily distinguished from siblings like get_order_by_id or delete_pet.

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?

The description only provides an ID range constraint ('integer IDs with value < 1000') but gives no guidance on when to use this tool versus alternatives, nor any prerequisites or contextual cues for selection. The existence of delete_user and delete_pet shows alternatives exist, but no comparison is made.

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

delete_petDeletes a pet.D

DestructiveIdempotent

Delete a pet.

ParametersJSON Schema

Name	Required	Description	Default
`petId`	Yes	Pet id to delete
`api_key`	No

TDQS

D1.9/5.0

Behavior2/5

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

The description adds no behavioral transparency beyond the annotations. The annotations already declare destructiveHint: true and idempotentHint: true, and the description merely confirms deletion. No additional context such as irreversibility, related effects, or auth requirements is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

While the description is extremely short and front-loaded, this is under-specification rather than conciseness. It consists of three words and leaves the user without any actionable detail beyond the tool name.

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 destructive operation with two parameters and no output schema, the description is incomplete. It lacks context about the petId requirement, the api_key parameter, potential side effects, or the return value. The annotation provides some context, but the description itself does not stand on its own.

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?

The schema includes two parameters: petId (with a short description) and api_key (undocumented). The description 'Delete a pet.' contributes nothing to understanding either parameter. With schema coverage at only 50%, the description was expected to compensate but fails entirely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a pet.' is a tautology that simply restates the tool name and title. It identifies the verb and resource but adds no specificity about scope, conditions, or what distinguishes it from sibling delete tools like delete_user or delete_order.

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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, idempotency implications, or contexts where a different tool (e.g., update_pet) would be more appropriate. The only implication is that you use it to delete a pet, which is already obvious.

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

delete_userDelete user resource.B

DestructiveIdempotent

This can only be done by the logged in user.

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	The name that needs to be deleted

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint, idempotentHint, and openWorldHint. The description adds that authentication is required, which is not captured in annotations. However, it does not clarify the scope (e.g., whether the logged-in user can delete any username or only themselves) or the consequences of deletion.

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?

A single short sentence with no filler or redundancy. It is perfectly concise, even though it is under-specified in content.

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

Completeness3/5

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

For a simple one-parameter delete tool, the annotations and schema cover several aspects, and the description adds the auth requirement. However, the ambiguity about whether the logged-in user can delete arbitrary users or only their own account is a significant gap for a destructive operation.

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 coverage is 100% and the username parameter is well-described as 'The name that needs to be deleted'. The description adds no additional parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does not explicitly state that the tool deletes a user; it only mentions a condition ('can only be done by the logged in user'). The title and tool name carry the actual purpose, but the description itself is vague about the core action.

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 description provides a prerequisite (must be logged in) but no guidance on when to use this tool versus alternatives or what distinguishes it from other delete operations among the siblings.

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

find_pets_by_statusFinds Pets by status.A

Read-onlyIdempotent

Multiple status values can be provided with comma separated strings.

ParametersJSON Schema

Name	Required	Description	Default
`status`	Yes	Status values that need to be considered for filter	available

TDQS

A3.5/5.0

Behavior4/5

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

The annotation already declares readOnlyHint, openWorldHint, and idempotentHint, so the agent knows it's a safe read operation. The description adds a behavioral detail that multiple status values can be combined as comma-separated strings, which is not in the annotations. This enriches the agent's understanding of the tool's input behavior.

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 a single, concise sentence with no fluff or repetition. It is appropriately sized for the tool's simplicity and gets straight to the usage detail. It earns a high score for efficiency.

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 simple one-parameter tool with strong annotations and full schema coverage, the description is mostly adequate. It lacks an explicit return-value statement, but the tool's name and title imply the result is a list of pets. The added comma-separated behavior completes the essential input semantics, making the overall definition reasonably complete.

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 describes the status parameter with an enum and a generic description, but the description clarifies that comma-separated multiple values are accepted. This is critical parameter semantics not explicitly stated in the schema. The description adds meaningful value beyond the schema's built-in documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description only states 'Multiple status values can be provided with comma separated strings,' which does not explicitly state that the tool finds pets. The tool's name and title convey the function, but the description itself lacks a clear verb+resource statement. Thus, the purpose is vague when relying on the description alone.

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?

The description provides no guidance on when to choose this tool over alternatives like find_pets_by_tags. It only offers a parameter formatting note, not tool-selection context. No exclusions or alternative tool references are given.

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

find_pets_by_tagsFinds Pets by tags.B

Read-onlyIdempotent

Multiple tags can be provided with comma separated strings. Use tag1, tag2, tag3 for testing.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	Yes	Tags to filter by

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds a note about comma-separated strings (though the schema expects an array) and suggests test tags, which is minor extra context. No contradiction with annotations, but no substantial new behavioral disclosure.

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 very short—two sentences with no filler words. It is concise, but it leads with a usage note rather than stating the purpose, which is a minor structural flaw. Still, it is efficient and to the point.

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?

The tool is simple (one parameter, no output schema), but the description still lacks essential information: it does not mention what the function returns (e.g., a list of pets), nor does it clarify the relationship to find_pets_by_status. The testing example is not enough to make the tool fully usable in context.

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% ('Tags to filter by'), so the schema already explains the parameter. The description adds a hint about multiple tags and sample values, but it also creates ambiguity by suggesting comma-separated strings instead of an array. The added value is marginal and slightly conflicting.

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 title 'Finds Pets by tags' clearly states the tool's verb and resource, and the description supplements with usage details. However, the description itself does not restate the purpose or explicitly differentiate from the sibling find_pets_by_status, though the resource and filter criterion are evident from the name and schema.

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?

The description provides an example ('Use tag1, tag2, tag3 for testing') and mentions comma-separated strings, but it gives no explicit guidance on when to use this tool versus alternatives like find_pets_by_status. There are no stated exclusions or contextual triggers, so the agent is left without decision support.

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

get_inventoryReturns pet inventories by status.A

Read-onlyIdempotent

Returns a map of status codes to quantities.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering the safety profile. The description adds the return type (map of status codes to quantities) but does not disclose any additional behavioral traits such as auth requirements, rate limits, or side effects beyond what annotations provide.

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 a single sentence, eight words long, with no redundant text. It is front-loaded with the verb and resource, and every word earns its place.

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 simple no-parameter, read-only tool, the description is adequate. It specifies the return shape (map of status codes to quantities), which is critical since there is no output schema. It does not enumerate possible status codes, but this is inferable and not necessary for operation.

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, and the schema description coverage is 100% (empty schema). With no parameters, the description does not need to add parameter semantics. Baseline for 0 params is 4, and the description does not introduce confusion.

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 clearly states the tool 'Returns a map of status codes to quantities', which is a specific verb (returns) and resource (inventory map). This distinguishes it from sibling tools like get_pet_by_id or find_pets_by_status, which focus on pets rather than inventory.

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 usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention any context such as 'use for stock levels' or 'prefer over find_pets_by_status for inventory counts'.

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

get_order_by_idFind purchase order by ID.B

Read-onlyIdempotent

For valid response try integer IDs with value <= 5 or > 10. Other values will generate exceptions.

ParametersJSON Schema

Name	Required	Description	Default
`orderId`	Yes	ID of order that needs to be fetched

TDQS

B3/5.0

Behavior4/5

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

The description discloses that IDs outside the stated ranges generate exceptions, which is a behavioral quirk not captured by the readOnlyHint, openWorldHint, or idempotentHint annotations. It adds useful information about 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 extremely concise—a single sentence—and wastes no words. However, it omits the primary purpose, so it is terse but not fully informative.

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

Completeness3/5

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

Given the title supplies the purpose and the readOnlyHint/idempotentHint cover safety, the description's extra info about exceptions makes the overall definition reasonably complete for a simple fetch-by-ID operation. Still, the description alone would be incomplete without the title and annotations, so it earns a mid score.

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 input schema defines orderId as int64 with a generic description. The description adds a specific constraint (IDs <=5 or >10) that affects whether a valid response is returned, providing meaningful semantic detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does not state what the tool does; it only provides a note about valid ID ranges ('try integer IDs with value <= 5 or > 10'). The title 'Find purchase order by ID' supplies the purpose, but the description itself lacks an explicit verb+resource statement, making it vague and failing to distinguish from siblings like get_pet_by_id without relying on the title.

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?

The description gives no guidance on when to use this tool versus alternatives such as get_pet_by_id or find_pets_by_status. It merely hints at ID values that yield valid responses, which is a parameter constraint, not usage context.

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

get_pet_by_idFind pet by ID.C

Read-onlyIdempotent

Returns a single pet.

ParametersJSON Schema

Name	Required	Description	Default
`petId`	Yes	ID of pet to return

TDQS

C2.9/5.0

Behavior2/5

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

The description adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the agent knows it is a safe read. But the description does not disclose potential 404 behavior, response shape, or any other runtime details that would be useful for an agent.

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 short, front-loaded sentence with no wasted words. It conveys the core action, though it could have been slightly more informative without becoming verbose.

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

Completeness3/5

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

For a simple read-only getter with minimal parameters and good annotations, the description is adequate but lacks details about the return object structure or error handling. Since there is no output schema, a bit more context would improve completeness, but the simplicity of the operation keeps it at a borderline acceptable level.

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?

The input schema has 100% coverage for the sole parameter petId with a clear description 'ID of pet to return'. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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 'Returns a single pet' clearly states the verb and resource, and the word 'single' helps distinguish it from sibling tools that return lists (e.g., find_pets_by_tags). However, it does not explicitly mention 'by ID' in the description itself, relying on the tool name and schema for that specificity.

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 guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or situations where another tool (e.g., find_pets_by_status) would be more appropriate. This is a bare statement with zero usage context.

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

get_user_by_nameGet user by user name.A

Read-onlyIdempotent

Get user detail based on username.

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	The name that needs to be fetched. Use user1 for testing

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and idempotentHint, which cover the safety profile. The description is consistent with these annotations but adds no extra behavioral context such as return format, error conditions, or authentication needs. It does not contradict the annotations.

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 a single, clear sentence with no filler. It is front-loaded with the action and resource, and every word contributes to understanding.

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

Completeness3/5

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

Given the simplicity of the tool (one parameter, read-only annotations), the description is adequate but minimal. It does not explain return values or failure behavior, and since there is no output schema, the description could carry more weight, but the intent is clear.

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%, as the 'username' parameter is fully documented with a description including a test value. The tool description adds no additional semantic meaning beyond restating 'based on username', so the baseline of 3 applies.

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 uses a specific verb 'get', identifies the resource 'user', and the basis 'username', making the tool's function unambiguous. It clearly distinguishes from sibling tools like update_user, delete_user, and create_user by focusing on retrieval.

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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions, prerequisites, or fallback tools. The context of when to choose this tool is only implied by its purpose.

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

login_userLogs user into the system.C

Read-onlyIdempotent

Log into the system.

ParametersJSON Schema

Name	Required	Description	Default
`password`	No	The password for login in clear text
`username`	No	The user name for login

TDQS

C2.4/5.0

Behavior1/5

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

The description directly contradicts the annotations: readOnlyHint is true, but 'Log into the system' implies a session-creating side effect. No behavioral details (e.g., token return, session expiry) are disclosed beyond the misleading annotation.

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 extremely brief and does not waste words, but it is under-specified to the point of adding nothing beyond the title. It is concise but not meaningfully structured or informative.

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 the absence of an output schema and the simple parameter set, the description should still explain expected behavior or return value. It fails to mention success/failure outcomes, session details, or the effect of invalid credentials, making it incomplete for a login action.

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?

The input schema already provides full descriptions for both username and password (100% coverage). The description adds no additional parameter semantics, so it meets the baseline for schema-documented parameters.

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 'Log into the system' clearly states the action and resource, distinguishing it from siblings like get_user_by_name or update_user. However, it is virtually identical to the name and title, adding no new specificity, so it does not earn a 5.

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

Usage Guidelines1/5

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

The description offers no guidance on when to use this tool versus alternatives (e.g., get_user_by_name for fetching user info), nor any prerequisites like the user existing or session handling. It is entirely absent of usage context.

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

logout_userLogs out current logged in user session.B

Read-onlyIdempotent

Log user out of the system.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior1/5

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

Annotation Contradiction: The description states 'Log user out of the system,' which is a state-changing operation, but annotations include readOnlyHint: true, meaning the tool is marked as not modifying state. This is a direct contradiction, and no additional behavioral context is provided.

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 a single, front-loaded sentence that conveys the action without unnecessary words or repetition. It is concise and appropriately sized for such a simple tool.

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

Completeness3/5

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

Given the zero-parameter schema and simple action, the description is nearly sufficient, but it lacks context about session invalidation or post-condition behavior. The annotation contradiction further undermines the reliability of the tool's behavioral profile, making it a minimum-viable but incomplete description.

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 and the schema is empty, so there are no parameter meanings to clarify. Baseline 4 is appropriate since no description is needed for absent parameters.

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 uses a specific verb ('log out') and identifies the target ('the system'), clearly distinguishing it from sibling tools like login_user or update_user. The title further clarifies that it targets the current logged-in user session.

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 usage guidance is provided. The description does not state when to use this tool, prerequisites (e.g., must be logged in), or alternatives, leaving the agent to infer context from the name and title alone.

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

place_orderPlace an order for a pet.C

Place a new order in the store.

ParametersJSON Schema

Name	Required	Description
`id`	No
`petId`	No
`status`	No	Order Status
`complete`	No
`quantity`	No
`shipDate`	No

TDQS

C2.6/5.0

Behavior2/5

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

The description only states 'Place a new order', which implies a mutation, but does not disclose side effects, required permissions, or response behavior. Annotations provide only openWorldHint, which does not cover safety traits, so the description carries the burden and fails to add behavioral transparency beyond the basic verb.

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 a single sentence with no filler; it is front-loaded and every word serves a purpose. While it is under-specified, that is an issue of completeness rather than conciseness, so it earns a perfect score here.

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?

For a tool with 6 parameters, no output schema, and minimal annotations, a one-sentence description is grossly insufficient. It doesn't explain what an order is, how petId relates to the order, or any order lifecycle details, making it inadequate for real-world 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?

With schema description coverage at only 17% (only 'status' has a description), the description needed to compensate by explaining parameters, but it mentions none at all. It provides zero guidance on id, petId, quantity, shipDate, or complete, leaving the agent completely blind to parameter semantics.

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 action ('Place a new order') on a specific resource (order in the store), distinguishing it from sibling get/delete operations. However, it omits pet-specific context from the title and doesn't explicitly contrast with alternatives, preventing a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives like get_inventory or delete_order. It lacks prerequisites, exclusions, or contextual hints beyond the bare action itself, leaving agents to infer usage from the tool name alone.

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

update_petUpdate an existing pet.C

Idempotent

Update an existing pet by Id.

ParametersJSON Schema

Name	Required	Description
`id`	No
`name`	Yes
`tags`	No
`status`	No	pet status in the store
`category`	No
`photoUrls`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

Annotations provide idempotentHint and openWorldHint, but the description adds no additional behavioral context such as whether this is a full or partial update, authentication requirements, or effects on associated data. It does not leverage the description field to enrich what annotations already convey.

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 concise sentence with no wasted words. It is appropriately sized for delivering the basic idea, though it sacrifices depth for brevity.

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 the tool's complexity (6 parameters, nested objects, no output schema), the description is far too sparse. It does not explain return values, error behavior, or the scope of the update, leaving significant gaps for an agent.

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?

With only 17% schema description coverage, the description should compensate by explaining key parameters. It mentions 'Id' but the schema does not list id as required, and the actual required fields (name, photoUrls) are undocumented. This could lead to incorrect 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 'Update an existing pet by Id' clearly states the action (update), the resource (pet), and the identifying mechanism (by Id). It is specific enough to distinguish from add_pet or delete_pet, though it does not explicitly differentiate from the sibling update_pet_with_form.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when update_pet_with_form might be preferred. The description simply states the action without any usage context.

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

update_pet_with_formUpdates a pet in the store with form data.C

Updates a pet resource based on the form data.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name of pet that needs to be updated
`petId`	Yes	ID of pet that needs to be updated
`status`	No	Status of pet that needs to be updated

TDQS

C2.9/5.0

Behavior2/5

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

Annotations provide no readOnly or destructive hints, so the description must disclose safety and behavioral traits. It only restates that it updates a pet, with no information about authentication, idempotency, partial updates, or response behavior. This is insufficient for a mutation tool.

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 short and non-redundant internally, but it largely duplicates the title 'Updates a pet in the store with form data.' It does not add new information, so while concise, it doesn't earn its place as a value-adding description.

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

Completeness3/5

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

The tool is simple and schema covers parameters, but the description is minimal. It omits the form-encoding distinction from 'update_pet' and any response expectations. Given the absence of an output schema, a brief note on usage context would improve completeness.

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?

All three parameters have clear schema descriptions ('Name of pet that needs to be updated', etc.), so the description does not need to add param-level detail. The phrase 'based on the form data' vaguely connects to the parameters but adds no concrete semantics. Schema coverage is 100%, so baseline 3 applies.

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 specifies the action ('updates') and resource ('pet'), making the core function clear. However, it fails to distinguish from the sibling tool 'update_pet', which likely updates a pet via JSON rather than form data, so the specificity is incomplete.

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?

The description provides no guidance on when to use this tool instead of alternatives. It does not mention the 'form' aspect as a deciding factor, nor does it reference 'update_pet' for JSON payloads. Agents must infer usage from the tool name.

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

update_userUpdate user resource.D

Idempotent

This can only be done by the logged in user.

ParametersJSON Schema

Name	Required	Description
`id`	No
`email`	No
`phone`	No
`lastName`	No
`password`	No
`username`	Yes	name that need to be deleted
`firstName`	No
`userStatus`	No	User Status

TDQS

D1.5/5.0

Behavior2/5

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

The description adds a single behavioral constraint (authentication requirement) but does not disclose update semantics, such as partial versus full replacement, side effects, or reversibility. The annotations (openWorldHint, idempotentHint) provide some context, but the description offers minimal additional insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, but it is under-specified rather than concise. It contains a single clause that conveys very little, failing to earn its place by providing essential information about the tool's purpose or usage.

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?

Given the tool's complexity (8 parameters, no output schema, low schema coverage), the description is drastically incomplete. It does not explain what fields can be updated, what the response is, or how authentication affects invocation. An agent cannot reliably select or use this tool based on the provided description.

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 coverage is only 25% (username gets a misleading description). The description does not compensate by explaining any parameters, despite 8 parameters being present. The agent gets no help understanding required fields, formats, or relationships between fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does not state what the tool does. It only says 'This can only be done by the logged in user,' which is a constraint, not a purpose. The tool's name and title indicate it updates a user, but the description itself fails to convey the operation.

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?

The description implies that the user must be logged in to perform the update, but it provides no guidance on when to use this tool versus alternatives like delete_user or get_user_by_name. No exclusions or comparisons to sibling tools are given.

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

upload_fileUploads an image.C

Upload image of the pet.

ParametersJSON Schema

Name	Required	Description	Default
`petId`	Yes	ID of pet to update
`additionalMetadata`	No	Additional Metadata

TDQS

C2.9/5.0

Behavior2/5

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

With only openWorldHint: true in annotations and no readOnly/destructive hints, the description carries the burden of disclosing behavioral traits. It states the upload action but does not mention side effects, required permissions, or any state changes. The openWorldHint is consistent with an upload, but the description adds no extra behavioral context.

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 sentence with no fluff, but it is under-specified. It is not a 5 because it could include a bit more context (e.g., what the image is used for) while remaining concise.

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

Completeness3/5

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

Given the low complexity (2 params, no output schema), the description is minimally adequate. However, it lacks any guidance on expected behavior or return values, and the absence of usage guidelines makes it incomplete for an agent deciding whether to invoke this tool.

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 both petId and additionalMetadata have descriptions. The description 'Upload image of the pet' does not add meaning beyond the schema; it only implies the image file is sent, but that is inherent to the tool name. Baseline 3 applies.

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 'Upload image of the pet' clearly identifies the action (upload) and resource (image of pet), distinguishing it from sibling tools like update_pet_with_form and add_pet. However, it is terse and doesn't elaborate on the scope or purpose beyond the title.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the pet must exist or if authentication is required, nor does it contrast with update_pet_with_form or other pet-related operations.

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. Dates show when Glama detected each change.

19 tool updatesv0.6.2Aug 11, 2026

Changedadd_pet29 fields changed

removedInput schema / $defs

Removed value: -{
-  "AddPetCategory": {
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Id"
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Name"
-      }
-    },
-    "title": "AddPetCategory",
-    "type": "object"
-  },
-  "AddPetTagsItem": {
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Id"
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Name"
-      }
-    },
-    "title": "AddPetTagsItem",
-    "type": "object"
-  }
-}

removedInput schema / properties / category / anyOf

Removed value: -[
-  {
-    "$ref": "#/$defs/AddPetCategory"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / category / default
```
Removed value: -null
```

addedInput schema / properties / category / properties

Added value: +{
+  "id": {
+    "example": 1,
+    "format": "int64",
+    "type": "integer"
+  },
+  "name": {
+    "example": "Dogs",
+    "type": "string"
+  }
+}

addedInput schema / properties / category / type
```
Added value: +"object"
```
addedInput schema / properties / category / xml
```
Added value: +{
+  "name": "category"
+}
```

removedInput schema / properties / id / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / id / default
```
Removed value: -null
```
addedInput schema / properties / id / example
```
Added value: +10
```
addedInput schema / properties / id / format
```
Added value: +"int64"
```
removedInput schema / properties / id / title
```
Removed value: -"Id"
```
addedInput schema / properties / id / type
```
Added value: +"integer"
```
addedInput schema / properties / name / example
```
Added value: +"doggie"
```
removedInput schema / properties / name / title
```
Removed value: -"Name"
```
addedInput schema / properties / photoUrls / items / xml
```
Added value: +{
+  "name": "photoUrl"
+}
```
removedInput schema / properties / photoUrls / title
```
Removed value: -"Photourls"
```
addedInput schema / properties / photoUrls / xml
```
Added value: +{
+  "wrapped": true
+}
```

removedInput schema / properties / status / anyOf

Removed value: -[
-  {
-    "enum": [
-      "available",
-      "pending",
-      "sold"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / status / default
```
Removed value: -null
```

addedInput schema / properties / status / enum

Added value: +[
+  "available",
+  "pending",
+  "sold"
+]

removedInput schema / properties / status / title
```
Removed value: -"Status"
```
addedInput schema / properties / status / type
```
Added value: +"string"
```

removedInput schema / properties / tags / anyOf

Removed value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/AddPetTagsItem"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / tags / default
```
Removed value: -null
```

addedInput schema / properties / tags / items

Added value: +{
+  "properties": {
+    "id": {
+      "format": "int64",
+      "type": "integer"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "type": "object",
+  "xml": {
+    "name": "tag"
+  }
+}

removedInput schema / properties / tags / title
```
Removed value: -"Tags"
```
addedInput schema / properties / tags / type
```
Added value: +"array"
```
addedInput schema / properties / tags / xml
```
Added value: +{
+  "wrapped": true
+}
```

removedInput schema / title

Removed value: -"upstream_callableArguments"

Changedcreate_user43 fields changed
- removedInput schema / properties / email / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / email / default
```
Removed value: -null
```
- addedInput schema / properties / email / example
```
Added value: +"john@email.com"
```
- removedInput schema / properties / email / title
```
Removed value: -"Email"
```
- addedInput schema / properties / email / type
```
Added value: +"string"
```
- removedInput schema / properties / firstName / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / firstName / default
```
Removed value: -null
```
- addedInput schema / properties / firstName / example
```
Added value: +"John"
```
- removedInput schema / properties / firstName / title
```
Removed value: -"Firstname"
```
- addedInput schema / properties / firstName / type
```
Added value: +"string"
```
- removedInput schema / properties / id / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / id / default
```
Removed value: -null
```
- addedInput schema / properties / id / example
```
Added value: +10
```
- addedInput schema / properties / id / format
```
Added value: +"int64"
```
- removedInput schema / properties / id / title
```
Removed value: -"Id"
```
- addedInput schema / properties / id / type
```
Added value: +"integer"
```
- removedInput schema / properties / lastName / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / lastName / default
```
Removed value: -null
```
- addedInput schema / properties / lastName / example
```
Added value: +"James"
```
- removedInput schema / properties / lastName / title
```
Removed value: -"Lastname"
```
- addedInput schema / properties / lastName / type
```
Added value: +"string"
```
- removedInput schema / properties / password / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / password / default
```
Removed value: -null
```
- addedInput schema / properties / password / example
```
Added value: +"12345"
```
- removedInput schema / properties / password / title
```
Removed value: -"Password"
```
- addedInput schema / properties / password / type
```
Added value: +"string"
```
- removedInput schema / properties / phone / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / phone / default
```
Removed value: -null
```
- addedInput schema / properties / phone / example
```
Added value: +"12345"
```
- removedInput schema / properties / phone / title
```
Removed value: -"Phone"
```
- addedInput schema / properties / phone / type
```
Added value: +"string"
```
- removedInput schema / properties / userStatus / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / userStatus / default
```
Removed value: -null
```
- addedInput schema / properties / userStatus / example
```
Added value: +1
```
- addedInput schema / properties / userStatus / format
```
Added value: +"int32"
```
- removedInput schema / properties / userStatus / title
```
Removed value: -"Userstatus"
```
- addedInput schema / properties / userStatus / type
```
Added value: +"integer"
```
- removedInput schema / properties / username / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / username / default
```
Removed value: -null
```
- addedInput schema / properties / username / example
```
Added value: +"theUser"
```
- removedInput schema / properties / username / title
```
Removed value: -"Username"
```
- addedInput schema / properties / username / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedcreate_users_with_list_input1 field changed
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changeddelete_order3 fields changed
- addedInput schema / properties / orderId / format
```
Added value: +"int64"
```
- removedInput schema / properties / orderId / title
```
Removed value: -"Orderid"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changeddelete_pet7 fields changed
- removedInput schema / properties / api_key / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / api_key / default
```
Removed value: -null
```
- removedInput schema / properties / api_key / title
```
Removed value: -"Api Key"
```
- addedInput schema / properties / api_key / type
```
Added value: +"string"
```
- addedInput schema / properties / petId / format
```
Added value: +"int64"
```
- removedInput schema / properties / petId / title
```
Removed value: -"Petid"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changeddelete_user2 fields changed
- removedInput schema / properties / username / title
```
Removed value: -"Username"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedfind_pets_by_status3 fields changed
- addedInput schema / properties / status / default
```
Added value: +"available"
```
- removedInput schema / properties / status / title
```
Removed value: -"Status"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedfind_pets_by_tags2 fields changed
- removedInput schema / properties / tags / title
```
Removed value: -"Tags"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedget_inventory1 field changed
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedget_order_by_id3 fields changed
- addedInput schema / properties / orderId / format
```
Added value: +"int64"
```
- removedInput schema / properties / orderId / title
```
Removed value: -"Orderid"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedget_pet_by_id3 fields changed
- addedInput schema / properties / petId / format
```
Added value: +"int64"
```
- removedInput schema / properties / petId / title
```
Removed value: -"Petid"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedget_user_by_name2 fields changed
- removedInput schema / properties / username / title
```
Removed value: -"Username"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedlogin_user9 fields changed
- removedInput schema / properties / password / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / password / default
```
Removed value: -null
```
- removedInput schema / properties / password / title
```
Removed value: -"Password"
```
- addedInput schema / properties / password / type
```
Added value: +"string"
```
- removedInput schema / properties / username / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / username / default
```
Removed value: -null
```
- removedInput schema / properties / username / title
```
Removed value: -"Username"
```
- addedInput schema / properties / username / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedlogout_user1 field changed
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedplace_order34 fields changed
- removedInput schema / properties / complete / anyOf
```
Removed value: -[
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / complete / default
```
Removed value: -null
```
- removedInput schema / properties / complete / title
```
Removed value: -"Complete"
```
- addedInput schema / properties / complete / type
```
Added value: +"boolean"
```
- removedInput schema / properties / id / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / id / default
```
Removed value: -null
```
- addedInput schema / properties / id / example
```
Added value: +10
```
- addedInput schema / properties / id / format
```
Added value: +"int64"
```
- removedInput schema / properties / id / title
```
Removed value: -"Id"
```
- addedInput schema / properties / id / type
```
Added value: +"integer"
```
- removedInput schema / properties / petId / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / petId / default
```
Removed value: -null
```
- addedInput schema / properties / petId / example
```
Added value: +198772
```
- addedInput schema / properties / petId / format
```
Added value: +"int64"
```
- removedInput schema / properties / petId / title
```
Removed value: -"Petid"
```
- addedInput schema / properties / petId / type
```
Added value: +"integer"
```
- removedInput schema / properties / quantity / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / quantity / default
```
Removed value: -null
```
- addedInput schema / properties / quantity / example
```
Added value: +7
```
- addedInput schema / properties / quantity / format
```
Added value: +"int32"
```
- removedInput schema / properties / quantity / title
```
Removed value: -"Quantity"
```
- addedInput schema / properties / quantity / type
```
Added value: +"integer"
```
- removedInput schema / properties / shipDate / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / shipDate / default
```
Removed value: -null
```
- addedInput schema / properties / shipDate / format
```
Added value: +"date-time"
```
- removedInput schema / properties / shipDate / title
```
Removed value: -"Shipdate"
```
- addedInput schema / properties / shipDate / type
```
Added value: +"string"
```
- removedInput schema / properties / status / anyOf
```
Removed value: -[
-  {
-    "enum": [
-      "placed",
-      "approved",
-      "delivered"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / status / default
```
Removed value: -null
```
- addedInput schema / properties / status / enum
```
Added value: +[
+  "placed",
+  "approved",
+  "delivered"
+]
```
- addedInput schema / properties / status / example
```
Added value: +"approved"
```
- removedInput schema / properties / status / title
```
Removed value: -"Status"
```
- addedInput schema / properties / status / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```

Changedupdate_pet29 fields changed

removedInput schema / $defs

Removed value: -{
-  "UpdatePetCategory": {
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Id"
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Name"
-      }
-    },
-    "title": "UpdatePetCategory",
-    "type": "object"
-  },
-  "UpdatePetTagsItem": {
-    "properties": {
-      "id": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Id"
-      },
-      "name": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "title": "Name"
-      }
-    },
-    "title": "UpdatePetTagsItem",
-    "type": "object"
-  }
-}

removedInput schema / properties / category / anyOf

Removed value: -[
-  {
-    "$ref": "#/$defs/UpdatePetCategory"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / category / default
```
Removed value: -null
```

addedInput schema / properties / category / properties

Added value: +{
+  "id": {
+    "example": 1,
+    "format": "int64",
+    "type": "integer"
+  },
+  "name": {
+    "example": "Dogs",
+    "type": "string"
+  }
+}

addedInput schema / properties / category / type
```
Added value: +"object"
```
addedInput schema / properties / category / xml
```
Added value: +{
+  "name": "category"
+}
```

removedInput schema / properties / id / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / id / default
```
Removed value: -null
```
addedInput schema / properties / id / example
```
Added value: +10
```
addedInput schema / properties / id / format
```
Added value: +"int64"
```
removedInput schema / properties / id / title
```
Removed value: -"Id"
```
addedInput schema / properties / id / type
```
Added value: +"integer"
```
addedInput schema / properties / name / example
```
Added value: +"doggie"
```
removedInput schema / properties / name / title
```
Removed value: -"Name"
```
addedInput schema / properties / photoUrls / items / xml
```
Added value: +{
+  "name": "photoUrl"
+}
```
removedInput schema / properties / photoUrls / title
```
Removed value: -"Photourls"
```
addedInput schema / properties / photoUrls / xml
```
Added value: +{
+  "wrapped": true
+}
```

removedInput schema / properties / status / anyOf

Removed value: -[
-  {
-    "enum": [
-      "available",
-      "pending",
-      "sold"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / status / default
```
Removed value: -null
```

addedInput schema / properties / status / enum

Added value: +[
+  "available",
+  "pending",
+  "sold"
+]

removedInput schema / properties / status / title
```
Removed value: -"Status"
```
addedInput schema / properties / status / type
```
Added value: +"string"
```

removedInput schema / properties / tags / anyOf

Removed value: -[
-  {
-    "items": {
-      "$ref": "#/$defs/UpdatePetTagsItem"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / tags / default
```
Removed value: -null
```

addedInput schema / properties / tags / items

Added value: +{
+  "properties": {
+    "id": {
+      "format": "int64",
+      "type": "integer"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "type": "object",
+  "xml": {
+    "name": "tag"
+  }
+}

removedInput schema / properties / tags / title
```
Removed value: -"Tags"
```
addedInput schema / properties / tags / type
```
Added value: +"array"
```
addedInput schema / properties / tags / xml
```
Added value: +{
+  "wrapped": true
+}
```

removedInput schema / title

Removed value: -"upstream_callableArguments"

Changedupdate_pet_with_form11 fields changed
- removedInput schema / properties / name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / name / default
```
Removed value: -null
```
- removedInput schema / properties / name / title
```
Removed value: -"Name"
```
- addedInput schema / properties / name / type
```
Added value: +"string"
```
- addedInput schema / properties / petId / format
```
Added value: +"int64"
```
- removedInput schema / properties / petId / title
```
Removed value: -"Petid"
```
- removedInput schema / properties / status / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / status / default
```
Removed value: -null
```
- removedInput schema / properties / status / title
```
Removed value: -"Status"
```
- addedInput schema / properties / status / type
```
Added value: +"string"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedupdate_user39 fields changed
- removedInput schema / properties / email / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / email / default
```
Removed value: -null
```
- addedInput schema / properties / email / example
```
Added value: +"john@email.com"
```
- removedInput schema / properties / email / title
```
Removed value: -"Email"
```
- addedInput schema / properties / email / type
```
Added value: +"string"
```
- removedInput schema / properties / firstName / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / firstName / default
```
Removed value: -null
```
- addedInput schema / properties / firstName / example
```
Added value: +"John"
```
- removedInput schema / properties / firstName / title
```
Removed value: -"Firstname"
```
- addedInput schema / properties / firstName / type
```
Added value: +"string"
```
- removedInput schema / properties / id / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / id / default
```
Removed value: -null
```
- addedInput schema / properties / id / example
```
Added value: +10
```
- addedInput schema / properties / id / format
```
Added value: +"int64"
```
- removedInput schema / properties / id / title
```
Removed value: -"Id"
```
- addedInput schema / properties / id / type
```
Added value: +"integer"
```
- removedInput schema / properties / lastName / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / lastName / default
```
Removed value: -null
```
- addedInput schema / properties / lastName / example
```
Added value: +"James"
```
- removedInput schema / properties / lastName / title
```
Removed value: -"Lastname"
```
- addedInput schema / properties / lastName / type
```
Added value: +"string"
```
- removedInput schema / properties / password / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / password / default
```
Removed value: -null
```
- addedInput schema / properties / password / example
```
Added value: +"12345"
```
- removedInput schema / properties / password / title
```
Removed value: -"Password"
```
- addedInput schema / properties / password / type
```
Added value: +"string"
```
- removedInput schema / properties / phone / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / phone / default
```
Removed value: -null
```
- addedInput schema / properties / phone / example
```
Added value: +"12345"
```
- removedInput schema / properties / phone / title
```
Removed value: -"Phone"
```
- addedInput schema / properties / phone / type
```
Added value: +"string"
```
- removedInput schema / properties / userStatus / anyOf
```
Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / userStatus / default
```
Removed value: -null
```
- addedInput schema / properties / userStatus / example
```
Added value: +1
```
- addedInput schema / properties / userStatus / format
```
Added value: +"int32"
```
- removedInput schema / properties / userStatus / title
```
Removed value: -"Userstatus"
```
- addedInput schema / properties / userStatus / type
```
Added value: +"integer"
```
- removedInput schema / properties / username / title
```
Removed value: -"Username"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```
Changedupload_file7 fields changed
- removedInput schema / properties / additionalMetadata / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / additionalMetadata / default
```
Removed value: -null
```
- removedInput schema / properties / additionalMetadata / title
```
Removed value: -"Additionalmetadata"
```
- addedInput schema / properties / additionalMetadata / type
```
Added value: +"string"
```
- addedInput schema / properties / petId / format
```
Added value: +"int64"
```
- removedInput schema / properties / petId / title
```
Removed value: -"Petid"
```
- removedInput schema / title
```
Removed value: -"upstream_callableArguments"
```

4 tool updatesv0.5.1Jun 20, 2026

Changedadd_pet5 fields changed

addedInput schema / $defs

Added value: +{
+  "AddPetCategory": {
+    "properties": {
+      "id": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Id"
+      },
+      "name": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Name"
+      }
+    },
+    "title": "AddPetCategory",
+    "type": "object"
+  },
+  "AddPetTagsItem": {
+    "properties": {
+      "id": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Id"
+      },
+      "name": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Name"
+      }
+    },
+    "title": "AddPetTagsItem",
+    "type": "object"
+  }
+}

changedInput schema / properties / category / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/AddPetCategory"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / category / title
```
Removed value: -"Category"
```

changedInput schema / properties / status / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "available",
+      "pending",
+      "sold"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / tags / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "$ref": "#/$defs/AddPetTagsItem"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

Changedfind_pets_by_status1 field changed
- addedInput schema / properties / status / enum
```
Added value: +[
+  "available",
+  "pending",
+  "sold"
+]
```

Changedplace_order1 field changed

changedInput schema / properties / status / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "placed",
+      "approved",
+      "delivered"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changedupdate_pet5 fields changed

addedInput schema / $defs

Added value: +{
+  "UpdatePetCategory": {
+    "properties": {
+      "id": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Id"
+      },
+      "name": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Name"
+      }
+    },
+    "title": "UpdatePetCategory",
+    "type": "object"
+  },
+  "UpdatePetTagsItem": {
+    "properties": {
+      "id": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Id"
+      },
+      "name": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "title": "Name"
+      }
+    },
+    "title": "UpdatePetTagsItem",
+    "type": "object"
+  }
+}

changedInput schema / properties / category / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "$ref": "#/$defs/UpdatePetCategory"
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / category / title
```
Removed value: -"Category"
```

changedInput schema / properties / status / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "available",
+      "pending",
+      "sold"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / tags / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "$ref": "#/$defs/UpdatePetTagsItem"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

19 tool updatesv1.0.0Jun 11, 2026
- First observedadd_pet
- First observedcreate_user
- First observedcreate_users_with_list_input
- First observeddelete_order
- First observeddelete_pet
- First observeddelete_user
- First observedfind_pets_by_status
- First observedfind_pets_by_tags
- First observedget_inventory
- First observedget_order_by_id
- First observedget_pet_by_id
- First observedget_user_by_name
- First observedlogin_user
- First observedlogout_user
- First observedplace_order
- First observedupdate_pet
- First observedupdate_pet_with_form
- First observedupdate_user
- First observedupload_file

Install Server

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

TDQS

B3/5.0

Disambiguation4/5

Tools are generally distinct per resource and action, but update_pet and update_pet_with_form could confuse agents expecting a single update path. Similarly, create_user vs create_users_with_list_input are similar in purpose though descriptions clarify the difference.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., get_pet_by_id, delete_order, create_user). There is minor variation in verbs like add vs create, but the pattern remains predictable throughout.

Tool Count5/5

19 tools is well-scoped for a pet store API covering pets, users, and orders. Each tool serves a clear purpose without redundancy, and the count is within the typical range for a domain-specific server.

Completeness4/5

The toolset provides solid CRUD coverage for pets, users, and orders, including listing/filtering and file upload. Minor gaps exist—for example, no update order and no way to list all users or all pets generically—but core workflows are covered.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

bridgeOAuth
ai.kaiv
Create hosted MCP servers from any OpenAPI spec. Requires a free Kaiva Bridge account.
Developer Tools Cloud Platforms
1
apis-io B
io.apis
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
Search Developer Tools Documentation Access
1332
typeshipOAuth
dev.typeship
Generate a typed SDK, CLI, and MCP server from any OpenAPI or GraphQL spec, and keep them current.
Developer Tools CI/CD & DevOps
1
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

Emcee
API Testing Agent Orchestration
mattt
A
license
Not graded
quality
C
maintenance
Generate an MCP server for any OpenAPI documented endpoint.
Updated 2 months ago (2026-07-04 11:41 UTC)
330
MIT
FastMCP OpenAPI
API Testing Developer Tools App Automation
Agarwal-Saurabh
A
license
Not graded
quality
D
maintenance
Dynamically generates MCP tools from OpenAPI specifications, enabling AI assistants to interact with any REST API through natural language. Supports multiple APIs with authentication, parameter validation, and integration with Claude Desktop and LangChain.
Updated a year ago (2025-10-13 10:19 UTC)
1
MIT
OpenAPI MCP Server
API Testing Developer Tools App Automation
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.
Updated 7 months ago (2026-01-27 03:22 UTC)
2
14
MIT
OpenAPI MCP Server
Developer Tools API Testing
prompteus-ai
F
license
Not graded
quality
D
maintenance
Dynamically creates an MCP server from any OpenAPI schema, enabling seamless integration with tools like Prompteus and Claude.
Updated a year ago (2025-05-02 15:04 UTC)
4
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mroops0111/openapi-mcp-gateway'

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