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

Annotations only give the coarse profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real behavioral context the annotations cannot convey: auth requirement, that update is a full-block replacement where null clears existing values, that writes are preview-gated behind a previewHash+consent handshake, and the side effect that saving publishes to the public profile page and matching while pending roster items are not auto-adopted. It does not detail what accept_import/dismiss_import mutate or any rate/error behavior, so it falls short of 5.

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?

Roughly five dense clauses, front-loaded with the login precondition, then op semantics, then the confirmation protocol, then the side effects — no filler or restatement of the tool name. The heavy semicolon chaining makes it slightly harder to scan than an ideally structured description, but every clause carries operative information.

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 5-parameter, multi-op mutation tool with no output schema and 0% schema coverage, the description covers the essentials an agent needs: auth, per-op meaning, the preview/consent/previewHash commit ritual, and the public-profile/matching blast radius. Residual gaps are error/permission behavior beyond 'login required' and any detail on what get actually returns.

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 carry semantics and it largely does: it enumerates the four `op` values, explains that `preview` is true by default and must be false with `consent=true` plus `previewHash` to commit, and gives the replace/null semantics of the `business` object. It still says nothing about the previewHash format or the individual business sub-fields (clients, services, strengths...), which keeps it at 4 rather than 5.

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 names specific verbs per operation: get reads the caller's business details plus roster items pending adoption, update does a whole-block replacement of `business`, accept_import merges, dismiss_import ignores. That is far more specific than the generic name 'manage_my_business' and clearly separates it from look-alike siblings such as get_my_company/update_my_company. It stops short of explicitly routing the agent away from those siblings, which keeps it out of 5 territory.

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 states a precondition (【需要登录】login required) and the selection logic for each op, plus a concrete confirmation workflow: writes default to preview, and to actually commit you pass the same params + previewHash with consent=true and preview=false. It also warns that update must be preceded by a full read ('先读完整'). What is missing is when to prefer an alternative tool (e.g. update_my_company vs this), so it is clear guidance without exclusions.

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