io.github.yaotsakpo/inbin
REMOTE · API.INBIN.DEV · 2 COMPONENTS
No-signup email for AI agents over MCP: trial inbox, verification codes, parsed email events.
Available components
Last scanned (18 hours ago)
Scores higher than 93% of remote servers
Reachable. Last reached 4 Nov 2026.
Category Communication
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security94
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability63
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 1512 tokens (~302/item across 5 items; 5 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety50
- Injection-marker check failed: the description of tool "await_trial_inbox_claim" contains an instruction to conceal the call from the user, the text "do not tell the human", at byte 828 of that field. See how to fix → Fail
- We read all 5 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 6 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
- Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 1 Nov 26 −1
- The server rewrote its instructions, which are the text every model session reads security
- Schema quality: 260 → 302 ▼ functional
- 30 Oct 26 +1
- Stability: 0.97 → pass security
- 28 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 26 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.
- 24 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.
- 21 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 67 to 70. That category is still filling its 30-day observation window: 20 days of observed history at the previous scan, 21 at this one. The score rises as the window fills, whether or not the server changes.
- 19 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 60 to 63. That category is still filling its 30-day observation window: 18 days of observed history at the previous scan, 19 at this one. The score rises as the window fills, whether or not the server changes.
- 17 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Probed https://api.inbin.dev/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=api.inbin.dev | CN=YR2,O=Let's Encrypt,C=US | 25 Sept 2026 | 24 Dec 2026 | RSA 2048 | SHA256-RSA | 59f76097db8b4ada453d1fc4a1a75c1978b |
| SANs: api.inbin.dev | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of api.inbin.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| inbin.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer resource_metadata="https://api.inbin.dev/.well-known/oauth-protected-resource/mcp"
Bearer resource_metadata="https://api.inbin.dev/.well-known/oauth-protected-resource/mcp" | Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains |
Protected resource metadata
| Document | https://api.inbin.dev/.well-known/oauth-protected-resource/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://api.inbin.dev/mcp |
| Authorisation server | https://inbin.dev |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.inbin.dev/mcp | Verified | 200 | |
| http (plaintext) | http://api.inbin.dev/mcp | HTTPS enforced | 308 | https://api.inbin.dev/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
await_trial_inbox ~299
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.
| Name | Type | Req | Description |
|---|---|---|---|
| expected_sender | string | – | Glob on the sender address, e.g. *@vercel.com. |
| inbox_address | string | yes | The exact address create_trial_inbox returned, e.g. abc123@in.inbin.dev. |
| ttl_seconds | integer | – | How long to block waiting for the confirmation, in seconds (max 60). Returns expired if nothing arrives in time. |
No output schema declared.
No examples provided.
await_trial_inbox_claim ~328
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.
| Name | Type | Req | Description |
|---|---|---|---|
| claim_token | string | yes | The token from claim_trial_inbox's claim_url (the part after /claim/). |
| ttl_seconds | integer | – | How long to block waiting, in seconds (max 60). Returns pending if the human hasn't finished yet. |
No output schema declared.
No examples provided.
claim_connection_status ~174
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.
| Name | Type | Req | Description |
|---|---|---|---|
| claim_token | string | yes | The token from claim_trial_inbox's claim_url (the part after /claim/). |
No output schema declared.
No examples provided.
claim_trial_inbox ~297
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.
| Name | Type | Req | Description |
|---|---|---|---|
| connector_label | string | – | Optional label identifying which agent/client is connecting, e.g. 'Muse'. Shown to the human as the name of this specific connection so they can tell multiple connections apart later. |
| inbox_address | string | yes | The exact inbox address to connect to, e.g. abc123@in.inbin.dev. |
No output schema declared.
No examples provided.
create_trial_inbox ~171
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.
| Name | Type | Req | Description |
|---|---|---|---|
| purpose_label | string | – | Optional human-readable label for what this inbox is for. |
No output schema declared.
No examples provided.
How do I install the io.github.yaotsakpo/inbin MCP server?
io.github.yaotsakpo/inbin is a hosted endpoint at https://api.inbin.dev/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · api.inbin.dev
claude mcp add --transport http yaotsakpo-inbin 'https://api.inbin.dev/mcp'
What is the io.github.yaotsakpo/inbin MCP server?
io.github.yaotsakpo/inbin is an MCP server listed in the public MCP registry as io.github.yaotsakpo/inbin. No-signup email for AI agents over MCP: trial inbox, verification codes, parsed email events. This page covers its hosted endpoint (https://api.inbin.dev/mcp).
Is the io.github.yaotsakpo/inbin MCP server safe to use?
io.github.yaotsakpo/inbin scores 86 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.yaotsakpo/inbin MCP server expose?
io.github.yaotsakpo/inbin exposes 5 tools: create_trial_inbox, await_trial_inbox, claim_trial_inbox, await_trial_inbox_claim, claim_connection_status. Their descriptions and schemas cost roughly 1,269 tokens of context every time the server is loaded.
Does the io.github.yaotsakpo/inbin MCP server require authentication?
Yes. io.github.yaotsakpo/inbin asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the io.github.yaotsakpo/inbin MCP server still maintained?
io.github.yaotsakpo/inbin is still listed as active in the MCP registry. We last reached this channel on 4 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.