Skip to main content
Glama
@inbin/mcp

@inbin/mcp

@inbin/mcp

mcptry

A minimal stdio-to-HTTP proxy for Inbin's Model Context Protocol surface. Lets stdio-only MCP clients (Claude Desktop, some Cursor builds, Zed, Cline) talk to Inbin's remote endpoint at https://api.inbin.dev/mcp.

Install & run

Nothing to install globally. Your MCP client invokes it via npx:

{
  "mcpServers": {
    "inbin": {
      "command": "npx",
      "args": ["-y", "@inbin/mcp"],
      "env": {
        "INBIN_API_KEY": "ink_live_..."
      }
    }
  }
}

Get an API key from https://inbin.dev/dashboard.

Related MCP server: mcp-toolmux

No account yet?

Over the remote endpoint (below) five tools need no key at all. An agent can create an inbox, use its address, and wait for a verification code:

  1. create_trial_inbox returns an inbox_address at once (it expires after 14 days).

  2. Use that address wherever a confirmation must be sent.

  3. await_trial_inbox with that exact inbox_address waits up to 60 seconds for the code or link. Call it again if it returns expired.

  4. claim_trial_inbox returns a link for a person to keep the address, and await_trial_inbox_claim and claim_connection_status follow that claim.

This stdio wrapper always sends a key, so it is for the key tools. For the no-account tools connect straight to https://api.inbin.dev/mcp with no header. A runnable walkthrough: https://inbin.dev/guides/ai-agent-email-address-verification-codes

What it does

  • Forwards each stdin JSON-RPC message to https://api.inbin.dev/mcp as an HTTPS POST with your Bearer key.

  • Streams the response back to stdout.

  • Notifications (messages with no id) get no reply, per JSON-RPC.

  • Concurrent in-flight requests are supported.

Tools exposed

Every Inbin application is an MCP server. With a key, the tools include (ask tools/list for the full set):

  • list_inboxes: enumerate inboxes in your app

  • list_events: filter by inbox / status / since; paginated

  • search_events: substring search over id / subject / from / to

  • get_event: a single event's parsed JSON + delivery history

  • query_events: filter, sort, group and aggregate over extracted records (your inbox as a table)

  • describe_schema: the current extraction schema

  • send_email: send through Inbin's gate (replies to people you deal with go out; a new address is held for the owner's approval)

Meetings

Invite the agent's Inbin address to a Google Meet call like anyone else. It joins under its own name, takes notes, and, if the owner allows it, answers out loud from only what the owner allowed for that meeting, handing decisions back to the owner. With a key:

  • list_meetings: the meetings your agents were invited to, with state

  • get_meeting_report: the report, including each line the agent said and the approved item it came from

  • get_meeting_transcript: what was said, in order (untrusted speech)

  • search_meetings: search across meeting transcripts and reports

  • pause_meetings / leave_meeting: stop joining, or leave a call now

Environment

Variable

Required

Description

INBIN_API_KEY

yes

your Inbin API key

INBIN_MCP_URL

no

override the endpoint (defaults to production)

INBIN_MCP_DEBUG

no

set to 1 for stderr logs

If your MCP client supports Streamable HTTP transport, skip this wrapper entirely and connect directly. Without a header you get the five no-account tools; with a key you get everything:

{
  "mcpServers": {
    "inbin": {
      "url": "https://api.inbin.dev/mcp",
      "headers": {
        "Authorization": "Bearer ink_live_..."
      }
    }
  }
}

License

MIT.

Available Tools

5 tools
await_trial_inboxA
Read-only
Inspect

Block (up to ttl_seconds, max 60) for the one confirmation email on a trial inbox created by create_trial_inbox. Pass the exact inbox_address that call returned. The inbox does NOT self-delete or become unusable after a match: it keeps receiving mail and can still be claimed afterward (call claim_trial_inbox any time before it expires) if the human wants to keep using the same address. Call this AFTER you have actually used the address somewhere (signed up, requested a code) -- calling it before that will just expire, since there is nothing to wait for yet. 60 seconds is a hard per-call ceiling, not the inbox's total lifetime: a sender that takes longer than that is not a failure, just call this again with the same inbox_address to keep waiting (the inbox stays valid for its full ~2-week expiry, and you can call this again later too, e.g. to catch a second, later email on the same address). Only treat expired as final once you've retried a few times.

Inputs: inbox_address (required), ttl_seconds, expected_sender.

await_trial_inbox_claimA
Read-only
Inspect

Block (up to ttl_seconds, max 60) for a human to finish the EMAIL+CODE step on the claim_url page from claim_trial_inbox. This NEVER returns a credential, at any status. It returns one of three honest states, not a single 'connected': "claim_pending" (nobody has entered the code yet -- keep waiting or call again), "claimed" (the human proved ownership and a credential was ISSUED, but nothing has used it yet -- a client still needs to be installed with the config from the claim page's 'Advanced' section before anything works), or "client_installed" (some client has actually authenticated with the connection at least once -- a real, observed signal, not an assumption). Each response includes a next_action field telling you exactly what to say or do -- follow it literally rather than guessing. "claimed" is NOT success: do not tell the human it's working until you see "client_installed", and even then, verify it yourself (call list_inboxes or similar through the new connection and read the actual result) before claiming it works for you specifically -- call claim_connection_status later if you need to check again after this chat session, since installing a client can take arbitrarily long and this tool only blocks up to 60s.

Inputs: claim_token (required), ttl_seconds.

claim_connection_statusA
Read-only
Inspect

Read-only, non-blocking check of exactly which state a claim_trial_inbox connection is in RIGHT NOW: "claim_pending", "claimed" (credential issued, unused), or "client_installed" (a client has actually authenticated with it at least once -- real, observed). Never returns a credential. Use this instead of await_trial_inbox_claim when you want to check progress WITHOUT blocking, especially much later than the original chat session -- installing a client into its own config is a human action with no fixed timeline, so polling this occasionally (not in a tight loop) is the right way to check back. Each response includes a next_action field telling you exactly what to say or do.

Inputs: claim_token (required).

claim_trial_inboxAInspect

Start connecting an agent to this inbox address, permanently -- the SAME address. Works whether this is a brand-new trial inbox OR one that's already been claimed by a different agent before: more than one agent can independently connect to the same inbox, each getting its own separate, revocable connection. Returns a claim_url immediately -- share it in chat right away. The human clicks it, enters their email, enters the one-time code Inbin sends there, and a credential is ISSUED. That is NOT the same as the connection working yet -- the human still has to install that credential into an MCP client's config before anything can actually use it, and you will never see the credential itself, by design. Call await_trial_inbox_claim afterward to see the human finish the email+code step, then claim_connection_status (repeatedly, possibly much later -- installing a client is not instant) to see whether a client has actually started using it. The inbox must still exist (not yet expired) for this to work; it does not need to still be a TRIAL inbox specifically.

Inputs: inbox_address (required), connector_label.

create_trial_inboxAInspect

Create a temporary inbox with NO Inbin account required at all -- usable before the human has signed up for anything. Returns the inbox address IMMEDIATELY; it does not wait for anything. Use the address to sign up wherever you need a confirmation sent, THEN call await_trial_inbox with that same address to block for the confirmation -- calling this alone does not get you a confirmation. This inbox is NOT tied to any account yet and expires automatically within about two weeks regardless of use. If the human wants to keep using this SAME address permanently, call claim_trial_inbox: no dashboard visit, no key to copy, and more than one agent can independently connect to the same address over time this way.

Inputs: purpose_label.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.4/5.0

    Scored across 5 tools

    Disambiguation4/5

    The five tools map to clearly distinct phases of one workflow (create, wait for mail, initiate claim, wait for claim, poll status), and the verbose descriptions explicitly state when each should be used. The only real overlap is between await_trial_inbox_claim and claim_connection_status, which both report claim state; the blocking vs non-blocking distinction is spelled out but an agent could still pick the wrong one.

    Naming Consistency4/5

    All names are snake_case verb-first (create_, await_, claim_), which is predictable. There is a minor deviation in object ordering: 'claim_trial_inbox' vs 'await_trial_inbox_claim' describe related actions with different word orders, and 'claim_connection_status' drops the trial_inbox subject, adding mild inconsistency.

    Tool Count5/5

    Five tools for a narrowly scoped trial-inbox onboarding service is well-sized: each tool covers a necessary step (create, wait, claim, wait-for-claim, check status) without redundancy. Nothing feels padded or missing at the count level.

    Completeness4/5

    The trial-inbox lifecycle is covered end to end: obtain an address, receive the confirmation, convert it into a permanent claimed connection, and observe installation status. Minor gaps exist — no way to list existing inboxes/claims, read arbitrary later mail, or release/expire an inbox — but the descriptions note these are handled elsewhere or by other clients.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      B
      maintenance
      A stdio MCP proxy that connects to one or more upstream MCP servers and exposes their tools, resources, and prompts through a single endpoint with a configurable middleware pipeline.
      14
      501 npm
      3
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Proxy-style MCP tool multiplexer that aggregates multiple downstream stdio MCP servers into one, offering meta-tools for status, search, call, parallel, batch, and pipeline operations with concurrency control and caching.
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Thin stdio proxy to Pifini's hosted MCP server (real events, reviewed places, and ticket checkout across the Caribbean & Latin America). MIT, zero dependencies.
      6
      MIT
    • F
      license
      C
      quality
      D
      maintenance
      Schema-driven MCP server that exposes all Paperclip API operations as typed MCP tools over stdio or Streamable HTTP, supporting both authenticated and local_mode deployments.
      100
      -