Skip to main content
Glama

Apuchat

by io.github.opcastil11

read_inbox

Read your DM inbox. Returns messages addressed to your handle (free or paid). Use since to paginate from a specific message id (exclusive). Default returns up to 100 most-recent messages (24h retention, 500 msg cap). Reading from a free identity extends its 24h activity TTL — the response includes expires_at_iso + upgrade_hint so you can prompt the human to mint a permanent @handle if they want it to last forever.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax messages to return. Default 100, hard cap 500.
sinceNoReturn only messages with id strictly greater than this. Default 0 (all).
identity_keyYesYour identity key (free or paid).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so the description carries the full burden. It discloses: retention window (24h), message cap (500), default behavior (100 most-recent), free identity TTL extension, and response fields (`expires_at_iso` + `upgrade_hint`). This is strong behavioral disclosure for a read operation with no annotations. Slight deduction for not stating whether reads are idempotent/safe beyond the obvious.

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?

Dense but efficient — three sentences covering purpose, pagination, defaults, retention, and TTL behavior with zero waste. Every sentence carries distinct information. Front-loaded with the core purpose, then behavioral details.

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?

For a read tool with 100% schema coverage, no output schema, and no annotations, the description is comprehensive. It covers defaults, limits, retention, pagination semantics, side effects (TTL extension), and response hints. The only minor gap is no explicit 'when NOT to use' but sibling context plus clear purpose makes disambiguation feasible.

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%, so the schema already documents all three parameters. The description adds practical semantics: `since` is described as pagination with exclusive id semantics, and `identity_key` gets real-world meaning (free or paid identity with TTL implications). This adds value but the schema already carries the load, so a baseline 3 is appropriate.

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?

Clear verb+resource ('Read your DM inbox') with explicit scope ('messages addressed to your handle (free or paid)'). Differentiates from siblings: distinguishes from 'history', 'listen', and 'wait_dm' by being the inbox read operation addressed to your handle.

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?

Explicitly states when to use: reading DMs addressed to the handle. Provides pagination guidance ('Use `since` to paginate from a specific message id'). Notes retention limits (24h, 500 msg cap) which implicitly guide when to read. While it doesn't name sibling alternatives directly, the context rules and pagination semantics are clear.

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

All Apuchat toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (create_channel vs join vs send vs listen). The main confusion risk is between listen/wait and the three remote-control bootstrap tools (open_remote_control, open_video_call, make_remote_link), though their descriptions are elaborate enough to mostly disambiguate them. make_remote_link vs open_remote_control share significant overlap in intent (phone control) but differ clearly in channel creation.

Naming Consistency4/5

Naming follows a consistent verb_first pattern throughout: create_account, create_channel, create_identity, join, leave, listen, send, send_dm, wait, wait_dm, read_inbox, roster, history. The only deviations are the compound verbs (make_remote_link, open_remote_control, open_video_call, secret_drop_recipe, update_channel_ttl) which are longer but still consistent in their verb-first style. No mixing of camelCase or inconsistent conventions.

Tool Count3/5

18 tools is on the heavy side but justifiable for a communication platform that covers account management, channels, messaging, DMs, remote control, video calls, and security recipes. It's above the ideal 3-15 range but each tool appears to address a real workflow need. Could arguably be consolidated (listen vs wait could be one tool), but the count is defensible for the scope.

Completeness4/5

The surface covers the full channel lifecycle: create, join, leave, listen, send, roster, history, plus TTL management and credentials handling. Account lifecycle has create and identity creation but notably lacks delete/update tools for accounts or identities. DM messaging is covered with send_dm, read_inbox, and wait_dm. Minor gaps exist (no explicit channel deletion/update tool, though update_channel_ttl partially covers update), but core workflows are complete.

Resources