Skip to main content
Glama
Sign In
moamcp

moamcp

by Yorha9e
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

moa_tower_inbox

Read your agent inbox to see direct and broadcast messages from the tower, newest first.

Instructions

Read the caller's inbox (messages addressed to you or broadcast; the tower sees everything), newest first.

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": {
      "workspace": "<workspace>",
      "caller_agent_id": "<caller_agent_id>"
    },
    "name": "moa_tower_inbox"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax messages to return (default 20), newest first
workspaceYesThe absolute repo root (main checkout) this tower namespace anchors to. Required on every tower tool — the server cwd is never used as a fallback.
caller_agent_idYesYour engine agent id. The tower tools resolve it against the boot-registered roster (the booted tower, or a spawned worker/reviewer).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.13.0

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the transparency burden. It adds useful behavior beyond the name: 'newest first' and the scope 'messages addressed to you or broadcast; the tower sees everything.' However, it does not disclose whether reading affects message state, pagination behavior beyond the limit parameter, or error conditions, leaving notable gaps for a no-annotation tool.

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?

One compact sentence with a parenthetical qualifier. The verb and object are front-loaded, and every word adds meaning; there is no filler or redundancy.

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

Completeness3/5

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

For a simple read tool, the description covers purpose, scope, and ordering, and the schema documents the limit parameter. However, with no output schema and no annotations, the description does not explain the returned message format or how this tool relates to sibling inbox/handoff tools, making it only minimally complete.

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?

Schema description coverage is 100%, and the input schema already documents each parameter in detail, including the default limit. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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 clearly states the action (Read), the resource (caller's inbox), the message scope (messages addressed to you or broadcast), and the ordering (newest first). This distinguishes it from sibling tools like moa_handoff_inbox by specifying inbox messages rather than handoffs.

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

Usage Guidelines3/5

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

The description implies when to use this tool—when you want to see messages addressed to you or broadcasts—but provides no explicit guidance on when not to use it or which alternatives (e.g., moa_handoff_inbox, moa_wait_turn) might be more appropriate. There is no mention of exclusions or alternative tools.

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

Deploy Server

Other Tools