Skip to main content
Glama
HakashiKatake

docorbit

by HakashiKatake
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

find_api

Search OpenAPI endpoints by path, operation ID, or keyword to retrieve exact parameters, schemas, authentication, and error responses.

Instructions

Lookup structured OpenAPI endpoints by path, operation ID, or keyword with exact parameters, schemas, auth, and error responses.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of endpoints to return (default: 5).
queryYesAPI path or keyword search (e.g. "/v1/webhook_endpoints", "create subscription").
formatNoResponse format: "markdown" (default, human/agent-readable documentation) or "json" (structured raw machine data).
methodNoHTTP method filter (e.g. "get", "post", "delete").
versionNoTarget API / documentation version filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.3
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Response format: \"markdown\" (default, human/agent-readable documentation) or \"json\" (structured raw machine data).",
+  "enum": [
+    "markdown",
+    "json"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.4

TDQS

B3.2/5.0
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 behavioral burden. It usefully discloses what the lookup returns (parameters, schemas, auth, error responses), and 'lookup' implies a read-only operation, but it says nothing about pagination, result limits beyond the schema default, or rate/permission 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?

A single well-packed sentence with the verb and resource front-loaded and no filler. It is appropriately sized, though the trailing enumeration of return fields makes it slightly run-on rather than crisply 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?

For a five-parameter read tool with no annotations and no output schema, the description covers the purpose and the shape of the return payload, which is the main gap to fill. It does not help with tool selection against its many siblings, so an agent still lacks the routing context needed to use it confidently.

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%, so the baseline is 3. The description does add a bit of meaning by naming the lookup modes (path, operation ID, keyword) that the 'query' parameter accepts, but it contributes nothing about method, version, format, or limit beyond what the schema already documents.

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?

States a specific verb ('lookup') and resource ('structured OpenAPI endpoints') and enumerates the lookup keys (path, operation ID, keyword) plus what comes back (parameters, schemas, auth, error responses). It reads as API-reference-specific, which loosely separates it from search_docs, but it never explicitly names or contrasts a sibling like check_api or search_docs.

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 when-to-use, when-not-to-use, or alternative routing guidance. With overlapping siblings such as check_api, search_docs, and get_documentation_map, the agent is left to infer when find_api is the right call.

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

Deploy Server

Other Tools