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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the data source ('FINRA BrokerCheck public API') and 'No API key required,' which together set auth and provenance expectations. Rate-limit or latency behavior is not disclosed, but for a non-destructive, idempotent read that gap is 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?

The description is compact and front-loaded: purpose sentence, return-content sentence, bulleted usage triggers, then a source/auth footer. Every sentence earns its place — bullet 2 reuses return-content themes but reframes them as a decision trigger, so even the mild overlap is functional. The structure makes decision-relevant information immediately visible.

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?

With an output schema present and safety annotations complete, the description covers the core invocation path fully and adds source and auth context. The main weaknesses are the absence of when-not-to-use guidance and a mild coherence issue: several schema parameters (wholesaler_ids, mcp_prompt_id) describe an internal 'fin' user-role system that sits oddly next to the 'public API, no API key required' framing. Still, none of these parameters are required, so correct invocation with just a CRD is fully supported.

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 description identifies CRD as the key input and its provenance ('from SearchBrokerCheck'), and clarifies that it targets one individual, which helps invoke the tool correctly. However, the schema itself already documents crd with nearly identical guidance, so the description adds modest value; the remaining parameters (wholesaler_ids, exclude_fillers, etc.) are documented only in the schema, never in the description. Although the context signal reports 0% schema coverage at the top level, the nested properties are themselves richly described, so the schema carries most of the parameter-semantics burden.

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 with a specific verb and resource: 'Retrieve the full FINRA BrokerCheck profile for one individual using their CRD number.' It enumerates returned content (employment history, exam qualifications, licenses, disclosures), and the 'one individual' scope plus 'FINRA BrokerCheck' qualifier separates it from firm-level and IAPD sibling tools. It also explicitly ties to SearchBrokerCheck, distinguishing detail-fetch from search.

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?

A dedicated 'Use this tool when' section gives three concrete triggers: having a CRD from SearchBrokerCheck, needing employment/qualification data, and performing individual due diligence. It does not explicitly state when not to use it or name excludable alternatives (e.g., GetIAPDIndividualDetail for SEC profiles), but the when-to conditions are specific enough to route an agent correctly.

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