Browse Bidwell services and states
list_care_optionsRead Bidwell Health’s public catalogue, including paused services. No personal information is needed.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
list_care_optionsRead Bidwell Health’s public catalogue, including paused services. No personal information is needed.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds genuinely useful context beyond them: the catalogue is public, requires no personal information (no auth), and crucially includes paused services that a naive caller might assume are filtered out.
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?
Two short sentences, front-loaded with the core action and resource, with the non-obvious detail (paused services, no PII) stated immediately. No filler.
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?
For a zero-parameter, read-only listing tool with rich annotations, the definition is nearly complete. It lacks any hint of the return shape or pagination, which matters somewhat since no output schema exists, but the gap is minor given the tool's simplicity.
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?
The tool takes zero parameters, so the baseline is 4. The description corroborates this by stating no personal information is needed, which is consistent with an input-free call.
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 states a specific verb and resource: "Read Bidwell Health's public catalogue," and it adds scope by noting paused services are included. It does not, however, differentiate itself from sibling listing/detail tools such as get_service_details, get_service_page, or check_service_availability.
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 phrase "No personal information is needed" hints that this is a safe, unauthenticated browse operation, implying when it applies. But there is no explicit statement of when to use this over get_service_details or the availability check, so usage is only implied.
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.