InPlan

Providers listed in a plan

search_plan_providers

Read-onlyIdempotent

Providers that a Marketplace (ACA) plan's network directory lists, with name, credential, primary specialty, network tiers and up to 5 locations. Filter by state, specialty (substring, e.g. "cardiology"), zip, or zip plus radius in miles. Pages are cursor-based: pass next_cursor back unchanged until it is null; with filters a page can hold fewer than limit providers. Medicare Advantage plans: use check_network or plans_for_provider instead. Needs the Growth plan or higher. Costs 1 call per page.

Input Schema

Name	Required	Description
`zip`	No	5-digit ZIP code, as a string. Optional.
`year`	No	Plan year, e.g. 2026. Optional; by default all plan years we hold are considered.
`limit`	No	Providers per page, 1 to 100. Default 25.
`state`	No	2-letter US state code, e.g. "OH". Optional.
`cursor`	No	next_cursor from the previous page.
`radius`	No	Miles around zip, 1 to 100. Needs zip.
`plan_id`	Yes	Plan ID. Marketplace (ACA) plans: 14 characters like "29276OH0970001" (a 16-character "-01" variant form is accepted). Medicare Advantage plans: "H1234-001-000" (the segment "-000" is optional).
`specialty`	No	Specialty name or part of it, e.g. "family medicine". Optional.

Output Schema

Name	Required	Description
`data`	Yes	The answer. Same shape as the matching InPlan API v1 endpoint.
`notes`	No	How to read the answer.
`sources`	Yes	Source types behind the answer (insurer_directory, plan_directory, provider_registry, plan_catalog), each with its as_of date.
`data_as_of`	Yes	Date (YYYY-MM-DD) of the newest data behind this answer.
`request_id`	Yes	Request id; quote it when you contact support.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds material context: cursor pagination semantics (pass next_cursor back unchanged until null), that filtered pages may hold fewer than limit, a per-page cost of 1 call, and a plan-tier requirement. These are exactly the operational facts annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single tight paragraph, front-loaded with what is returned, then filters, then pagination, then the sibling routing and cost. Every sentence carries distinct information with no repetition of the title.

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?

Despite 8 parameters and an output schema, the description covers the decision-relevant gaps: return fields, filter behavior, pagination, cost, and access tier. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description earns extra by explaining filter semantics the schema leaves implicit — specialty is a substring match with an example, radius requires zip, and cursor must be echoed unchanged. It doesn't cover year or limit defaults, which the schema already handles.

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?

Opens with a specific verb+resource+scope: providers listed in a Marketplace (ACA) plan's network directory, and names the returned fields. It explicitly contrasts itself with check_network and plans_for_provider for Medicare Advantage plans, so an agent can distinguish it from all siblings.

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?

Gives explicit when-to-use conditions (ACA plans), when-not-to-use plus named alternatives (Medicare Advantage → check_network or plans_for_provider), and prerequisites (Growth plan or higher). It also states which filters exist and that a filtered page can be short.

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

All InPlan 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?