OpenAPI MCP Gateway

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 2.9/5 across 19 of 19 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![openapi-mcp-gateway MCP server](https://glama.ai/mcp/servers/mroops0111/openapi-mcp-gateway/badges/card.svg)](https://glama.ai/mcp/servers/mroops0111/openapi-mcp-gateway)

Score Badge

Copy to your README.md:

[![openapi-mcp-gateway MCP server](https://glama.ai/mcp/servers/mroops0111/openapi-mcp-gateway/badges/score.svg)](https://glama.ai/mcp/servers/mroops0111/openapi-mcp-gateway)

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