API Plan Finder

Ask for a field, provider, condition or plan to be covered

request_coverage

Use this when: a search or check of API plans came back empty or mostly unknown, or the user asks about a field, provider, condition or plan this service does not cover, and you want it to be considered. Do not use this when: plans were found (use them), or to ask a question (nothing is answered). Leave one short line: kind, name and an optional reason. No personal information: it takes no name, e-mail or link and refuses them. It is kept in the server log only and has no reply. Example: 1 search with 3 required conditions came back with 0 plans, and the user needs a condition that is not recorded.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "name": "<name>"
    },
    "name": "request_coverage"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	What is missing: field (a kind of API not compared here), provider, condition (a field of a plan we do not record), plan, or other.
`name`	Yes	The field, provider, condition or plan, as a short name (at most 80 characters). Not a person's name or contact detail.
`reason`	No	Optional. Why it is needed, in one short sentence (at most 200 characters). No personal information.

Output Schema

Name	Required	Description	Default
`kept`	Yes
`note`	No
`received`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the key behavioral traits: the entry lands in the server log only, generates no reply, and personal information is refused. It also specifies the required format ('one short line: kind, name and optional reason'), which is the kind of concrete operational detail annotations cannot carry.

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?

Length is justified for a tool with nuanced when/when-not boundaries, and the structure is front-loaded with use and do-not-use conditions. The trailing example is useful but the prose could be tightened slightly.

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?

An output schema exists, so return values need no explanation, and the description correctly states there is no reply. With annotations covering safety flags and full schema coverage, nothing an agent needs to invoke this correctly is missing.

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?

With 100% schema description coverage across all three parameters (including the kind enum), the schema already carries the semantics, so 3 is the baseline. The description reinforces the intent ('kind, name and an optional reason') and adds the privacy constraint on name/reason, but supplies no format or validation detail beyond the schema.

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 definition makes clear this tool submits a request for missing coverage (field, provider, condition, plan) rather than performing a search or check, and the closing lines state the request is logged with no reply. It distinguishes itself from siblings like search and check_conditions by naming the 'came back empty / not covered' trigger. Purpose is stated through usage framing rather than a direct verb+resource sentence, which slightly blunts it.

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?

'Use this when' enumerates the exact triggers (empty/unknown results from a search or plan check, user asks for something not covered) and 'Do not use this when' explicitly excludes using it when plans were found or to ask a question. The alternative behavior is named inline ('use them'), and a concrete worked example anchors the boundary.

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

All API Plan Finder tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?