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

With no annotations provided, the description carries the full burden and does well: it discloses that a login token or bound cloud-marketplace credential is required, that unauthenticated calls return 401, and that an unbound instance returns code=40003 with data.bindUrl. It does not describe the shape or size of the 'structured health profile' returned, which is the remaining gap.

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 purpose and the login requirement are front-loaded, and the error semantics are stated compactly. The login requirement is stated twice (the '[需要登录]' prefix and the 鉴权 paragraph), a minor redundancy in an otherwise tight definition.

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?

Auth and error behavior are covered thoroughly, which is the hardest part for a gated read tool with no annotations and no output schema. Still missing: any hint of what the profile payload contains or its size, and disambiguation of the duplicated contactId/contactid parameters, both of which an agent needs to call this confidently.

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%, so the description must compensate; it does explain that contactid identifies the target contact and is optional, defaulting to the caller. It does not resolve the schema's real ambiguity, however: two near-duplicate fields, 'contactId' and 'contactid', with no statement of which is authoritative or whether they are interchangeable.

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 gives a specific verb and resource: retrieve a contact's structured health profile by contactid, and states that omitting contactid returns the caller's own profile. That is unmistakably distinct from contact_profile_save (write) and contact_get (basic contact record), although no sibling is named explicitly.

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 conditional 'if contactid is not passed, read the current user's own profile' is a genuine usage rule, and the login requirement gates invocation. However, there is no guidance on when to prefer this over contact_get or corp_contact, so the agent must infer the boundary from names alone.

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