Every tool carries its HTTP method and path in its description, which makes the mapping back to the endpoint visible instead of something you infer from the name. Because the surface is generated from a specification handed in at startup, the tools captured here belong to the Swagger Petstore demo — pets, store orders and users — rather than to the server itself. What the generation inherits is worth noticing: the write operations are as real as the API behind them, and delete_pet, delete_order and delete_user sit in the same list as the reads, with no separate switch in front of them.
A tool surface generated from an OpenAPI specification supplied when the server starts: every operation becomes a tool named after it and labelled with its method and path. The specification behind this capture is the Swagger Petstore.
- The pet resource end to end: add_pet and update_pet, find_pets_by_status and find_pets_by_tags, get_pet_by_id, update_pet_with_form, delete_pet, and upload_file for an image.
- The store side: get_inventory for pet inventories by status, place_order, get_order_by_id and delete_order.
- User management: create_user, create_users_with_list_input, get_user_by_name, update_user and delete_user, alongside login_user and logout_user.
- Each tool's HTTP method and path stated in its own description, so a call traces back to the endpoint it hits without a separate mapping.
- Parameters taken straight from the specification's operation — delete_pet takes the api_key the spec defines alongside the petId, and update_pet_with_form takes the form fields rather than a body.
An OpenAPI specification for the server to generate its tools from, supplied when it starts; the capture here points at the Swagger Petstore. Whatever the API behind it requires — login_user exchanges a username and password, and delete_pet takes an api_key.
One command — npx mcp-openapi --spec https://petstore3.swagger.io/api/v3/openapi.json