trmnl_disconnect_room_booking_integration

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructive=true, idempotent=true, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by spelling out exactly what is lost: stored credentials and the account's calendars across every screen and collection. It does not say whether calendars themselves are deleted or merely unbound, which is the one remaining behavioral gap.

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 impactful information — the account disconnect and what gets removed — is front-loaded, and the endpoint line is useful for debugging. The trailing 'Changes remote state or starts work. Run only within the user-authorized scope.' is generic boilerplate that does little beyond restating destructiveHint.

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 destructive, idempotent mutation with no output schema and two parameters, the description covers the effect, the underlying API call, the blast radius, and the authorization constraint. The only refinement an agent might want is valid integration_type values, and that belongs in the schema rather than the description.

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 50%: id and installation_id are documented, but integration_type is bare. The description's path template partially compensates by showing all three segments are required and how they compose, but it never explains what integration_type values are accepted or what profile does. Baseline 3 for partial compensation 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?

States a specific verb and resource (disconnect a room booking account/integration) and immediately describes the concrete effect: credentials forgotten and calendars removed from every screen and collection. That effect distinguishes it from siblings like trmnl_update_room_booking_integration or trmnl_sync_room_booking_integration, though no sibling is named explicitly.

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: the tool removes an integration, so an agent infers it should be used when an account is permanently retired. There is no explicit when-not guidance (e.g., prefer sync or update for temporary fixes) and no note that this is irreversible rather than a toggle. The closing 'run only within the user-authorized scope' is an authorization caveat, not selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.