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

No annotations are provided, so the description carries the burden of behavioral disclosure. It notes that the profile 'follows them across companies' and defaults to the caller, which adds meaningful context. However, it doesn't explicitly state that the operation is read-only or describe authorization requirements beyond what the schema implies. Since 'Get' suggests a safe read, this is adequate but not exhaustive.

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 four short sentences, each carrying distinct information: what it returns, cross-company scope, when to use it, and how to target another person. It is front-loaded and every sentence earns its place with no wasted words.

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?

Since there is no output schema, the description explains the return value: 'overall character level + per-topic strengths (novice/fluent/expert).' It also covers primary usage, default behavior, and cross-company persistence. It could mention potential errors or permission requirements, but for a simple getter this is sufficient.

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 schema covers both parameters with detailed descriptions (companyId is required; member_id is optional and defaults to ctx.userId). The description restates the defaulting behavior but adds no new semantics beyond the schema. With 100% schema description coverage, this matches the baseline of 3.

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 clearly identifies the tool as retrieving a person's operator fluency/reader profile, including overall level and per-topic strengths. It distinguishes itself from sibling tools like get_voice_profile or get_my_profile by specifying the exact resource (reader profile) and the data returned.

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 a concrete use case: 'Use before writing cards/FYIs so speech matches their level.' It also explains default behavior and how to query another person via member_id. It doesn't explicitly name alternatives or when not to use, but the context is clear enough.

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