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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds substantial behavior details: the async mode with job_id polling, specific AAOIFI ratio thresholds (debt/market-cap <30%, etc.), output fields (compliance_status, purification_pct, P0/P1/P2 signals, quality_score, sources), and the list of prohibited activities. This explains beyond what annotations already cover and does not contradict them.

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 clear sections: audience, standards, four modes with bullet points, prohibited activities, and output summary. It is dense but every sentence conveys useful information—no fluff. The use of headers and bullets makes it easy to scan while remaining relatively short for the amount of 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 complex tool with four modes and four standards, the description covers all invocation paths, explains the default standard, contains the full list of prohibited activities, and outlines the expected output fields. The async behavior is fully disclosed. An output schema exists, so return values need no further explanation. There are no critical gaps.

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?

The input schema already provides 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds richer meaning by explaining each mode's purpose in more detail, expanding on the default standard (AAOIFI) as 'most conservative, widely accepted,' and giving concrete examples of queries (e.g., 'Aramco', 'AAPL', 'tobacco'). This goes beyond the schema without redundancy.

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 opens by stating it is a 'Sharia compliance screening engine' for Islamic banks, Sukuk issuers, Gulf sovereign funds, and related entities, which is a specific verb+resource+scope. It lists four distinct modes and explicitly claims 'Zero competing MCP on this vertical,' clearly distinguishing it from any sibling tool.

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 provides clear context on when to use each mode (company, instrument, sector_screen, financial_ratios) and which standards are available. However, it does not explicitly name alternative tools or state when not to use this tool, relying instead on the 'Zero competing MCP' assertion. This meets the 'clear context, no exclusions' bar but stops short of the full when/when-not guidance.

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