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

Only destructiveHint is annotated, so the description carries most of the burden and does so richly: nothing is sent, the result contains an accept_url, the sign-up token is valid 14 days and bound to the email, the invitee must sign in with that exact address and consent, and a ChatGPT connector refresh is required after acceptance. The replaces_member_id behavior (old pending invitation cancelled, link disabled, notice marked done) is also disclosed.

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 core action and the Slack-workspace disambiguation, then layers constraints. Dense but every sentence adds operative detail; the multi-clause final sentence is somewhat heavy but still purposeful.

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?

No output schema exists, yet the description explains the return shape (accept_url) and downstream consequences of the invite lifecycle, including the token validity and consent requirement. An agent has everything needed to call it correctly and advise the invitee.

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 100% and the schema already documents project_id omission and replaces_member_id's requirement of project_id plus the cancellation semantics. The description mostly restates that, adding only the workflow framing of pulling the address from a reinvite_requested notice, so baseline 3 is appropriate.

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 and resource (invite a person by email into a shared project) and explicitly disambiguates from the obvious confusion — a Slack workspace. It also distinguishes itself from the sibling cancel/leave shared project tools by naming what it creates and what it does not.

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 clear conditions: omit project_id to create a new two-person project, and use replaces_member_id when answering a reinvite_requested notice. It points to send_message as the delivery channel for accept_url. It lacks explicit when-not guidance relative to cancel_shared_project_invite, but the reinvite workflow covers the main routing decision.

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