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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial operational context on top: automatic normalization of @SYS vs @SYS: label ID forms, the 392K+ entry scale, and the language-loading latency model (en-US/fr at startup, other languages ~15s on first call then instant). This is the kind of behavior an agent needs to anticipate format quirks and timing. No contradiction with annotations.

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 dense but every sentence earns its place: purpose, bidirectional mode, input normalization, scale, workflow, and performance caveat. The WORKFLOW marker gives clear structural segmentation, and core purpose is front-loaded ahead of operational detail.

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 tool with no output schema, the description conveys the core return semantics implicitly (matching label ID or text in all languages) and covers scale, performance, and the recommended downstream call. The only gap is the exact result shape or empty-result behavior, which is minor given the explicit maxResults parameter.

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 the baseline is 3, but the description adds genuine meaning: the query parameter accepts either plain text or a label ID in two interchangeable formats, and the language parameter carries the on-demand loading implication (~15s first call). maxResults semantics are already fully documented in the schema, so no additional value is needed there.

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 first sentence names a specific verb and resource ('Search D365 F&O labels across all indexed languages') and immediately differentiates the tool's two modes: text→label ID and label ID→text. It distinguishes itself from the sibling find_references by positioning itself as the resolution step in a two-stage workflow. No ambiguity about what the tool does.

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 WORKFLOW section explicitly instructs the agent to call search_labels first, then find_references with the same label ID to locate X++ objects — clear routing to the key sibling. It states when to use the tool (resolving label text to IDs and vice versa) but does not provide exclusions for other search siblings like search_d365_code or federated_search.

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