patient_drug_content

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 the automatic YYYYMMDD conversion and lists return fields, which is useful. However, it does not explicitly state that the operation is read-only or describe error behavior, access permissions, or side effects. The verb '取得' implies retrieval but lacks explicit safety disclosure.

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-structured with an introduction, Args, Returns, Example, and internal conversion note. Each section adds value without redundancy. It is front-loaded with the purpose and provides a practical example. Slightly verbose but acceptable for a complex multi-parameter tool.

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?

Given no output schema, the Returns section is valuable. The example gives a concrete calling pattern. The description covers most functional aspects: parameters, return fields, auto-conversion, and a conditional parameter. Missing credential parameter explanations and error handling are minor gaps given the tool's straightforward read-only nature.

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?

With 0% schema coverage, the description must compensate. It explains caseno, dt, type, dept, and dt1 with meanings and formats. However, it completely omits eip_id, eip_password, and hisno, which are required parameters. These are likely common authentication/patient identifiers, but their absence leaves a gap, especially for agents unfamiliar with the system.

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 '取得用藥詳細內容' (get medication details), which is a specific verb+resource. It clearly indicates this tool retrieves detailed drug content for a specific case, distinguishing it from patient_drug_list which returns a list. The example shows a two-step workflow, reinforcing its role as the detail-fetching counterpart.

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 example provides clear usage context: first call patient_drug_list to obtain caseno, then use this tool with those parameters. It also gives conditional guidance for dt1 ('僅住院需要' - only needed for inpatient). However, it does not explicitly contrast with alternative tools or state when not to use it.

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