Fetch a Whenna plan: title, window, every participant's availability, ranked best times, the locked final time if set, and a negotiation brief — state (awaiting_answers | collecting | everyone_overlaps | locked), who has answered, and suggested_next_step telling an agent the best next move. Poll this between actions when coordinating.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Plan id (the part after /o/ in the link) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the detailed return payload including the state enum, who answered, and suggested_next_step, and advises polling between actions. This adds useful behavioral context about its role as a status-checking tool.
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 front-loaded with the core purpose and uses a structured list for the payload. While slightly long, it is well-organized and every sentence adds value, including the polling guidance.
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 comprehensively covers what the tool returns, including state values and the suggested next step, which is especially valuable given there is no output schema. It sufficiently prepares an agent to interpret and use the response for coordination.
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?
The only parameter 'id' is fully documented in the schema with a clear description ('the part after /o/ in the link'), so the description does not need to add parameter details. Coverage is 100%, earning the baseline of 3.
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 clearly identifies the tool as fetching a Whenna plan and enumerates its contents (title, window, availability, best times, locked time, negotiation brief). This distinguishes it from sibling action tools like whenna_create_plan and whenna_lock_time, which mutate state.
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?
It provides explicit usage guidance: 'Poll this between actions when coordinating,' indicating when the agent should call it. It does not name specific alternatives, but the context implies it is for checking plan state between mutations, which is sufficient.
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.
Each tool targets a distinct action in the scheduling workflow: creating plans, fetching plans, marking availability, viewing best times, locking times, setting location, and creating the next plan. No overlap in purpose.
All tools follow the consistent 'whenna_verb_noun' pattern in snake_case, making it easy to predict the tool for a given action.
With 7 tools, the set covers the essential operations for meeting scheduling without being excessive. Each tool serves a clear and necessary role.
The core workflow (create, fetch, mark availability, compute best times, lock, set place, plan next) is well-covered. However, there is no tool to update plan details (e.g., title, window) after creation, which is a minor gap.