Related Servers

Each tool targets a distinct entity (spec, collection, tag, endpoint) and scope (list, get, by_spec, by_tag, etc.) or a distinct action (search, inspect, invoke, info, response_*). The response_* tools are clearly differentiated: outline for structure, slice for extraction, filter for search/pagination, and compress for size reduction. Even the similar endpoint_by_id vs inspect are explicitly separated by 'quick summary' vs 'full technical details'.

The naming follows a strong `resource_by_scope` pattern (e.g., endpoint_by_tag, collection_by_spec, tag_by_id) and consistent action verbs (search, invoke, info). The response_* prefix is uniform. Minor deviations: `spec_list` doesn't follow the `*_by_*` pattern, and `inspect` is an exception to the endpoint detail retrieval naming compared to `endpoint_by_id`.

With 19 tools, this is slightly above the 'well-scoped' range (3–15) and in the 'heavy' band, but the count is justified by the domain: the spec-collection-tag-endpoint hierarchy yields 11 navigation tools, plus essential action tools (search, inspect, invoke, info) and 4 dedicated response-handling tools for large payloads. Each tool earns its place, though scope-combining could reduce redundancy.

The hierarchical navigation is complete: list and get for spec, collection, tag, and endpoint; search for discovery; inspect for full schemas; invoke for execution; and a full response post-processing pipeline (outline → slice/filter/compress). The only notable gap is the absence of a tool to export the raw OpenAPI specification document, but that is not essential for the stated purpose of discovering, inspecting, and invoking endpoints.