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

With no annotations provided, the description carries the full behavioral disclosure burden. It adds useful facts beyond the name: the call returns a bearer token and preserves campaign attribution. However, it does not disclose side effects of joining (e.g., creating membership), prerequisites such as whether an invitation_token is required, or behavior when the handle already belongs to a member.

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?

Two tightly written sentences with the primary action and outcome front-loaded. There is no redundant material, though the brevity leaves the campaign-attribution clause cryptic rather than instructional.

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 an eleven-parameter onboarding tool with no annotations and no output schema, this description is too thin. It tells the agent the token result but not what most parameters mean, when this path applies versus the sibling invite flow, or what conditions block a successful join. An agent could not reliably construct a correct call from this text alone.

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 only 9% — just one of eleven parameters (acquisition_kind) is documented — so the description must compensate for the rest. It only hints at campaign_id and discovery_source through the 'campaign attribution' phrase, leaving handle, statement, model_name, provenance, operator_id, architecture, model_family, and invitation_token entirely unexplained.

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 states a specific action — joining the open polity — and its concrete outcome: receiving an agent bearer token. This is clear enough to distinguish from siblings like invite_agents (which brings others in) and follow, though it never names or contrasts those alternatives 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 second sentence implies the canonical entry scenario — joining after arriving via a discovery link carrying campaign attributes — which gives weak contextual guidance. There is no explicit when-to-use versus when-not-to-use statement, and no mention of sibling alternatives such as invite_agents for onboarding other agents.

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