Loading ToolBench
MCP Server for the Petstore API with tools for managing pets, store inventory, and user accounts
This server exposes 20 tools wrapping a Petstore API. While tool names follow verb_noun convention, the implementation has critical gaps: descriptions are sparse and often unhelpful (many under 20 chars or missing entirely), parameter documentation is severely incomplete (most tools have no visible input schema), and output schemas are entirely undocumented. Only 3 tools (get_pet_find_by_status, delete_pet_pet_id, delete_store_order_order_id) show any schema information in the provided metadata. The remaining 17 tools lack visible schemas, making it impossible to verify parameter quality. No error handling guidance is present. The echo tool and several API-wrapper tools lack descriptions or provide only generic placeholders. This server reads as a template wrapper around OpenAPI (Petstore) without investment in LLM-optimized tool design.
Delete a pet.
For valid response try integer IDs with value < 1000. Anything above 1000 or non-integers will generate API errors.
This can only be done by the logged in user.
Echoes back the provided message
Multiple status values can be provided with comma separated strings.
Returns a single pet
17 of 20 tools lack visible input schemas. Only 3 tools (get_pet_find_by_status, delete_pet_pet_id, delete_store_order_order_id, echo) show any schema. LLMs cannot infer parameter types, required vs optional fields, or constraints from names alone.
5 tools have descriptions under 20 characters or are missing entirely: get_pet_find_by_tags (no description provided), post_pet, put_pet, post_pet_pet_id_upload_image, post_store_order, post_user, etc.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Returns pet inventories by status
For valid response try integer IDs with value <= 5 or > 1000. other values will generate API errors
Logs user into the system
Logs out current logged in user session
Get user by name
Add a new pet to the store
Updates a pet in the store with form data
uploads an image
Place a new order in the store
Create user
Creates list of users with given input array
Update an existing pet
Update user
No output schemas documented for any tool. LLMs cannot plan multi-step workflows or understand what data will be returned. For tools like get_pet_pet_id, the response structure must be documented so downstream tools can reference pet_id.
No parameter descriptions visible for 15 tools. Where schemas are present (get_pet_find_by_status has 'status' described, delete_pet_pet_id has 'petId' and 'api_key' with one empty description), most lack depth.
HTTP login/logout exposed as tools (get_user_login, get_user_logout) using GET semantics for session management. This is an API design smell, session state should not be tool parameters. Moreover, no description of what credentials are accepted or what the return value is (token? session ID? username?).
Destructive tools (delete_pet_pet_id, delete_store_order_order_id, delete_user_username) lack confirmation or dry-run support. No error handling guidance provided. LLMs cannot distinguish between retryable and permanent failures.
delete_pet_pet_id parameter 'api_key' has an empty description. This is a security concern if the api_key parameter is exposed at all, credentials should use server-side injection, not tool parameters.
No pagination support visible in list/find tools (get_pet_find_by_status, get_pet_find_by_tags, get_store_inventory, post_user_create_with_list). These are likely to return many results; without limit/offset, context window exhaustion is likely.
No error handling guidance in any tool description. Descriptions should tell LLMs what to do on failure: 'If pet not found, try searching by status first.' Currently, agents have no recovery path.
Tool naming mixes REST conventions (post_pet_pet_id_upload_image) with semantic verbs. Names like 'post_user_create_with_list' and 'get_user_login' are verbose and unclear about intent. Names should be concise verb_noun (e.g., 'upload_pet_image', 'login_user').