Gantry

Overview Schema Source Related Servers Discussions Admin

bot_inbox

Read-only

Retrieve and review messages in a specified bot's inbox, with options to filter by intent, limit results, or page after a given point. Use it to process incoming bot messages and track their status.

Instructions

bot inbox

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "arguments": "<arguments>"
    },
    "name": "bot_inbox"
  }
}

Input Schema

Name	Required	Description	Default
`arguments`	Yes
`idempotency_key`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.4.0Nov 7, 2026

TDQS

D1.3/5.0

Behavior1/5

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

Annotations already state readOnlyHint=true and destructiveHint=false, so safety is covered structurally, but the description adds nothing beyond that. It never explains the meaning of the idempotency_key, the nested intent/basis objects, pagination via after/limit, or what an inbox response contains.

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

Conciseness2/5

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

It is short but only because it is under-specified rather than tight; there is no front-loaded statement of purpose and no structure. Two lowercase words cannot be considered an efficient description of a nested-parameter tool.

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

Completeness1/5

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

Given nested objects, a required bot_id, an idempotency key, and no output schema, the description omits everything an agent needs. Its complexity demands a real description, and this provides none.

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

Parameters1/5

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

Schema description coverage is 0% and the description supplies no parameter meaning whatsoever. Critical unknowns such as whether 'after' is a cursor or timestamp, what 'limit' defaults to, and what 'intent'/'basis' payloads are expected remain undocumented, and the nested 'arguments' wrapper is unexplained.

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

Purpose2/5

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

"bot inbox" merely restates the tool name as a lowercase fragment with no verb and no stated resource semantics. An agent cannot tell what operation this performs on a bot's inbox (read? list? poll?) or how it differs from siblings such as studio_inbox, list_team_messages, or get_bot_context.

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

Usage Guidelines1/5

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

No when-to-use guidance, no exclusions, and no pointer to any of the many sibling inbox/message/context tools. The agent is left to guess selection criteria entirely from the name.

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