Modify an existing meeting type's name, cost, length, or description by supplying only the fields to change. Set enabled to false to hide it.
Update a meeting type; only provided fields change. Set enabled=false to hide it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric id | |
| cost | No | ||
| name | No | ||
| length | No | ||
| enabled | No | ||
| description | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden. It usefully discloses PATCH semantics (only provided fields are mutated, so unlisted fields are preserved) and the side effect of enabled=false, but says nothing about authorization requirements, whether changes are reversible, or what happens to the other optional fields when omitted.
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 tight clauses, front-loaded with the core action and immediately followed by the two most decision-relevant details (selective mutation, how to hide). No filler; only knock is that it is quite sparse for a six-parameter mutation.
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 mutation tool with zero annotations, no output schema, and six parameters at 17% coverage, this is under-specified. The agent learns the update is partial and that enabled=false hides the type, but not the meaning of length/cost/name or any permission and failure behavior.
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 coverage is only 17% (just id's "Numeric id"), so the description must compensate for five undocumented parameters. It adds marginal value by explaining partial-update behavior across all optional fields and the enabled flag's effect, but leaves cost, name, length (an unexplained string, oddly typed for a duration), and description completely undescribed.
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?
States a specific verb+resource ("Update a meeting type"), which clearly distinguishes it from the create_/delete_/list_meeting_type siblings without needing to name them. It stops short of explicitly routing to those alternatives, but the operation is unambiguous.
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?
Usage is implied rather than stated: "only provided fields change" tells the agent this is a partial update (don't re-send everything) and "Set enabled=false to hide it" gives one concrete usage path. There is no explicit when-to-use-vs-alternatives guidance or prerequisite/permission note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.