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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false), and the description adds substantial context beyond them: the GDPR data-minimisation scope (only the current role is stored — no photos, About text, education, skills, earlier jobs, or contact details), the fact that each call is a real LinkedIn profile view with an 8-contact cap, and that it returns per-contact status. Nothing contradicts the annotations.

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?

Front-loads the purpose, then layers data-scope, usage, batch limit, and return value. Every sentence carries useful information, though the enumerated GDPR exclusion list makes it slightly longer than strictly necessary.

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 2-parameter mutation with no output schema, the description covers the mutation effect, the storage scope, the LinkedIn-view cost and batch cap, the sequencing relative to search_google_xray, and the return shape ('per-contact enrichment status'). An agent has everything needed to invoke it correctly.

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 coverage is 100%, so the schema already documents both contact_ids and profile_id (UUID, defaults to active profile). The description repeats the max-8 constraint on contact_ids but adds no new semantics for profile_id or the ID format, so the baseline of 3 applies.

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 specific verb (enrich), resource (existing contacts), source (their LinkedIn profile via the connected account), and the exact fields saved (current company, position, headline, location). The purpose is unambiguous and clearly distinct from company-enrichment siblings like enrich_crm_company_ares, though it never explicitly contrasts itself with contact-mutating siblings such as update_contact or upsert_linkedin_contact.

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?

Gives a concrete workflow context: 'Use after search_google_xray to confirm the current employer of lightly-saved leads,' naming a sibling and the scenario that selects this tool. It also warns 'keep batches small; max 8 per call.' No explicit when-not-to-use or alternative-tool exclusion is given, so it stops short of a 5.

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