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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: it is 'source-backed', returns 'known information gaps', and is positioned as a structured decision-support pass. This communicates investigative rather than authoritative-exhaustive behavior.

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?

Two sentences, front-loaded with the core action and outputs, followed by concrete use cases. The text is compact and every clause adds selection or invocation value, despite minor repetition of 'structured' and 'ahead of'.

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 an output schema and read-only/idempotent annotations, the description covers the main invocation decision well: what it does, what it returns, and when to use it. It could be more complete by addressing the optional transactionValueOMR parameter and explicitly steering away from lighter-weight siblings like get_oman_company_profile.

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 directly names companyId and indirectly explains transactionType by mapping 'contract, partnership, extending credit, investing' to the enum values. However, it says nothing about transactionValueOMR, leaving one parameter without added semantic guidance.

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 uses a specific verb-resource pair: 'Perform structured commercial due diligence on one Oman company by companyId.' It also names the concrete outputs—identity verification, risk assessment, prioritized checklist, and known information gaps—which clearly distinguishes it from profile-retrieval or general-analysis 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 gives explicit use contexts: before awarding a contract, entering a partnership, extending credit, or investing, when a structured due-diligence pass is needed. It does not explicitly mention when not to use it or name alternative sibling tools, so it falls just short of a 5.

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