Skip to main content
Glama
lemonaide152

meld

by lemonaide152
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

meld — ephemeral context bridge

Don't meet. Meld.

meld puts the context on a URL so neither side has to paste the block. Then the URL dies.

One URL. Both sides add context. When it resolves, the host serves 410 and the meld is gone. No history, no threads, no accounts.

Live

https://meld.mergeinc.workers.dev

Related MCP server: Vaulted MCP Server

Try it

Discover

Quick start (agents)

# Create a meld — get one share URL
curl -X POST https://meld.mergeinc.workers.dev/api/melds \
  -H "Content-Type: application/json" \
  -d '{"context": "Auth flow: OAuth2+PKCE, JWT tokens, refresh rotation"}'
# → {"code": "abc123", "url": "https://…/m/abc123", ...}

# Party B (human or agent) resolves:
curl -X POST https://meld.mergeinc.workers.dev/api/melds/abc123/resolve \
  -H "Content-Type: application/json" \
  -d '{"context": "Looks good, but add rate limiting to token refresh"}'

# Preferred: Party A reads both sides after resolve (no token)
curl https://meld.mergeinc.workers.dev/api/melds/abc123
# → {"code":"…","context_a":"…","context_b":"…","resolved":true, …}

Legacy read path (still on the live host)

owner_token and GET /api/melds/{code}/result (header X-Meld-Token) are still issued and accepted for backwards compatibility. Prefer GET /api/melds/{code} after resolve — it returns both sides without a token. Token rotation on /result still applies if you use that path.

Trust model

No accounts. The hard promise: after TTL T, the host serves 410 and the meld is gone.

Optional client-side encryption keeps plaintext off the server; the URL is still the capability. Full statement: TRUST.md.

API

Endpoint

Method

Auth

Description

/api/melds

POST

None

Create a meld (returns share url; also still returns legacy owner_token)

/api/melds/{code}

GET

None

View a meld — preferred Party A read after resolve (both sides)

/api/melds/{code}/resolve

POST

None (or PIN)

Resolve a meld

/api/melds/{code}/result

GET

Owner token

Legacy owner read (token rotates)

/v1/melds

POST

API key

Create via agent key

/v1/usage

GET

API key

Check usage

Pricing

Who

Price

Limits

Humans (browser)

$0

Free — no IP free-wall (X-Meld-Client: human or browser UA)

Agents (/api/melds)

$0 then key / unlock

3 melds / IP / hour; then POST /v1/keys or wait

Agent API key (/v1)

$0

10,000 melds / key (mint via POST /v1/keys)

Agent wall unlock

$3.33 one-time

Unlocks one specific meld beyond the agent free tier

Humans free in the browser. Agent payment protocols are coming. No subscriptions. Create responses carry X-Meld-Pricing: humans-free; agents-key-or-quota. Checkout (agent wall): POST /api/checkout {"meld_code": "<code>"} (Stripe). Playbooks: FDE gather, provider-switch dump/request, TTL continuation — /recipes.md.

Available Tools

3 tools
meld_createAInspect

Create a meld: an ephemeral context bridge. Returns a share link to give the other party (human or agent) and an owner link to keep. The meld expires (~1 hour free tier) after both parties exchange context.

ParametersJSON Schema
NameRequiredDescriptionDefault
pinNoOptional PIN the other party must supply to answer.
contextYesYour context: code, requirements, logs, a prompt, a question — anything.

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the ephemeral nature (expires ~1 hour free tier) and that it returns two links (share and owner). This goes beyond the schema, which only lists parameters. It does not mention any destructive side effects or permissions, but for a create operation, the disclosed behaviors are relevant and useful.

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 two sentences with no waste. It front-loads the core purpose and return values, then adds the expiration detail. Every sentence earns its place, making it efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple create tool with two parameters and no output schema, the description covers the essential aspects: what it creates, what it returns (share and owner links), and its ephemeral nature. It does not explain how to use the links or any error conditions, but these are not critical for basic invocation. The description is sufficient for an agent to call the tool correctly.

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 the schema already documents both parameters (context and pin). The description adds no new meaning beyond what the schema provides; it only restates that context can be code, requirements, etc., which is also in the schema. Baseline 3 is appropriate when the schema fully covers parameters.

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 verb (create) and resource (meld) with a clear concept (ephemeral context bridge). It distinguishes from siblings by its action: it creates, while siblings are meld_resolve and meld_read. An agent can immediately tell this is for initiating a new meld.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it: to create a new meld, as opposed to resolving or reading existing ones. It provides clear context about the purpose but does not explicitly state 'use this when you need to start a context exchange' or list exclusions. The differentiation from siblings is implicit through the verb and resource, which is clear but not explicit.

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

meld_readAInspect

Owner: read the resolved result of your meld. The owner token rotates on every read — use the newest one.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesThe meld code.
owner_tokenYesYour owner token (from meld_create or the previous read).

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses token rotation on every read, which is useful, but does not state whether the read is destructive, whether it consumes the meld, or what the return format looks like. Given the absence of annotations, this is a moderate gap.

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?

Two short sentences with no filler. The purpose is stated upfront, and the critical token-rotation caveat is included immediately, making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with two parameters and no output schema, the description covers the essential context: ownership, token usage, and the rotation behavior. It lacks explicit mention of return value, but that may be implied by 'read the resolved result'. Overall adequate for a basic operation.

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. The description adds the behavioral detail that the owner token rotates on every read and that the newest one must be used, which goes beyond the schema's static description and clarifies usage.

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?

Description states a clear action ('read') on a specific resource ('resolved result of your meld') and clarifies ownership. It distinguishes from siblings by implying it's for reading after resolution, though it doesn't name alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a usage hint (owner token rotation) but lacks explicit when-to-use or when-not-to-use guidance relative to siblings like meld_resolve and meld_create. It implies the read step comes after creation/resolution but does not state it directly.

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

meld_resolveAInspect

Resolve a meld you received a link for. Submit your context/answer. Returns the other party's context. The meld dissolves shortly after.

ParametersJSON Schema
NameRequiredDescriptionDefault
pinNoPIN if the meld has one.
codeYesThe meld code from the link (the part after /m/).
contextYesYour answer/context.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the meld 'dissolves shortly after' (a time-sensitive side effect) and that it 'returns the other party's context' (output behavior). It does not mention failure modes or authentication, but for a simple tool, these are not critical. The description adds meaningful behavioral context beyond the schema.

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 two concise sentences with no wasted words. It front-loads the purpose, then states the key behavior (return and dissolution). Every sentence earns its place, and the structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three simple parameters and no output schema, the description covers the essential aspects: what it does, what it returns, and a critical time-sensitive warning. It does not explain error cases or prerequisites, but these are not necessary for a tool of this simplicity. The description is sufficiently complete for an agent to call it correctly.

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 the schema already documents all three parameters. The description adds a brief clarification ('Submit your context/answer') that aligns with the 'context' parameter, but it does not add new information about 'code' or 'pin' beyond what the schema provides. This is a baseline score for a well-covered schema.

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 verb ('Resolve') and resource ('a meld you received a link for'), which clearly distinguishes it from siblings like meld_create (creating) and meld_read (reading). The phrase 'you received a link for' adds the exact context of use, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates when to use this tool: when you have a link to a meld and need to submit your context/answer. It does not explicitly mention alternatives or exclusions, but the context 'you received a link for' implies this is for resolving incoming melds, not for creating or reading. This is clear enough for an agent to select correctly, though it lacks explicit 'when not to use' guidance.

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. 3 tool updatesv0.1.0
    • First observedmeld_create
    • First observedmeld_read
    • First observedmeld_resolve
Deploy Server
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

TDQS

A4.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct role: create establishes the meld, resolve is for the invited party to submit context, and read is for the owner to retrieve the resolved result. There is no functional overlap between the three operations.

Naming Consistency5/5

All tools follow the same meld_ prefix with a simple verb: create, resolve, and read. This creates a predictable and consistent naming pattern across the entire tool surface.

Tool Count5/5

Three tools is exactly the right scope for an ephemeral context bridge with a straightforward lifecycle. Each tool maps to one essential stage of the meld process with no redundancy.

Completeness5/5

The full lifecycle of a meld is covered: creation, participant resolution, and owner read of the resolved result. Expiry and token rotation are handled automatically, so no additional operations are necessary.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers