join_planJoin a plan as the person you act for. If a participant with the same name already exists, you act as them (like picking your name in the app). Returns participant_id and participant_token. Confirm the name with the user first.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The person's name as the group knows them (max 80 chars). | |
| plan | Yes | Plan link (e.g. https://lesgooo.fun/ab12/when) or its 4-character id. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as idempotent and non-destructive, and the description adds concrete behavioral detail: same-name participants are reused, and participant_id plus participant_token are returned. This enriches the annotation without contradicting it. It doesn't mention failure cases, but with annotations present the bar is lower.
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?
Three terse sentences, each carrying distinct value: the core action, the idempotency behavior and return value, and a user-confirmation instruction. No redundant phrasing or repetition of schema details.
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?
The absence of an output schema is compensated by explicitly listing returned fields. The subtle same-name reuse behavior is disclosed, and the user-confirmation requirement covers an important interaction driver. Nothing needed to call the tool correctly seems missing.
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 coverage is 100%, so both parameters are already documented. The description adds value by directing the agent to confirm the name with the user first)Skip, which is user-oriented semantic guidance beyond the schema's string type.
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 starts with a clear verb+resource pair ('Join a plan') and adds essential scope ('as the person you act for'). It does not explicitly differentiate from siblings like set_rsvp or create_plan, so it falls short of a 5, but the purpose is unambiguous.
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 description provides clear context for when to use the tool – joining a plan on behalf of someone, with the caveat to confirm the name first. It does not state exclusions or name alternatives, so it stops at 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.