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

Annotations mark this as a non-read-only, non-idempotent, open-world write, and the description adds meaningful context beyond that: login is required, the default is a non-committal preview, committing needs consent=true and a previewHash, and cloud users are manually relayed. The caveat that a conversation does not mean acceptance/joining/confirmed availability is valuable expectation-setting not present in 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?

The single dense block front-loads the login requirement and flows from the preview default to kind-specific params to the submit contract. Every clause carries information with almost no filler, though the semicolon-packed style is heavy and could be broken into clearer segments.

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 12-parameter, 0%-coverage, write-class tool with no output schema, the description covers the trigger (login), the kind-dependent parameters, the two-step commit contract, the cloud-user path, and the key expectation caveat. Return values are not described, but with no output schema that is not required; the remaining gap is the lack of explicit alternatives to call instead.

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 the burden, and it largely does: it explains targetUserId's role for groups (owner/admin/invitable person), that startsAt/endsAt carry a timezone, and the roles of activityId, headcount, spaceName, previewHash, consent and preview. It omits semantics for id/kind internals and message limits, so coverage is strong but not exhaustive.

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?

Combined with the title, the description makes clear this tool initiates contact with a group owner or venue provider through a preview-then-submit flow. It specifies a concrete action (preview then contact) on two resource kinds (群/场地), distinguishing the tool from generic messaging siblings. It never states the purpose in one clean sentence, relying on the title to anchor 'what it does', so it is clear but not maximally sharp.

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 spells out the operating procedure: default preview mode, then resubmit with the same params plus previewHash, consent=true and preview=false. It also routes usage by kind (group uses targetUserId; venue uses activityId/startsAt/endsAt/headcount/spaceName). It does not compare against alternatives like request_activity_cloud_contact_requests or start_conversation, so there are no explicit exclusions.

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