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

With no annotations, the description carries the full burden and does well: it discloses the budget/rate cost, warns against bulk looping, and flags that any returned email is an UNVERIFIED pattern guess keyed to email_confidence=pattern_guess. It does not cover auth requirements or failure behavior on invalid/non-profile URLs.

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?

Three sentences, front-loaded with the returned fields, then the email caveat, then the cost warning. Every sentence adds information an agent needs and none is redundant.

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 no output schema, the description usefully enumerates the return fields and the confidence semantics of the suggested email, plus the budget cost. What is missing is any note on invalid-URL handling or how the unverified email should be treated downstream.

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 0% for the single parameter, so the description must compensate, and it does by specifying the expected URL shape (linkedin.com/in/...). It could still clarify whether only profile URLs are accepted or whether company URLs are rejected, but the format guidance is meaningful.

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?

It states a specific verb and resource ('Fetch ... for a linkedin.com/in/... URL') and enumerates exactly which fields come back (name, title, employer, avatar, location). This leaves no ambiguity about what the tool produces, though it never names a sibling it should be chosen over (e.g. sdr_get_person_detail).

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?

It gives concrete invocation constraints that function as usage guidance: the call costs one profile view from the workspace's shared daily LinkedIn budget and should not be looped over large lists. It stops short of stating when to prefer this over the SDR person-detail siblings, so it is clear context without explicit alternatives.

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