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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful operational behavior: the data source (SEC EDGAR), a $0.02 USDC cost per call, and a post-quantum signed settlement receipt with verification URL. It does not describe exact output structure or error behavior, but the core read-only nature is reinforced.

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: primary purpose first, scope and return content second, then source, attestation, verification, and cost. Every fragment adds useful information and there is no redundant or filler text.

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 one-parameter read-only tool with no output schema, the description covers what data is returned (filings, dates, links, signal), the lookback window, source, verification, and cost. It does not specify the exact response format or error behavior, but it is sufficient for most selection and invocation decisions.

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?

There is only one parameter, ticker, and the schema provides its name, type, and length but no description. The tool description does not explicitly explain that ticker should be a US-listed company's stock symbol, though the parameter name and SEC Form 4 context make it reasonably self-explanatory. Low schema coverage means the description could compensate more, but the single obvious parameter limits the practical gap.

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 states a specific resource and action: SEC Form 4 insider transaction history for executive buy/sell filings over the last 90 days, including filing dates and links. It is clear what the tool returns. However, it does not explicitly differentiate itself from the related sibling get_sec_beneficial_ownership.

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 90-day window and the mention of an insider activity signal give clear context for when this tool is relevant. It does not state exclusions or name an alternative tool, so it stops short of 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.