Read the current responses for a Whenly event and get the best meeting times (the slots where the most people are free). Pass the event slug (the code after /e/ in the event_url).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The 7-char event code from the event_url (the part after /e/). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It explicitly says 'Read', implying a non-mutating operation, and defines what 'best' means (slots where most people are free). This is strong transparency for a simple getter, though it does not describe the exact response shape or any edge cases.
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 sentences communicate the purpose, the parameter to pass, and the meaning of the result with no filler. The key behavior is front-loaded, and the instruction is immediately actionable.
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?
With one required parameter and no nested objects, the description gives an agent everything needed to invoke the tool correctly: what to pass and what to expect in return. A more explicit output format would be helpful since there is no output schema, but the high-level result description is adequate for this simple 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?
The schema already documents the slug parameter at 100% coverage, including its format (7-char event code after /e/). The description mostly restates this by saying 'Pass the event slug (the code after /e/ in the event_url)', so it adds no substantial meaning beyond the schema.
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 uses a specific verb ('Read') and clearly identifies the resource ('current responses for a Whenly event') and the derived outcome ('best meeting times'). The read operation contrasts directly with the only sibling tool, create_event, so an agent can distinguish them without extra effort.
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 makes it clear when to use the tool: when you need the current responses and best available slots for an event. It does not explicitly name create_event as an alternative or state when not to use it, but the 'Read' wording plus the sibling name provides sufficient context for choosing it.
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.
create_event and get_results are completely distinct: one creates a scheduling link, the other reads response data. There is no overlap or ambiguity between the two tools.
Both tools use the same verb_noun snake_case pattern: create_event and get_results. The naming is predictable and consistent.
Two tools feels thin for a scheduling service, though each tool is meaningful and covers a clear step in the workflow. It is on the minimal side but not absurdly incomplete.
The core create-then-poll loop is supported, but update, delete, and broader event-management operations are missing. Agents can work around this by creating a new event, but lifecycle coverage is incomplete.