Skip to main content
Glama
yaotsakpo

@inbin/mcp

by yaotsakpo
README.md
# @inbin/mcp

A minimal stdio-to-HTTP proxy for [Inbin](https://inbin.dev)'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`:

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

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

## 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. Available tools:

- `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

## 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 |

## Remote (recommended)

If your MCP client supports Streamable HTTP transport, skip this
wrapper entirely and connect directly:

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

## License

MIT.

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

ActivitySlowing
ResponsivenessNo issues