F
licenseA
qualityC
maintenanceEnables local-first search and analysis of Boxes home inventory exports and images, with tools for inventory queries, documentation audits, and signed webhook verification.
7
-
inbin
Server Details
Query Inbin's parsed email events (newsletters, invoices, alerts) as typed JSON tools.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 27.4% over 61 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- Repository
- yaotsakpo/inbin-mcp
- GitHub Stars
- 1
- Server Listing
- @inbin/mcp
TDQS
A4.4/5.0
Scored across 5 tools
Disambiguation3/5
The tools await_trial_inbox_claim and claim_connection_status both report the same claim states and differ only in blocking behavior, creating a real risk of misselection. The other tools are more distinct, but this overlap reduces clarity. Descriptions help but do not fully eliminate confusion.
Naming Consistency4/5
All tool names use snake_case with a verb_noun pattern, which is consistent. However, 'claim_connection_status' uses 'claim' as a verb for a read-only check, which is semantically misleading, and 'await_trial_inbox_claim' is a bit awkward as a noun phrase.
Tool Count5/5
With 5 tools, the set is well-scoped for the trial inbox workflow: create, await email, claim, await claim, and check status. Each tool serves a distinct step without redundancy or bloat.
Completeness5/5
The tools cover the full lifecycle from creating a trial inbox, receiving a confirmation email, initiating a claim, waiting for claim completion, and checking connection status. No obvious gaps exist for the stated purpose.
Available Tools
5 toolsawait_trial_inboxARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ttl_seconds | No | How long to block waiting for the confirmation, in seconds (max 60). Returns expired if nothing arrives in time. | |
| inbox_address | Yes | The exact address create_trial_inbox returned, e.g. abc123@in.inbin.dev. | |
| expected_sender | No | Glob on the sender address, e.g. *@vercel.com. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give readOnlyHint=true; the description carries the real behavioral load: the 60s ceiling is per-call not the inbox lifetime, the inbox does not self-delete or become unusable after a match, it stays valid ~2 weeks, and 'expired' is not final until retried. That is exactly the context an agent cannot get from the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and the required parameter before the edge-case guidance, and every sentence carries non-redundant operational detail; it is long and parenthetical-heavy, but nothing is filler.
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 still explains the meaningful return condition (expired) and how to interpret it, plus retry cadence and inbox lifetime — an agent has everything needed to call and interpret this correctly.
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?
Schema coverage is 100% so the baseline is 3, but the description goes beyond the schema by insisting on the exact address returned by create_trial_inbox and by clarifying that ttl_seconds caps a single blocking call rather than the inbox's total validity — a distinction the schema's 'max 60' alone does not convey.
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?
States a specific verb and resource ('Block ... for the one confirmation email on a trial inbox') and names the creating sibling (create_trial_inbox) whose output feeds it, so it is unmistakable against await_trial_inbox_claim, claim_trial_inbox, and create_trial_inbox.
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?
Explicit when-to-call ('AFTER you have actually used the address somewhere') plus when-not ('calling it before that will just expire'), the retry rule for >60s senders, and the alternative claim_trial_inbox path if the human wants to keep the address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
await_trial_inbox_claimARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim_token | Yes | The token from claim_trial_inbox's claim_url (the part after /claim/). | |
| ttl_seconds | No | How long to block waiting, in seconds (max 60). Returns pending if the human hasn't finished yet. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, but the description adds major behavioral context: it NEVER returns a credential at any status, it returns three named states rather than a boolean, each response carries a next_action field, and 'claimed' is explicitly NOT success. It also tells the agent to independently verify via list_inboxes before asserting success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the blocking bound, then the three states, then the verification warning. It is long and repeats emphasis ('NOT success', 'follow it literally') that could be tightened, but nearly every sentence carries actionable guidance for a genuinely tricky tool, so the size is mostly justified.
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?
There is no output schema, so the description carries the full burden of describing returns and does so: three named states with precise meaning, the next_action field, and the absence of a credential in any response. It also covers the cross-session continuation path via claim_connection_status. Nothing an agent needs to call this correctly is missing.
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 both parameters (claim_token and ttl_seconds) are already fully documented in the schema. The description only restates the ttl_seconds cap and the token's origin, adding no new syntax or format detail. Baseline 3 is correct when the schema does the heavy lifting.
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?
States a specific verb and resource: block (up to ttl_seconds, max 60) for a human to finish the EMAIL+CODE step on the claim_url page produced by claim_trial_inbox. It explicitly distinguishes itself from the sibling tools by naming claim_url from claim_trial_inbox and by referencing claim_connection_status as the later check.
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?
Gives explicit when-to-use (block while a human completes the EMAIL+CODE step), what to do on each outcome (keep waiting or call again on 'claim_pending'), and names the alternative for later checking: 'call claim_connection_status later if you need to check again after this chat session'. It also warns that client installation can take arbitrarily long, so this tool only blocks up to 60s.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claim_connection_statusARead-onlyInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| claim_token | Yes | The token from claim_trial_inbox's claim_url (the part after /claim/). |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds that the call is non-blocking, that it never returns a credential, that 'client_installed' is real observed authentication, and that each response carries a next_action field. It also explains why polling is appropriate (human install action, no fixed timeline).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the operation and its return states, and every clause carries information. It is slightly dense with nested parentheticals and em-dash asides, which costs a little readability, but nothing is filler.
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 compensates by listing the possible return states and noting the next_action field, and it covers the blocking/non-blocking tradeoff. An agent has everything needed to call and interpret it.
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 coverage is 100% and the schema already documents that claim_token comes from claim_url after /claim/. The description adds no additional syntax or format detail for the parameter, so the baseline 3 for fully documented single-parameter schemas applies.
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?
States a specific verb (read-only, non-blocking check) and resource (the claim_trial_inbox connection's current state), then enumerates the exact states returned. An agent can distinguish it from await_trial_inbox_claim without opening any schema.
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 names the alternative ('Use this instead of await_trial_inbox_claim when you want to check progress WITHOUT blocking') and gives the condition that selects it, plus practical polling guidance ('occasionally, not in a tight loop'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| inbox_address | Yes | The exact inbox address to connect to, e.g. abc123@in.inbin.dev. | |
| connector_label | No | 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. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint=false and idempotentHint=false; the description adds substantial context beyond them: it returns a claim_url, the human must complete an email + one-time-code step, a credential is ISSUED but not the same as working, the credential is never visible to the agent, and multiple agents can hold independent revocable connections. That multiple-connections detail usefully explains the non-idempotent annotation. It stops short of discussing failure/expiry error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and its permanence, then the workflow. Every sentence carries real information (the claim flow, the issue-vs-working distinction, the follow-up tools), though the paragraph is long and could be tightened with enumeration.
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?
No output schema exists, and the description compensates by naming the immediate return (claim_url) and the full multi-step human/agent handoff through to claim_connection_status. For a tool with an inherently multi-stage async workflow, nothing needed to call it correctly is missing.
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 coverage is 100% and both parameters are already documented in the schema, so the description adds no format or constraint detail beyond it. Baseline 3 applies when the schema carries the full parameter burden.
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?
States a specific verb and resource ('Start connecting an agent to this inbox address, permanently -- the SAME address') and explicitly covers both cases (new trial inbox vs. already-claimed), which distinguishes it from create_trial_inbox and the await/status siblings.
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?
Names the follow-up tools by name and the condition for each ('Call await_trial_inbox_claim afterward... then claim_connection_status (repeatedly, possibly much later)'), and states the precondition (inbox must still exist, need not still be a trial). Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| purpose_label | No | Optional human-readable label for what this inbox is for. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and idempotentHint=false. The description adds substantial context beyond that: it returns the address immediately without waiting, the inbox is unbound to any account, it auto-expires in roughly two weeks regardless of use, and it grants no confirmation on its own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded, with the immediate-return and no-account traits stated first, then the workflow, then the expiry and claim path. Slightly verbose with heavy capitalization for emphasis, but essentially every sentence carries distinct information.
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?
Even with no output schema, the description explains what comes back (the address, immediately) and covers lifetime, account binding, and the follow-up calls an agent must make. Nothing needed to invoke this correctly is missing.
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?
Only one optional parameter (purpose_label) with 100% schema description coverage, so the schema already documents it fully. The description adds no further parameter meaning, but the zero-required-param shape means there is little to explain.
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?
States a precise verb+resource ('Create a temporary inbox') and immediately characterizes the key distinguisher: no account required, usable before signup. An agent can tell this apart from await_trial_inbox and claim_trial_inbox without opening any schema.
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 describes the workflow: use the returned address to sign up, THEN call await_trial_inbox to block for the confirmation, and warns that calling this alone does not yield a confirmation. It also names claim_trial_inbox as the alternative when the address must be kept permanently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
claim_connection_status
1 tool update
- Changed
claim_trial_inbox2 fields changed- added
Input schema / properties / connector_labelAdded value: +{ + "description": "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.", + "type": "string" +} - changed
Input schema / properties / inbox_address / descriptionPrevious value: -"The exact trial inbox address to claim, e.g. abc123@in.inbin.dev."New value: +"The exact inbox address to connect to, e.g. abc123@in.inbin.dev."
2 tool updates
- Added
await_trial_inbox_claim - Added
claim_trial_inbox
2 tool updates
- Added
await_trial_inbox - Changed
create_trial_inbox2 fields changed- removed
Input schema / properties / expected_senderRemoved value: -{ - "description": "Glob on the sender address, e.g. *@vercel.com.", - "type": "string" -} - removed
Input schema / properties / ttl_secondsRemoved value: -{ - "default": 45, - "maximum": 60, - "minimum": 1, - "type": "integer" -}
1 tool update
- First observed
create_trial_inbox
Related MCP Connectors
Extract PDFs into structured tables, query records, and configure document inbox workflows.
Read-only Amazon SES observability: search events, inspect bounces, pull delivery stats.
- DatanemOAuthcom.datanem
Turn PDFs, scans and photos into a queryable database. Invoices, CVs, receipts, in bulk.
Verified extraction: source-backed JSON from PDFs/URLs; honest null + signed receipt.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to read, search, send, manage, schedule, and analyze messages across multiple IMAP/SMTP accounts, including real-time inbox watching, verification-code capture, calendar extraction, and analytics. Exposes 52 tools, 7 prompts, and 6 resources over stdio or Streamable HTTP.24 npmISC
- AlicenseNot gradedqualityAmaintenanceEnables AI assistants to read, search, send, schedule, and organize email across multiple IMAP/SMTP accounts, including drafts, provider-aware labels, real-time inbox watching, verification-code capture, and analytics. Supports OAuth2, calendar extraction, and both local stdio and networked Streamable HTTP access.24 npmISC
- AlicenseAqualityCmaintenanceReads and searches local email archives (.mbox or .eml) with full MIME parsing, enabling queries about senders, subjects, dates, and bodies while keeping all data on your machine.3127 npmMIT
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.