Skip to main content
Glama
Sign In

inboxmcp

by io.github.zhlei07
OverviewDiscussionsAdmin

Check this AI connection's email monitoring

get_email_monitor_state
Read-onlyIdempotent

Check readiness before starting or troubleshooting this AI connection's email monitor.

    Requires email:read. Returns stored progress, mailbox collection health, pending/deferred
    counts, needs_owner_review_count, active lease and retention gaps, or not_configured with
    reconnection guidance. expired_deferred lists deferred events that retention removed before
    completion; it is informational and never blocks claims, unlike a retention gap.
    Tell the owner only about owner_actions with notify_owner true; the others were already
    reported. A mailbox with retrying true had a temporary failure that InboxMCP retries by
    itself: do not report it. Progress is stored by InboxMCP, not by Notion or local files.
    This call changes no progress, enables no collection and verifies no notifications.
    Reconnect for missing progress permission only if this client is eligible for
    consumer-state:write; a read-only client
    ceiling cannot be raised by reconnecting. Never reset an existing task's baseline.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description explains nuanced behavior: expired_deferred is informational and never blocks claims, retrying mailboxes are auto-retried and should not be reported, owner_actions should only be surfaced when notify_owner is true, and progress is stored by InboxMCP rather than Notion or local files. It also clarifies what the call does not do: it changes no progress, enables no collection, and verifies no notifications.

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 front-loaded with purpose and permission requirements, then moves through return states, reporting caveats, storage location, and reconnection constraints. Despite its length, each sentence carries distinct operational meaning for a state-check tool with complex output semantics.

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?

With no output schema, the description carries the burden of explaining return states and does so thoroughly, including not_configured guidance, retention-gap behavior, lease information, and owner notification rules. It also covers authorization, non-effects of the call, and reconnection eligibility, leaving little ambiguity for an agent.

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

Parameters4/5

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

The tool takes zero parameters, so there are no parameter meanings to document and the baseline is 4. The description appropriately focuses on state semantics and preconditions rather than inventing parameter details.

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 action and resource: checking readiness/progress for this AI connection's email monitor. It also explicitly lists the returned state categories (stored progress, mailbox health, pending/deferred counts, leases, retention gaps, not_configured), so an agent can distinguish it from sibling tools like list_mailboxes or get_email_context.

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 says when to call it: "before starting or troubleshooting this AI connection's email monitor." It also gives important usage constraints, including required permission (email:read), when reconnecting is appropriate, and the warning never to reset an existing task's baseline.

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

All inboxmcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources