parse_event_textTurn a natural-language sentence (Chinese works best) into create_event input using sync.day's AI parser. Does NOT create anything; review the result, then call create_event. Example: '下周六或周日下午聚餐，大概 3 小时'.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | One sentence describing the event, max 300 chars. | |
| today | No | Reference date for relative words like 明天/下周, YYYY-MM-DD. Defaults to today in Asia/Shanghai. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag readOnlyHint=true, and the description reinforces this by stating 'Does NOT create anything'. It adds useful behavioral context beyond annotations: the use of 'sync.day's AI parser' and that the result should be reviewed before creating. No contradiction with the read-only annotation.
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 sentences with no filler. Each sentence serves a purpose: defining the action, clarifying the non-destructive workflow, and giving a concrete example. Front-loaded with the core purpose and immediately followed by the critical 'does NOT create anything' caveat.
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?
Despite having no output schema, the description adequately communicates the output as 'create_event input' and instructs the agent to review before creating. Combined with the readOnly annotation and the example, it fully equips the agent to invoke the tool and handle the result safely. There is no missing critical information for such a 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 covers both parameters with descriptions (text max 300 chars, today format and default). The description adds an example and notes 'Chinese works best', but does not add significant parameter-level semantics beyond what the schema provides. With 100% schema coverage, the baseline of 3 is appropriate.
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 verb ('Turn'), a clear input ('natural-language sentence'), and a concrete output ('create_event input'). It explicitly says it 'Does NOT create anything', which distinguishes it from the sibling create_event tool. The example further clarifies the expected input format.
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 clearly states when to use the tool: when you have natural language to convert to event input. It also provides a workflow ('review the result, then call create_event') and a language hint ('Chinese works best'). It does not explicitly mention when not to use it or compare it to alternatives like decide_time, but the context is clear enough for an agent to select 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.
Each tool targets a distinct operation, and the descriptions clearly separate organizer actions from participant actions. The only mild ambiguity is between decide_time and vote_time, but the descriptions resolve it well.
All tool names consistently follow a snake_case verb_noun pattern: create_event, get_event, update_event, decide_time, vote_time, remove_participant, submit_availability, parse_event_text. There is no mixed casing or inconsistent verb style, making the set predictable.
Eight tools is well-scoped for a scheduling and availability poll server. Each tool covers a meaningful action without redundancy, and the count feels neither thin nor bloated.
The core workflow is covered: create, read, update, availability submission, voting, deciding, participant removal, and natural-language parsing. The main gap is the lack of a delete_event or cancel operation, which is a workaround-level omission rather than a blocking one.