Prepare your RSVP for review and explicit confirmation on MYOPL. This call does not change an RSVP.
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | Exact MYOPL league slug from its link, for a league the signed-in account belongs to. | |
| response | Yes | Proposed attendance: yes to attend, maybe if undecided, or no to decline. The owner confirms on MYOPL. |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / descriptionAdded value: +"Arguments for prepare_my_rsvp."Input schema / properties / league / descriptionAdded value: +"Exact MYOPL league slug from its link, for a league the signed-in account belongs to."Input schema / properties / response / descriptionAdded value: +"Proposed attendance: yes to attend, maybe if undecided, or no to decline. The owner confirms on MYOPL."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "description": "MYOPL structured response for prepare_my_rsvp.",
+ "oneOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "action_id": {
+ "description": "Identifier to pass to get_my_action_status for this connection.",
+ "pattern": "^[A-Za-z0-9]{64}$",
+ "type": "string"
+ },
+ "confirmation_url": {
+ "description": "MYOPL page where the owner reviews and confirms the RSVP.",
+ "format": "uri",
+ "type": "string"
+ },
+ "expires_in": {
+ "description": "Seconds until this preparation expires.",
+ "minimum": 1,
+ "type": "integer"
+ },
+ "guidance": {
+ "description": "Instructions for presenting the confirmation step.",
+ "type": "string"
+ },
+ "status": {
+ "const": "confirmation_required",
+ "description": "The RSVP awaits the account owner's confirmation.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "status",
+ "action_id",
+ "confirmation_url",
+ "expires_in",
+ "guidance"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "error": {
+ "description": "Tool execution or argument error; the enclosing result has isError set to true.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false the description usefully reassures that no RSVP is actually changed, consistent with destructiveHint=false. But it leaves the real side effect unexplained: if the call is not read-only yet changes no RSVP, what does it write (a pending proposal, a token, a draft)? No auth or rate-limit context either.
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 short sentences with zero boilerplate; the non-mutation guarantee is front-loaded immediately after the purpose so the agent sees the key constraint at a glance.
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?
An output schema exists, so return values need no explanation, and both required params are documented. The workflow (stage now, owner confirms later) is covered; the only real gap is the precise state effect of a non-read-only call.
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%, so both 'league' and 'response' are fully documented in the schema, including the enum meanings and the league slug constraint. The description adds no parameter-level detail, which is the correct baseline when the schema already carries the semantics.
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 ('prepare') and resource ('RSVP') and clarifies the outcome: it stages an RSVP for review and confirmation on MYOPL rather than applying it. It is distinguishable from the get_my_* siblings, though it never names them or explains exactly what artifact the call produces.
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?
Usage is implied by 'Prepare your RSVP for review and explicit confirmation' — you call this before the owner confirms. However, no explicit when-to-use condition or alternative is named, and 'This call does not change an RSVP' only hints that a different step (the MYOPL confirmation) performs the actual change.
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.