getCompanyProfile

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered for the agent. The description contributes only a partial picture of the payload ('market capitalization, stock price, industry, and much more') without disclosing whether this is a premium endpoint, what authentication/entitlement is required, or how large/fresh the returned profile is.

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 resource and its scope, with no redundant instructions. The second sentence spends words naming the vendor API and ends in the vague filler 'and much more', which is mild padding but not damaging.

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 lookup with full schema coverage, no output schema, and safety annotations already present, the description supplies enough for correct invocation. The remaining gap is only the unenumerated payload contents and any entitlement caveats, which are secondary for a simple profile fetch.

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 100% for the single 'symbol' parameter, so the schema already carries the semantics and the baseline is 3. The description restates that the symbol identifies a stock but adds no format guidance (exchange suffix, casing, delisted tickers) beyond what the schema provides.

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?

States a clear verb ('Access') and resource ('detailed company profile data') scoped to 'a specific stock symbol', and lists representative fields (market cap, price, industry). However, it never distinguishes itself from near-neighbors in this dense sibling set such as getCompanyProfileByCIK, getCompanyProfilesBulk, or getCompanySymbols.

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 phrase 'for a specific stock symbol' implicitly tells the agent this is the single-symbol lookup and requires a ticker, which argues against the bulk or CIK variants. But there is no explicit when-to-use/when-not guidance and no named alternative, so the routing decision is left to inference.

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