Compare a real HTTP request/response against an OpenAPI spec contract. Returns per-field violations.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | OpenAPI spec JSON object | |
| request | Yes | HTTP request to validate | |
| response | No | HTTP response to validate (optional) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / request / descriptionPrevious value: -"검증할 HTTP 요청"New value: +"HTTP request to validate"Input schema / properties / request / properties / body / descriptionPrevious value: -"요청 바디"New value: +"Request body"Input schema / properties / request / properties / contentType / descriptionPrevious value: -"요청 Content-Type (기본값: application/json)"New value: +"Content-Type (default: application/json)"Input schema / properties / request / properties / method / descriptionPrevious value: -"HTTP 메서드 (GET, POST, ...)"New value: +"HTTP method"Input schema / properties / request / properties / params / properties / path / descriptionRemoved value: -"경로 파라미터"Input schema / properties / request / properties / params / properties / query / descriptionRemoved value: -"쿼리 파라미터"Input schema / properties / request / properties / path / descriptionPrevious value: -"요청 경로 (예: /users/123)"New value: +"Request path (e.g. /users/123)"Input schema / properties / response / descriptionPrevious value: -"검증할 HTTP 응답 (선택)"New value: +"HTTP response to validate (optional)"Input schema / properties / response / properties / body / descriptionRemoved value: -"응답 바디"Input schema / properties / response / properties / contentType / descriptionRemoved value: -"응답 Content-Type"Input schema / properties / response / properties / statusCode / descriptionRemoved value: -"HTTP 상태 코드"Input schema / properties / spec / descriptionPrevious value: -"OpenAPI 스펙 JSON 객체"New value: +"OpenAPI spec JSON object"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 the core output behavior ('Returns per-field violations') and implies a read-only comparison operation. However, it does not mention potential side effects, whether the spec must be valid first, error handling, or limitations (e.g., only validates request/response objects, not headers or metadata). This is a minimal but not misleading disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and then the output. Every word earns its place, with no fluff or redundancy. It is highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, one optional, nested objects) and no output schema, the description provides enough context to understand the tool's role. It could be enhanced by elaborating on the structure of 'per-field violations' or clarifying that the response is optional, but the schema already covers the input shape. The description is adequate for a developer familiar with OpenAPI concepts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (spec, request, response) already described in the schema. The description adds no additional parameter semantics, but the baseline of 3 is appropriate since the schema fully documents the inputs and their structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare a real HTTP request/response against an OpenAPI spec contract.' It names the specific verb (compare) and resource (HTTP request/response vs OpenAPI spec), and distinguishes it from sibling tools like validate_openapi_spec (which validates the spec itself) and check_breaking_changes (which checks compatibility).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the alternatives. It does not mention that this is for validating actual traffic against a contract, nor does it exclude cases where the user should instead validate the spec itself or check breaking changes. Sibling tool names are present but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct purpose: validation, linting, breaking change detection, request/response diffing, and mock generation. There is no overlap or ambiguity between them.
All tools follow a consistent verb_noun snake_case pattern (check_, diff_, generate_, lint_, validate_), making the naming predictable and easy to navigate.
With 5 tools, the set is well-scoped for an API contract validator. Each tool covers a distinct aspect of specification validation and testing without excess or redundancy.
The toolset comprehensively covers the core domain: structural validation, linting, breaking change detection, runtime request/response validation, and mock generation. No obvious gaps remain for typical contract-validation workflows.