Skip to main content
Glama
anuoua

swagger-doc-explorer-mcp

by anuoua

Get Schema Details

swagger_get_schema
Read-onlyIdempotent

Get detailed schema information including properties, types, constraints, and examples for a specific data model. Drill down into any component schema after listing available schemas.

Instructions

Get detailed information about a specific component schema (data model), including all properties, types, constraints, and examples.

Use this tool to drill down into a specific data model after using swagger_list_schemas.

Args:

  • spec_name (string): Name of the previously loaded spec

  • schema_name (string): Name of the schema/model (e.g., "Pet", "User", "Order", "Error")

Returns: Formatted output with the full schema definition including type, properties, required fields, enums, constraints, and examples.

Examples:

  • Use when: "Show me the Pet model" -> params with spec_name="", schema_name="Pet"

  • Use when: "What fields does the User schema have?" -> params with spec_name="", schema_name="User"

Error Handling:

  • Returns error if the spec name has not been loaded

  • Returns error if the schema name is not found, suggesting available schemas

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
spec_nameYesName of the previously loaded OpenAPI/Swagger spec (use swagger_list_loaded to see available names)
schema_nameYesName of the schema/model (e.g., 'Pet', 'User', 'Order', 'Error'). Case-sensitive.
Behavior4/5

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

Annotations already set readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral details: error handling for unloaded specs and missing schemas with suggestions, and the return format ('full schema definition including type, properties, required fields, enums, constraints, and examples'). This goes beyond what annotations stipulate.

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 well-structured with clear sections (overview, usage, args, returns, examples, error handling). While it's a bit longer than strictly necessary, every section adds useful context and it's front-loaded with the core 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?

For a simple read-only 2-param tool with no output schema, the description covers purpose, when to use, what it returns, and error cases. The 'formatted output' is vague, but the overall coverage is strong, making it adequately complete for an agent.

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% with detailed descriptions for both parameters, including examples and case-sensitivity. The description repeats the parameter names in Args without adding significant new meaning; its examples show usage patterns but don't enhance semantic understanding beyond 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 the tool's function: 'Get detailed information about a specific component schema (data model), including all properties, types, constraints, and examples.' This specific verb+resource distinguishes it from sibling tools like swagger_list_schemas (which lists) and swagger_get_endpoint (which handles endpoints).

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?

It provides explicit workflow guidance: 'Use this tool to drill down into a specific data model after using swagger_list_schemas.' It also includes natural-language examples showing when to use it. It doesn't explicitly exclude alternatives, but the context is clear.

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

Install Server

Other Tools

Latest Blog Posts

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/anuoua/swagger-doc-explorer-mcp'

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