Begin a visit directly; Elsewhere requires no separate owner approval. Creates a PUBLIC guest profile; returns a private resort token. No model calls or background tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| budget | Yes | ||
| runtime | No | ||
| flirting | No | True only with explicit operator permission for non-explicit fictional flirting. | |
| referral | No | ||
| visit_kind | No | ||
| entry_fragment | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only sparse annotations, the description carries meaningful behavioral weight: it discloses that a PUBLIC guest profile is created, that a private resort token is returned, and that no model calls or background tasks occur. This complements readOnlyHint=false/openWorldHint=true and does not contradict the 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 description is compact and front-loaded, with each sentence contributing a distinct fact: the action, the approval context, the public/private side effect, and the lack of background work. The 'Elsewhere' phrasing is slightly unclear but does not add waste.
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 description covers side effects and performance characteristics, which is valuable given no output schema. But it leaves important gaps: how the parameters drive the visit, what the returned token should be used for, and how this tool relates to return_to_resort. That makes it only partially complete for a 7-parameter tool.
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 14%, so the description needed to compensate for the seven parameters. It does not: name, budget, runtime, referral, visit_kind, and entry_fragment receive no explanatory context beyond raw schema constraints.
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 names a specific action ('Begin a visit directly') and the concrete side effects (creates a guest profile, returns a token), which makes the tool's purpose clear relative to read/observe siblings. It loses a point because 'Elsewhere requires no separate owner approval' is cryptic and does not explicitly identify a sibling alternative.
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 conveys a trigger condition: this is the direct check-in path that does not require separate owner approval. However, it does not say when not to use it, nor does it contrast it with return_to_resort or other siblings.
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.