Skip to main content
Glama
wudpecker

Worth Sending

Official
by wudpecker
README.md
# Worth Sending

**Does this adoption message earn the recipient's attention?**

Worth Sending is a small MCP server that applies an evidence-based rubric to
product-adoption messages. An agent supplies a draft, recipient context, evidence,
and its assessment. The server returns **send**, **revise**, or **hold**, with a
score and the reasons behind the recommendation.

Created by **Userlens**. MIT licensed. Runs locally with Node.js 20 or later.
No separate model API key, account, database, or hosted service is required.

> **Release candidate:** v0.1.0 is available from the `feat/initial-release`
> branch for review. An npm registry release has not been published.

## Try it

```sh
git clone --branch feat/initial-release https://github.com/wudpecker/worth-sending-mcp.git
cd worth-sending-mcp
npm ci
npm run example
```

The synthetic weekly-report example returns a recommendation including:

```json
{
  "rubric_version": "0.1",
  "decision": "send",
  "score": 93.75,
  "summary": "All required checks, dimension minimums, and the send threshold pass.",
  "assessment_source": "calling_agent",
  "recommendation_only": true
}
```

A draft with no recipient context returns `hold` and `score: null`:

```sh
node bin/worth-sending.js evaluate examples/missing-context.json
```

## Connect an MCP client

For clients that use an `mcpServers` JSON configuration, add this entry. Replace
the path with the absolute location of your clone:

```json
{
  "mcpServers": {
    "worth-sending": {
      "command": "node",
      "args": ["/absolute/path/to/worth-sending-mcp/bin/worth-sending.js"]
    }
  }
}
```

If the client does not inherit your shell's PATH, use the absolute path to your
Node executable for `command`. Reload the client's MCP connections after saving.

You can also run the GitHub release candidate through npm, without a manual clone:

```json
{
  "mcpServers": {
    "worth-sending": {
      "command": "npx",
      "args": [
        "--yes",
        "--package=github:wudpecker/worth-sending-mcp#feat/initial-release",
        "worth-sending-mcp"
      ]
    }
  }
}
```

For reproducibility, replace the branch ref with a reviewed commit SHA. This
GitHub install runs local code and installs its npm dependencies. It is not a
remote MCP endpoint. Clients that accept only an HTTPS server URL need a future
hosted transport; this release supports stdio.

Do not use `npx worth-sending-mcp` as a registry shortcut yet: this project has not
published that npm package.

## Ask your agent

> Evaluate whether this adoption message is worth sending using Worth Sending.
> Read `get_message_rubric` first. Use the context and evidence I provide to judge
> each check and dimension, then call `evaluate_message`. Keep unknown facts
> unknown. Explain the recommendation and what would change it.

Provide the exact draft, recipient's goal and workflow, product eligibility,
channel and contact history, expected recipient benefit, intended sender outcome,
and source-dated evidence. See the [complete synthetic input](examples/weekly-report.json).
The tool can accept an incomplete packet and return the missing context.

## How it works

1. **`get_message_rubric`** provides the rating anchors and decision policy.
2. Your agent assesses the message using the evidence it has permission to use.
3. **`evaluate_message`** validates the packet, checks evidence references, and
   applies the fixed policy to the agent's judgments.

The same rubric is available as a resource at `worth-sending://rubric/v0.1`.

The calling agent judges meaning and evidence quality. The server has no built-in
LLM and does not independently verify facts or infer intent from a draft. It
validates structure, referenced evidence IDs, timestamps, and decision rules.
Fabricated evidence can still produce a bad recommendation. A `send` verdict is
a recommendation, not dispatch authorization.

| Dimension | Weight | Minimum for sending |
| --- | ---: | ---: |
| Recipient business value | 35% | 3/4 |
| Evidence of relevance | 25% | 3/4 |
| Timing | 15% | 2/4 |
| Actionability | 15% | 3/4 |
| Sender business outcome | 10% | 2/4 |

Ratings run from 0 to 4. The weighted total is out of 100. Under this initial
policy, 80 or more can receive `send`; 60–79.99 receives `revise` when the required
minimums pass; lower totals receive `hold`. Weak actionability can also require
revision above 80. Weak recipient value, relevance, timing, or business fit
overrides the total and produces `hold`.

Claims must be supported, the recipient must be eligible, the action must still
be needed, delivery must be allowed, and the contact window must be clear.
A failed or unknown check—or missing essential context or rating—produces `hold`
with no score. Malformed assessments, nonexistent evidence references, duplicate
evidence IDs, future evidence, and gates supported only by inference are rejected
as invalid input.

**Rubric v0.1 is a hypothesis.** The weights are not calibrated predictions of
ROI or conversion. Validate them against independent reviews and recipient
outcomes, including completed tasks, useful repeat behavior, and dismissals.
Use this policy for discretionary adoption nudges; operational or security
notices need a different policy. Read the [full rubric](rubric.md).

## CLI and library

```sh
node bin/worth-sending.js --help
node bin/worth-sending.js evaluate examples/weekly-report.json
node bin/worth-sending.js evaluate - < examples/weekly-report.json
```

Within a clone, the scoring function is also directly importable:

```js
import { evaluateMessage } from './src/evaluate.js';

const result = evaluateMessage(assessmentPacket);
```

The default executable starts the MCP server and waits for a client on stdin.
Use `node bin/worth-sending.js` in an MCP configuration. If you use npm scripts
instead, run `npm run --silent start` so npm's banner cannot pollute the protocol.
The `evaluate` CLI writes JSON and exits with status 0 for all valid decisions;
inspect `decision` to distinguish send/revise/hold. Invalid input exits with 1.

## Data handling

The server does not make outbound requests, log message content, write assessment
files, or send messages. Inputs and results travel through your existing MCP
client and may be subject to that client's model provider and retention settings.
All checked-in examples are synthetic.

## Development

```sh
npm ci
npm test
npm pack --dry-run
```

Tests cover policy thresholds and overrides, evidence validation, missing context,
MCP discovery and resource reads, structured results, errors, and recovery.
See [CONTRIBUTING.md](CONTRIBUTING.md) and the [release guide](docs/release.md).

Built with the [official MCP SDK](https://github.com/modelcontextprotocol/typescript-sdk).
See its [stdio client documentation](https://ts.sdk.modelcontextprotocol.io/v2/clients/connect)
for the local-process connection model.

## License

[MIT](LICENSE) © 2026 Userlens.

TDQS

A4.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one retrieves the rubric, the other performs the evaluation. The descriptions explicitly state that the rubric should be read first, eliminating any confusion about which tool to use when.

Naming Consistency5/5

Both tool names follow a consistent snake_case verb_noun pattern: get_message_rubric and evaluate_message. The slight variation in noun phrase length does not break the predictable convention.

Tool Count4/5

With only 2 tools, the set is slightly below the typical 3-15 range, but each tool is essential for the server's narrow purpose. The minimal count is justified by the focused workflow of fetching a rubric and then evaluating a message.

Completeness5/5

The two tools cover the full lifecycle for evaluating a message: obtaining the rubric and performing the assessment. No obvious operations are missing for the stated domain, and the server explicitly does not dispatch messages, so no send tool is needed.

Maintenance

ActivityMaintained
ResponsivenessNo issues