request_immunization_resource

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

No annotations are provided, so the description carries the full burden. It discloses critical behaviors: do not guess or auto-fill missing data, require confirmation before deletion, and provide app links rather than API links. It does not cover auth or error behavior, but the key safety-relevant behaviors are well documented.

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?

The description is well-organized with a purpose statement, a rules list, and an Args section. The rules are detailed but each adds operational value, so the length is justified.

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?

The tool has an output schema, and the description covers resource scope, CRUD operations, data fidelity, and deletion confirmation. For a resource-specific CRUD tool with multiple siblings, this is fairly complete, though it omits authentication requirements and explicit handling of the request-wrapping parameter structure.

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 Args section gives useful examples for path (e.g., '/Immunization?patient=Patient/123') and clarifies body usage for POST/PUT. However, it lists method/path/body as top-level arguments and fails to mention the required 'request' wrapper object from the schema, which could lead to incorrect invocation.

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 explicitly states it makes HTTP requests and 'perform[s] CRUD operations only on the FHIR Immunization resource,' using a specific verb and resource. This clearly distinguishes it from sibling tools like request_patient_resource or request_generic_resource.

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 description clearly states when to use the tool: for CRUD operations on the Immunization resource only. It also provides operational rules around creating/updating (use only provided data) and deleting (require user confirmation), but it does not explicitly name alternative tools for non-Immunization resources.

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