mcp-swagger

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose: fetching server URLs, executing endpoints, listing endpoints, getting details, searching, schema handling, tag management, API info, security schemes, validation, schema references, curl generation, and deprecated endpoints. The descriptions are explicit enough to prevent confusion even where similar (e.g., listEndpoints vs getEndpointsByTag).
Naming Consistency5/5
All tool names follow a consistent verb+noun camelCase pattern (get, execute, list, search, validate, generate). The style is uniform and predictable, making it easy to infer tool behavior from names.
Tool Count5/5
14 tools is well within the ideal 3-15 range and each tool addresses a specific need in exploring and interacting with a Swagger-defined API. The count feels comprehensive without being bloated.
Completeness5/5
The toolset covers the full lifecycle of API interaction: discovery (list, search, details), execution, schema exploration, security information, validation, and deprecation tracking. There are no obvious dead ends or missing essential operations for a Swagger/OpenAPI use case.
Average 3.8/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only retrieval ('récupère') but doesn't explicitly state that it has no side effects, nor does it describe error behavior, permissions, or any limitations. It adds minimal context beyond what is already implied by the tool name.
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 with no filler. It clearly states the action, the target, and the type of details returned, making it highly efficient.
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 tool's simplicity (2 parameters, high schema coverage) and lack of output schema, the description provides a decent overview of what is returned. However, it uses 'etc.' without specifying the exact structure, error scenarios, or how it differs from closely related tools like getSchemas. This leaves gaps for an agent to fully understand the tool's output.
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 schema descriptions for path and method are clear and complete (100% coverage). The description itself doesn't add any extra meaning about how to provide these parameters; it only mentions the content of the response. Since the schema already documents the parameters well, the baseline of 3 is appropriate.
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 and resource: 'Récupère les détails complets d'un endpoint spécifique' (retrieves complete details of a specific endpoint). It enumerates the content (paramètres, body, réponses, schémas) which distinguishes it from sibling tools like listEndpoints (listing) or getSchemas (schemas only).
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 explicit guidance on when to use this tool versus alternatives. The description only states what it does; it doesn't mention when not to use it or which sibling tool might be better for a different scenario. The implied use case (wanting details for a specific endpoint) is present but not articulated.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool returns the real response and automatically uses Swagger-defined headers, which is useful. However, it does not mention potential side effects (e.g., executing POST/PUT/DELETE mutates backend data), error behavior, authentication requirements, or rate limits. For an execution tool, this is a significant transparency gap.
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?
Two sentences, front-loaded with the core action, no redundancy. Every word is information-dense and fits the purpose of an execution tool.
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?
No output schema exists, but the tool is an execution tool with moderate complexity. The description lacks essential context about side effects, error scenarios, and security implications of calling endpoints. While the parameter list is well documented, the description fails to warn that mutating methods will actually change data. This is incomplete for a tool that directly invokes arbitrary API endpoints.
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?
Input schema covers 100% of parameter descriptions, so baseline is 3. The description adds context about automatic header handling and real response but does not elaborate on parameter syntax beyond what the schema already provides. Thus it adds marginal value.
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 'Exécute un endpoint API et retourne la réponse réelle' (executes an API endpoint and returns the actual response), which is a specific verb+resource. It distinguishes from sibling tools like listEndpoints and getEndpointDetails by emphasizing real-time execution rather than introspection of API definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'Parfait pour tester les endpoints et récupérer des données en temps réel' (perfect for testing endpoints and retrieving real-time data), implying use cases. It does not explicitly name alternatives or exclusions, but the contrast with sibling tools that inspect/retrieve definitions is implicit. This is clear context but lacks explicit 'when not to use' guidance.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions what the output includes (headers and example body), but does not disclose whether the operation has side effects, requires authentication, or what happens for invalid inputs. This is insufficient for a tool with no 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 clearly communicates the tool's function. No unnecessary words or repetition, and the information about headers and request body is efficiently included.
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 generation tool with 100% schema coverage, the description is mostly complete. It explains the core functionality and output contents. However, it lacks explicit usage guidance and does not describe the exact return format, but these are not critical for correct invocation. Overall, it is adequate for an agent to select and use the 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% for both parameters (path and method), with clear descriptions in the schema. The tool description does not add additional meaning beyond that, so the baseline 3 is appropriate. It does not explain how parameters affect the generated curl command beyond what the schema already states.
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 generates an example curl command for a specific endpoint, including headers and request body. The verb 'Génère' and resource 'exemple de commande curl' are specific, and it is distinct from sibling tools like executeEndpoint or listEndpoints.
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 implies usage: if you need a curl example for an endpoint, use this tool. However, it lacks explicit guidance on when to use it versus alternatives like executeEndpoint, or any exclusions. The context is implied but not clearly contrasted with sibling tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the two behavioral modes (list all vs. return complete schema), but it fails to mention potential error behavior (e.g., what happens if the schema name does not exist), authentication requirements, or the exact structure of the response. This is adequate but not thorough.
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 three sentences long, front-loaded with the main purpose, then economically explains the parameter-dependent behavior. Every sentence adds value, with no redundant or filler content. It is concise and well-structured.
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 (one optional parameter, no output schema, no annotations), but the description still leaves some gaps. It states what is returned in broad terms ('liste tous les schémas' and 'schéma complet') but does not clarify the exact return format (e.g., array of names vs. full definitions) or how errors are handled. Given the lack of an output schema, the description should provide more precise return information.
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 already documents the single optional parameter 'schemaName' with 100% coverage. The description adds meaningful semantics by explicitly stating that omitting the parameter lists all schemas and providing it returns the complete schema. This goes beyond the schema's simple 'optionnel' label.
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 the tool retrieves data schemas (DTOs) defined in the API, with a specific verb ('Récupère') and resource. It explains the two modes: no parameter lists all schemas, and with a name returns the complete schema. However, it does not explicitly distinguish itself from the sibling tool 'getSchemaReferences', so it misses the top score.
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 implies usage context: use without parameter to list all schemas, or with a name to get a specific schema. This is clear context but it does not provide explicit guidance on when to choose this tool over alternatives such as 'getSchemaReferences', nor does it mention any exclusions or prerequisites.
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?
No annotations are provided, so the description carries the full burden. It discloses that it lists all tags, but omits any details about return format, authentication requirements, side effects, or operational context. For a read-only tool this is a notable gap.
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 with no unnecessary words. It effectively communicates the tool's purpose.
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?
The tool is simple (no parameters, no output schema) and the description adequately explains its function. However, it doesn't mention return format or any operational caveats, which would make it fully 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 has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed given the empty parameter set.
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 ('Liste') and resource ('tags') with clear scope ('tous les tags utilisés pour catégoriser les endpoints'). It clearly differentiates from siblings like getEndpointsByTag by focusing on tags themselves rather than endpoints.
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 explicit guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. Usage is only implied by the name and simple statement.
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?
With no annotations, the description carries the full burden. It discloses the key behavior of suggesting similar paths when the path does not exist, but it does not specify the return format, confirm the operation is read-only, or mention any error handling. This is a minimum viable level of 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 concise sentence that front-loads the primary action (validating existence) and immediately adds the fallback behavior (suggesting similar paths). Every word contributes value, with no redundancy.
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 with one parameter and no output schema, but the description fails to mention what the tool returns (e.g., a boolean, a list of suggestions, or an object). This leaves the agent uncertain about how to interpret the result, so the description is adequate but not complete.
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 single parameter 'path' is already fully described in the input schema with an example, and the tool description adds no additional semantics. With 100% schema coverage, the baseline score of 3 is appropriate.
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 that the tool validates whether an endpoint path exists and, if not, suggests similar paths to correct typos. This specific verb+resource combination distinguishes it from sibling tools like searchEndpoints or getEndpointDetails.
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 implies the tool should be used to verify endpoint path existence and get typo suggestions, but it does not explicitly state when to use it over alternatives like searchEndpoints or provide exclusions. Only implied usage is present.
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?
With no annotations, the description carries the full burden. It indicates a read-only listing operation ('Liste') and specifies 'disponibles' (available), implying a filtered set. However, it does not disclose the return format, whether custom schemes are included, or any authentication requirements for calling the tool itself.
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, well-structured sentence. It front-loads the verb 'Liste' and immediately specifies the resource. No wasted words.
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 list tool with no parameters and no output schema, the description is mostly complete: it names the resource and examples. However, it could briefly hint at the response structure (e.g., 'returns a list of scheme names and types') to fully compensate for the missing output schema.
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, so the baseline is 4. The description adds context about the tool's domain (OAuth2, API keys, Bearer tokens) but no parameter-specific meaning is needed since there are none.
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 lists available authentication/authorization schemes, with concrete examples (OAuth2, API keys, Bearer tokens). The verb 'Liste' and resource 'schémas d'authentification/autorisation' make the purpose unambiguous and distinguish it from sibling tools like getSchemas.
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 'use when you need to see supported auth methods' or reference any sibling tools. For a tool in a group with similar list-focused endpoints, this missing context is a gap.
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?
With no annotations, the description carries the full burden. The verb 'récupère' implies a read-only, non-destructive operation, and the list of returned metadata fields adds context. However, it does not disclose permissions, rate limits, or response format, which could be more explicit for a tool with no annotation support.
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: 'Récupère les métadonnées de l'API' followed by a colon-separated list of fields. Every element earns its place, with no redundant or filler content.
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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides the essential purpose and the specific data returned. It could mention the response format or any prerequisites, but for a metadata getter this is largely sufficient, especially with the field enumeration.
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?
There are zero parameters, so the input schema is fully covered by default. The description adds value by specifying what metadata is retrieved, which is relevant output context. The baseline of 4 applies due to no 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 the specific verb 'Récupère' (retrieves) and clearly identifies the resource as API metadata, enumerating the exact fields returned (title, version, description, servers, contact, license). This distinguishes it from sibling tools like getServerUrls or getSchemas, which focus on specific aspects.
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?
No explicit when-to-use guidance or alternative comparisons are provided. The description simply states what the tool does, but the context of sibling tools implies this is for general API info while others handle endpoints or schemas. This is implicit rather than explicit.
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?
No annotations are provided, so the description carries the full burden. It states the core behavior (retrieves URLs and environments) but does not disclose return format, pagination, authentication, or any side effects. The verb implies read-only, but this is not explicit. For a simple getter, this is adequate but not rich.
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, front-loaded sentence efficiently conveys the tool's purpose without any fluff. Every word is meaningful, and the structure is optimal.
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 parameterless retrieval tool with no annotations and no output schema, the description is sufficient for invocation: it tells the agent what data it will receive (server URLs and environments). It could be slightly more explicit about the return structure, but the simplicity of the tool makes this a minor gap.
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, leading to a baseline of 4. The description does not need to explain parameters, and the schema confirms there are none. No additional semantics are required or provided.
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 retrieves server URLs and their environments (dev, staging, prod, etc.). The verb 'récupère' is specific, and the resource is unambiguous. It distinguishes itself from sibling tools focused on endpoints, schemas, and tags by focusing on server URLs/environments.
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?
Usage is implied by the purpose: you would use this tool when you need server URLs or environments. However, there is no explicit guidance on when to prefer this over siblings, nor any mention of exclusions or alternatives. The context is clear but not elaborated.
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?
Without annotations, the description carries the burden of behavioral disclosure. It adds that the return is a 'résumé léger' (light summary) to save tokens, which is useful context. It also mentions the response includes HTTP methods and tags, providing a clear expectation without contradictions.
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 two concise sentences in French, front-loading the primary purpose and adding a note about token efficiency. No wasted words.
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 tool with one optional parameter and no output schema, the description adequately explains the tool's purpose and the nature of the returned summary. It could specify the exact structure of the returned data, but the mention of HTTP methods and tags provides enough 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%, as the 'tag' parameter is fully described in the input schema. The description itself adds no further explanation of the parameter, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available endpoints with their HTTP methods and tags, using a specific verb and resource. It distinguishes from siblings like getEndpointsByTag and searchEndpoints by explicitly saying 'tous les endpoints' (all endpoints).
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 implies usage for getting an overview of all endpoints, but does not explicitly name alternatives or exclusions. With sibling tools like getEndpointsByTag and searchEndpoints, this could be clearer, but the purpose itself makes the primary use case evident.
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?
No annotations are provided, so the description carries the full burden. It clearly indicates a read operation ('Récupère') and provides the filtering scope, but does not disclose potential pagination, ordering, or what constitutes an 'endpoint' in the response. It is minimally transparent but not misleading.
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, focused sentence that immediately states the tool's purpose and relevance. No wasted words; every word earns its place.
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?
With no output schema, the description does not explain the return format, but the tool is simple (one parameter, read-only intent). It does not mention pagination or result details, but for a basic retrieval oriented around tags, the description is minimally sufficient. A more complete description could note whether endpoint summaries or full details are returned.
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 fully describes the only parameter 'tag' with a description, achieving 100% coverage. The description adds little beyond the schema, merely echoing 'tag spécifique'. Baseline 3 is appropriate as the schema carries the parameter meaning.
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 verb 'Récupère' (retrieves) and the resource 'endpoints' scoped by a 'tag spécifique'. It explicitly distinguishes itself from listEndpoints by noting it is 'Plus ciblé' (more targeted), which sets it apart from a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct when-to-use guidance by comparing with listEndpoints and indicating this tool is more targeted when a specific tag is involved. It names the alternative tool, fulfilling the requirement for explicit alternatives.
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?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Trouve') but does not disclose details such as matching behavior (exact vs partial), output format, or any limitations. The description is straightforward but lacks behavioral context beyond the core action.
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 two sentences long, front-loaded with the core function, and the second sentence adds a valuable use-case context. Every word serves a purpose; no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is complete: it states what it does, what it searches for, and when it's useful. The agent can confidently invoke it based on this information alone.
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 single parameter schemaName has a description in the schema ('Le nom du schéma à rechercher'), providing 100% schema description coverage. The tool description does not add additional semantic value beyond what the schema already states, 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 ('Trouve') and a clear resource ('tous les endpoints qui utilisent un schéma spécifique'), explicitly indicating the tool's function of finding endpoints referencing a given schema. This distinguishes it from siblings like getSchemas (which fetches schemas) and searchEndpoints (which does generic search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Utile pour l'analyse d'impact lors de modifications de schémas', which tells when to use it (impact analysis for schema changes). It does not explicitly mention when not to use it or alternative tools, but the context is sufficient.
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?
No annotations are provided, so the description carries full responsibility. It states the action (lists deprecated endpoints) but adds no further behavioral details such as pagination, ordering, or authentication requirements. The behavior is straightforward, but the description does not go beyond the tool's name to disclose any subtle traits.
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 two short sentences, front-loaded with the core action and followed by the use case. There is no redundant information or fluff, making it highly efficient.
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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description adequately covers what the tool does and why it is useful. It could have mentioned return format, but for a basic list operation, this is not a significant gap. The context is complete enough for an agent to invoke it correctly.
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, so the description is not required to explain parameter semantics. The schema coverage is implicitly 100% (vacuously), and the baseline for 0-parameter tools is 4. The description adds no parameter detail, which is appropriate 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 description clearly states the verb 'List' and the specific resource 'endpoints marked as deprecated', which distinguishes it from sibling tools like listEndpoints and searchEndpoints. It is unambiguous and uses precise terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Utile pour la planification de migrations' (useful for migration planning). This implies when to use the tool, though it does not explicitly mention alternatives or when not to use it. For a simple list tool, this contextual guidance is sufficient.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful details: the search covers paths, descriptions, and tags, and results are 'triés par pertinence' (sorted by relevance). However, it does not mention read-only nature, pagination, result limits, or any error behavior. For a search tool this is adequate but not rich, hence a 3.
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 two sentences long, front-loaded with the action ('Recherche des endpoints'), and each sentence carries meaningful information: what is searched and how results are ordered. There is no fluff or repetition, making it highly concise and well-structured.
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?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description covers all essential elements: purpose, search scope, and output behavior (sorted by relevance). It does not explain the return format or limits, but for a search tool of this complexity, the description is sufficiently complete. Slightly better than a bare minimum because it articulates the relevance ordering.
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% for the single 'query' parameter, which provides the baseline of 3. The description adds extra semantic meaning by stating the query is matched against paths, descriptions, and tags, clarifying how the parameter is used beyond the simple 'terme de recherche' (search term) in the schema.
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 a specific verb+resource combination ('Recherche des endpoints' = search endpoints), and specifies the search scope ('par mot-clé dans les chemins, descriptions, tags' = keyword in paths, descriptions, tags). This distinguishes it from sibling tools like listEndpoints (list all) or getEndpointsByTag (filter by tag), as it is a keyword-based search across multiple fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to find endpoints by keyword, with the search fields explicitly listed. However, it does not explicitly state when not to use it or mention alternatives (e.g., 'use listEndpoints to list all endpoints'). The context is clear but lacks explicit exclusions, placing it a notch below a perfect 5.
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:

[![mcp-swagger MCP server](https://glama.ai/mcp/servers/awssam/mcp-swagger/badges/card.svg)](https://glama.ai/mcp/servers/awssam/mcp-swagger)

Score Badge

Copy to your README.md:

[![mcp-swagger MCP server](https://glama.ai/mcp/servers/awssam/mcp-swagger/badges/score.svg)](https://glama.ai/mcp/servers/awssam/mcp-swagger)

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/awssam/mcp-swagger'

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