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

Annotations already cover read-only/idempotent/no-destruction, so the description earns credit for the extra semantics it adds: the exact CMS baseline (FULL NCCI PTP, 2026q3 v322r0) rather than a rolling change window, and the crucial interpretation that an empty result means no PTP edit was ever recorded. It doesn't independently disclose auth or rate-limit behavior, but for a read-only lookup that's minor.

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?

Front-loaded with the core question it answers, followed by examples and then the baseline caveat. Every sentence carries information, though the parenthetical about the FULL baseline vs. rolling window is dense and somewhat runs on within one sentence.

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?

There is no output schema, but the description compensates by naming what comes back (paired codes, orientation, modifier indicator) and by defining the empty-result semantics. Combined with the explicit dataset scope, an agent has enough to select and interpret the call, leaving only return formatting/pagination unspecified.

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 coverage is 100%, so code, status, and setting are already documented in the schema; the description adds conceptual grounding (Column 1/Column 2, modifier indicator) but no further per-parameter syntax or defaults. Baseline 3 applies when the schema carries the parameter detail.

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?

States a specific verb and resource — surface NCCI procedure-to-procedure PTP edits for one HCPCS/CPT code — and explains the Column 1 / Column 2 orientation so the result shape is predictable. It explicitly distinguishes itself from the sibling check_code_pair by framing this as the single-code lookup against the same baseline.

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?

Gives three concrete trigger questions ("what codes conflict with 99214", "what is bundled into this procedure", denial diagnosis) that map to the agent's intent space, and clarifies its relationship to check_code_pair. It stops short of an explicit when-not rule (e.g., use check_code_pair when you already have both codes), so it's strong context without full exclusivity guidance.

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