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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds substantially beyond that: deleted documents persist in sources and docs with deleted:true for 30 days so reads and visits keep accumulating, then drop at purge; live documents carry no deleted field; links are capped at 100 with linksTotal giving the real count and viewCount is per-link not per-contact; profile is a stored research result that contacts no outside source; pending is true only while research is queued or running. It also flags untrusted content boundaries, which is operationally important.

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 first clause is front-loaded and correct, but the body is one dense run-on block of nested field explanations with no breaks, mixing return-shape documentation, business rules, and safety notes. Almost every sentence carries real information (justified by the absence of an output schema), so the length is defensible, but the structure makes it hard to scan and re-read.

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 is the only specification of the response, and it covers the significant structures: identity, sources with attribution semantics, lastEmail with status and failure reasons, links with role/viewCount/limit, profile lifecycle statuses, and the 30-day deleted-document behavior. An agent can reason about the result without guessing.

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?

A single parameter with 100% schema coverage, so the baseline is 3. The description only adds provenance ('from lnkdrp_list_contacts'), not format or constraint information beyond the schema's 24-hex-char pattern. Adequate, not additive.

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?

Opens with a specific verb+resource+scope: 'One contact by id (from lnkdrp_list_contacts)', immediately separating it from the bulk lnkdrp_list_contacts sibling and pointing at where the id comes from. It then enumerates exactly what the single record contains (identity, sources, docs, tags, note, links, profile). It stops short of explicitly contrasting with lnkdrp_update_contact or lnkdrp_get_activity, but the read-one-record purpose is unambiguous.

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?

Usage is implied by the parenthetical id source and by the explicit exclusion 'This tool does not start or refresh research', which routes research initiation elsewhere. It also names lnkdrp_restore_doc as the path for restoring purged documents. But there is no direct 'use this rather than X when Y' statement versus siblings like lnkdrp_list_contacts or lnkdrp_get_activity, leaving the agent to infer the choice.

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