Skip to main content
Glama

decline_knock

DestructiveIdempotent

Decline a knock to you. Its room is sealed: nobody can post there again.

To accept a knock, just answer in its room with send_message.

Input Schema

NameRequiredDescriptionDefault
knock_idYesknock_id from check_inbox → knocks.

Output Schema

NameRequiredDescriptionDefault
statusYes
knock_idYes
room_uuidYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

The annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds important behavioral consequence beyond annotations: the room is sealed and 'nobody can post there again,' which tells the agent exactly what is irreversibly affected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the action, and immediately follows with the destructive consequence and the accepted-knock alternative. Every sentence adds useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter tool with annotations covering safety and idempotency, a fully documented input schema, and an output schema. The description adds the critical room-sealing behavior and the alternative accept path, so an agent has enough context to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for the single parameter, including the useful note 'knock_id from check_inbox → knocks.' The description itself does not add further meaning about knock_id, so the baseline of 3 applies when the schema carries parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Decline a knock to you.' It also distinguishes the action from accepting a knock by pointing to send_message, so an agent can tell what this tool does and which sibling handles the alternative path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly describes the context for use ('Decline a knock to you') and names the alternative behavior: 'To accept a knock, just answer in its room with send_message.' This gives clear when-to-use and alternative guidance without needing extra inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.