Skip to main content
Glama
lemonaide152

meld

by lemonaide152
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

meld — ephemeral context bridge

Don't meet. Meld.

Put working context on a capability URL. Neither side pastes the block. Party A creates the link. One note says what the exchange is for and what it is not for. A sends that URL to B privately. The conversation stays on that link.

The bridge stays open while the exchange is active. Until the first reply, the hop stays open 36 hours from creation. The first reply sets a 24 hour timer. Each later reply is kept. Each later reply resets that 24 hours. There is no maximum lifetime once replies have started. A read does not start the timer. A read does not reset the timer.

When the window ends, the host dissolves the meld. Dissolve deletes the bridge. The next request for that code is 404. A code that never existed is 404. An expired code is 404. The response is the same.

Host-readable while live. Anyone with the link can read it. Not for secrets. No accounts. No plaintext archive.

No AI in the loop. The host holds what you pour while the bridge is live. The host does not summarize the exchange. The host does not rewrite it. The host does not invent a reply. The host does not run a model on it.

Self-host is the path. This repository is the server, Caddy, and Docker setup.

Get started

git clone https://github.com/lemonaide152/meld.git && cd meld && docker build -t meld . && docker run --rm -p 8080:8080 -e MELD_PUBLIC_URL=http://127.0.0.1:8080 meld

Then:

curl -s -X POST http://127.0.0.1:8080/api/melds \
  -H "Content-Type: application/json" \
  -d '{"note":"For a design review. Not for passwords or customer data."}'

A sends the url to B privately. B replies with POST /api/melds/{code}/resolve. Keep talking on that same link.

Compose (local)

cp .env.example .env
docker compose up -d --build

Same API on http://127.0.0.1:8080.

Compose + Caddy (public TLS)

Set MELD_SITE and MELD_PUBLIC_URL in .env, point DNS at the machine, open 80/443:

docker compose --profile tls up -d --build

Python (no Docker)

python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
python server.py

Related MCP server: Vaulted MCP Server

Publish an image

docker build -t ghcr.io/lemonaide152/meld:latest .
docker login ghcr.io
docker push ghcr.io/lemonaide152/meld:latest

API

Endpoint

Method

Description

/api/melds

POST

Creation. One note: what the exchange is for and what it is not for. Send note, or put that same text in context, for, and not_for. Open 36 hours from create until the first reply. A sends the URL to B privately.

/api/melds/{code}

GET

Plaintext while live: the note and every reply. Does not start or reset the timer. Unknown, dissolved, and expired are the same 404.

/m/{code}

GET

Same plaintext read. This is the capability URL. Link-preview crawlers get an expires-only card with no exchange. That card does not read the meld.

/api/melds/{code}/resolve

POST

Append a reply on this same bridge. Keep talking on that link. The first reply sets a 24 hour timer. Each later reply is kept and resets that 24 hours. Unknown, dissolved, and expired are the same 404.

A client that still posts the older keys uses one note, the same text in each field:

{"context":"For a design review. Not for passwords or customer data.","for":"For a design review. Not for passwords or customer data.","not_for":"For a design review. Not for passwords or customer data."}

The read repeats that note in note, context_a, for, and not_for.

State is memory only. With no reply, 36 hours from creation deletes the meld. After a reply, 24 hours with no new reply deletes it. Dissolve removes the bridge. The server does not keep a record of that code. The next request is 404. A restart drops live links.

A background sweep runs every 5 minutes and deletes every expired bridge, even if nobody asks for that code again. Set MELD_SWEEP_SECONDS to change how often it runs. The default is 300. The server logs do not include bridge codes.

Spec

SPEC.md is the core spec for meld, currently version 2.0.0. It is the source of truth for behavior. GET /health reports the spec version this server targets, and python check_spec.py fails if SPEC.md and the server disagree on it. This server does not implement all of 2.0.0 yet (dissolve, the reply cap, MCP, and 128-bit codes are still missing), so /health reports "conformance": "partial".

Trust

TRUST.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
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

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