search_payment_items

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

Since no annotations are provided, the description carries full responsibility and it does so thoroughly. It discloses the pagination limit, that results contain only summaries, that returned content is raw official data rather than AI instructions, and that patient data must not be entered. This gives an agent substantial operational context beyond the schema.

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 declaration is compact and front-loaded with the most important constraints and usage rules. Every clause serves a purpose: safety status, pagination behavior, alternative single-item routes, and output semantics. No filler is present.

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 the tool's moderate complexity, an output schema exists and the description covers the missing operational details: pagination, summary-only results, the correct sibling for full details, and intended/non-intended uses. This is sufficient for an agent to select and invoke the tool correctly.

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?

Schema description coverage is 0%, so the description must compensate; it meaningfully explains limit and offset behavior ('搜尋結果一次最多 5 筆' and '要看更多用 offset 翻頁'). The query parameter remains implicit beyond the verb 'Search', so it does not fully document all parameters, but it adds real semantic value over the empty schema.

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 action ('Search the current NHI table') and names concrete behavior (returns summary listings). It also differentiates itself from single-item lookups by directing users to get_payment_rule or get_points for full remarks, so an agent can distinguish this search tool from its siblings.

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 is explicit about how to use the tool: results are capped at 5, use offset for pagination, and single-item details should go through get_payment_rule or get_points. It also provides context for when NOT to rely on it by declaring it is not validated for hospital deployment and not for claim determination.

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