Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/cyanheads/reference-data-mcp-server/add-testnpx skills add cyanheads/reference-data-mcp-server --skill add-testgit clone --depth 1 https://github.com/cyanheads/reference-data-mcp-serverWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00041 | $0.03571 |
| Opus 5 | $0.00020 | $0.01785 |
| Sonnet 5 | $0.00008 | $0.00714 |
| Haiku 4.5 | $0.00004 | $0.00357 |
Grade A, and why
add-test scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to add-test — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 318 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Context
Tests use Vitest and createMockContext from @cyanheads/mcp-ts-core/testing. If the repo already has tests, match the existing layout. If the repo has no existing tests, create a root tests/ directory that mirrors the src/ structure (e.g. tests/mcp-server/tools/definitions/echo.tool.test.ts for src/mcp-server/tools/definitions/echo.tool.ts).
For the full createMockContext API and testing patterns, read:
skills/api-testing/SKILL.md
Steps
- Identify the target — which tool, resource, or service needs tests
- Read the source file — understand the handler's logic, input/output schemas, error paths, and which
ctxfeatures it uses - Create the test file in the repo's existing test layout — search for existing
*.test.tsfiles to confirm whether tests are colocated with source or under a roottests/directory - Write test cases covering happy path, error paths, and edge cases
- Run
bun run testto verify - Run
bun run devcheckto verify lint, types, and MCP definitions
Determining What to Test
Read the handler and identify:
| Aspect | Test Strategy |
|---|---|
| Happy path | Valid input → expected output. Include at least one. |
| Input variations | Optional fields omitted, defaults applied, boundary values |
| Error paths | Invalid state, missing resources, service failures → correct error thrown |
ctx.state usage |
Available on any mock context (tenant 'default' unless { tenantId } says otherwise). It runs the production storage path, so use storage-legal keys (cache/v1/abc, never cache:v1:abc) and assert TTL expiry with fake timers. |
ctx.requestInput / ctx.inputs |
Two rounds. First round: assert the handler throws the input-required signal (.rejects.toSatisfy(isInputRequiredSignal)), or catch it and assert on error.result.inputRequests. Second round: seed createMockContext({ inputResponses }) and assert the handler completes. Cover the decline/cancel branch too. |
ctx.signal |
Pass createMockContext({ signal: controller.signal }) and assert a long loop stops early rather than running to completion. |
ctx.fail (typed contract) |
Definitions with errors[] need fail attached to the mock ctx — createMockContext({ errors: myTool.errors }) does it for you. Assert on data.reason (stable per-contract entry), not just code. |
format function |
Test separately if defined — it's pure, no ctx needed. Verify it renders the IDs and fields the model needs, not just a count or title. For projection-style tools, test non-default field selections. |
| Sparse upstream payloads | For third-party API integrations, build a fixture with omitted fields. Assert normalized output still validates and format() preserves unknown values instead of inventing facts. |
| Form-client payloads | If handler has optional fields: test with empty-string inner values (form clients send "" instead of undefined). Assert handler doesn't break or produce invalid output. |
| Auth scopes | Not tested at handler level (framework enforces) — skip |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 318 lines · 41 tokens per session scan A 9ff05d2f4834
add-test is a skill published in the GitHub repository cyanheads/reference-data-mcp-server (1 stars, last pushed 9d ago), licensed Apache-2.0. It adds 41 tokens to every session and 3,571 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to add-test, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
bun-test
Complete guide to Bun's native test runner: writing tests, expect matchers, mocks, spies, lifecycle hooks, snapshots, code coverage, reporters, DOM testing, and test configuration.
bun-guides-test
Practical guides for testing TypeScript applications, mocking modules, mocking fetch, and running unit tests in Bun.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
api-testing
Testing patterns for MCP tool/resource handlers using createMockContext and Vitest. Covers mock context options, handler testing, McpError assertions, format testing, Vitest config setup, and test isolation conventions.
add-test
Scaffold a test file for an existing tool, resource, or service. Use when the user asks to add tests, improve coverage, or when a definition exists without a matching test file.
add-test
Scaffold a test file for an existing tool, resource, or service. Use when the user asks to add tests, improve coverage, or when a definition exists without a matching test file.