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 declare readOnlyHint=true, and the description reinforces this by saying 'Does NOT create anything'. The description adds useful behavioral context beyond annotations: it is an AI parser, it works best with Chinese, and its output should be reviewed before acting. This goes beyond what annotations alone provide.
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: the core function is stated first, followed by the critical safety clarification and a concrete example. Every sentence earns its place, and there is no redundant wording.
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?
For a simple two-parameter, read-only parsing tool with full schema coverage, the description covers the essential context: what it does, what it does not do, and what to do next. There is no output schema, so a bit more detail about the exact shape of the returned create_event input would be ideal, but the description already says the output is create_event input and instructs the agent to review it.
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 the schema already documents both parameters well. The description adds a clarifying example and the 'Chinese works best' hint, which helps with the text parameter, but it doesn't add substantial parameter-level meaning beyond what the schema provides. Baseline 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 states a specific verb ('Turn'), a specific resource ('natural-language sentence'), and a concrete target output ('create_event input'). It also explicitly distinguishes itself from create_event by saying 'Does NOT create anything', which separates it from the sibling tool.
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 clearly tells the agent when to use this tool: for natural-language sentences, with a note that Chinese works best. It also gives explicit follow-up guidance: review the result, then call create_event. The example makes the intended usage concrete and understandable.
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 has a clearly distinct purpose: creation, parsing, reading, updating, deciding, submitting availability, voting, and participant removal. The closest pair, submit_availability and vote_time, are separated by their inputs (startOptions vs voteOptions) and lifecycle stage.
All tool names follow a consistent lowercase snake_case verb_noun pattern, e.g. create_event, get_event, update_event, vote_time, decide_time. Minor compound names like parse_event_text and remove_participant still fit the same predictable convention.
Eight tools is well-scoped for an availability-polling server. Each tool covers a distinct part of the workflow without redundancy or excessive fragmentation.
The core lifecycle is covered: create, parse, read, update, submit availability, vote, decide, and remove participants. The only notable gap is no explicit delete/cancel event tool, but this does not break the main scheduling workflow.