Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Resumable API pagination, repeated-failure detection and tool-progress cache hints for AI agents
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Download the maker’s .mcpb file
The link goes to the maker’s own file; we do not host or repackage it. Open the file and Claude Desktop installs it.
Run this in your terminal
Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account Warddamn, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (0.1.1) reached the registry last month.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need MCPB on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, AI Deprecations
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
Three deterministic helpers for agent developers, built by AVRG3: finish paginated jobs, interrupt repeated work that makes no progress, and report tool progress to a cache scheduler. No model calls, training, accounts, or telemetry.
Version 0.1.1: library, CLI and a separate three-tool MCP server. No model calls or telemetry. The cache bridge requires a compatible inference-serving integration; it does not control hosted-model caches or stock vLLM by itself.
Find a tool by task, with example inputs · Actual tool schemas · Public install.
Requires Node.js 20+. No npm account or source checkout is needed.
Claude Code:
claude mcp add tiny-runtime -- npx -y -p https://github.com/Warddamn/tiny-tools/releases/download/runtime-v0.1.1/tiny-runtime-0.1.1.tgz tiny-runtime-mcp
Cursor, Claude Desktop and other stdio MCP clients: add this server configuration. VS Code uses servers in place of mcpServers.
{"mcpServers":{"tiny-runtime":{"command":"npx","args":["-y","-p","https://github.com/Warddamn/tiny-tools/releases/download/runtime-v0.1.1/tiny-runtime-0.1.1.tgz","tiny-runtime-mcp"]}}}
MCPB-compatible clients: download the portable bundle and open it. It includes dependencies for macOS, Windows and Linux; a Node.js runtime is required. Bundles are unsigned; release checksums and registry hashes verify integrity. The smaller npx tarball downloads third-party dependencies at installation.
Claude Code plugin: /plugin marketplace add Warddamn/tiny-tools, then /plugin install tiny-runtime@tiny-tools. This adds the usage guidance as well. Choose either the plugin or manual MCP setup.
Three worked examples with expected answers · GitHub downloads · Official MCP Registry
JavaScript/TypeScript library: install the same public tarball with npm install https://github.com/Warddamn/tiny-tools/releases/download/runtime-v0.1.1/tiny-runtime-0.1.1.tgz, then import collectPages, RepeatGuard or ProgressBridge from @tiny_tools_pw/runtime. This is a GitHub-hosted package, not an npm registry listing.
complete, partial, or failed. Durable checkpoints let a new run pick up after the last committed page.retain, prefetch, or release hints. A host adapter applies them; the MCP tool only writes a plan.These solve known engineering problems, not previously empty categories. MCPProxy already has batching/pagination recipes; other projects implement loop detection and caching. This package focuses on explicit failure semantics, reusable integration, and tests. It is not a generic proxy for every MCP server.
Requires Node.js 20+. From the repository root:
npm ci
npm run build npm run demo:runtime node packages/runtime/dist/cli.js collect packages/runtime/examples/collect.json --output-dir /tmp/runtime-results node packages/runtime/dist/cli.js check packages/runtime/examples/guard-trace.json --output-dir /tmp/runtime-results node packages/runtime/dist/cli.js plan packages/runtime/examples/progress-trace.json --output-dir /tmp/runtime-results
Each job creates its own directory and returns absolute artifact paths. CLI exit code is 0 for successful work and 1 for an error or incomplete collection. Partial records and their checkpoint remain available. No input file is overwritten. Job output files use owner-only permissions where supported; the parent directory's permissions still matter.
For an MCP client, replace the example path with your checkout's actual path:
{"mcpServers":{"tiny-runtime":{"command":"node","args":["/absolute/path/tiny-tools/packages/runtime/dist/mcp.js"]}}}
Add the eight-line usage snippet to your agent instructions. For automatic operation without additional model turns, integrate the SDK rather than asking the model to repeatedly call trace-analysis tools.
The included examples/collect.json reads a local synthetic page manifest. A file source is an object containing pages, each with a request cursor (null for the first page) and a page containing items and required nextCursor. Only explicit nextCursor: null means the source is exhausted. Empty pages may still have a next cursor. File paths in a config are resolved relative to that config.
A configured HTTP source uses GET only, on exactly the supplied origin/path. Example (the domain is a placeholder, not a real service):
{
"source": { "type": "http", "url": "https://api.example.com/records?status=open", "itemsPath": "data.records", "nextCursorPath": "pagination.next_cursor", "cursorParam": "cursor", "totalPath": "pagination.total", "snapshotPath": "snapshot_id", "bearerEnv": "RECORDS_API_TOKEN", "scope": "account-and-filter-identity" }, "key": "id", "sumFields": ["amount_cents"], "maxPages": 100, "maxRecords": 10000, "maxBytes": 16000000, "timeoutMs": 30000 }
totalPath, snapshotPath, and bearerEnv are optional. If configured, missing metadata fails the page. Paths use dot-separated own object keys; literal keys containing dots are unsupported. API mapping is explicit, never guessed. Returned cursors remain opaque query-parameter values, not URLs. Redirects are rejected. Keep authentication in the tool host environment; configs and checkpoints never store the resolved bearer token. Use HTTPS except for explicit local test endpoints. Do not put secrets in URL query parameters.
Prefer provider-side aggregation/filtering to fetching unnecessary records. APIs using Link headers, offsets, GraphQL POST, or tool-specific protocols need a small SDK adapter:
import { collectPages } from '@tiny_tools_pw/runtime';
const result = await collectPages({ sourceId: 'account/dataset/filter/version', key: 'id', sumFields: ['amount_cents'], fetchPage: async (cursor, signal) => { const response = await yourReadOnlyClient.list({ cursor, signal }); return { items: response.records, nextCursor: response.next ?? null }; } });
Only map absent response.next to null when the provider's documented contract says it means the end. Callbacks must honor AbortSignal to stop their own I/O. The collector returns promptly even if an adapter ignores cancellation, but cannot kill arbitrary callback work.
Resume a CLI collection:
node packages/runtime/dist/cli.js collect /absolute/path/job.json --checkpoint /absolute/path/tiny-runtime-abc/checkpoint.json
Every accepted page is checkpointed before requesting another. timeoutMs covers collection, fetches and awaited callbacks; job setup, validation and safe filesystem finalization add overhead. Arbitrary synchronous callbacks cannot be interrupted, and timed-out custom adapters must stop their own work. MCP clients that request progress receive committed-page notifications; cancellation stops further requests and preserves committed work. Resumption creates a fresh directory, preserving the original checkpoint. maxPages is per invocation; record and byte budgets include previously committed pages. Increase limits to accept an oversized page; the collector never saves half a page. Default maximum response page size for HTTP is 1 MB (hard cap 8 MB), records 10,000 (hard cap 100,000), collection bytes 16 MB (hard cap 64 MB), and timeout 30 seconds (hard cap 5 minutes). No automatic retries, backoff, parallel fetching, or writes to the source.
With key, identical duplicates are counted once, and conflicting versions of an ID fail the entire new page. Without key, all rows are preserved. Declared total must refer to unique records when a key is used, all rows otherwise, and remain constant. Sums use BigInt internally and return strings; use integer minor units such as cents or integer strings, not rounded decimal numbers. Use tiny-context's query_table for decimal/statistical work.
Completeness has a precise limit: complete means the configured source explicitly ended and all configured metadata checks passed. It cannot expose hidden provider limits, a lying total, or missing records in the source. A stable snapshot/total improves evidence. Resume requires the same source/mapping/scope and aggregation; update scope when accounts or filters change. Checkpoint SHA-256 detects accidental corruption, not malicious tampering. Checkpoints contain records and cursors and should be protected like the source data. The CLI/MCP jobs write one immutable page delta and a small atomic commit pointer per page, then one compatible version-1 snapshot on return. Interrupted jobs retain a version-2 journal; keep its entire job directory together and resume via the CLI/MCP or readCheckpoint(path). Old version-1 snapshots still work. Journal recovery caps total JSON bytes read at 128 MB (64 MB per file), independently of untrusted metadata counters; the SDK can request a smaller read budget. SDK users can pass new CheckpointStore(freshDirectory).save as onPage after initialize(checkpoint); call drain() before finalizing. The older onCheckpoint callback remains snapshot-based and can be expensive on long jobs.
A trace is { "observations": [...], "nextAttempt": {...}, "options": {...} }; see examples/guard-trace.json. Each observation includes attempt (scope, tool, JSON args, optional state), outcome, and optional stateAfter. Use fingerprint() over measured file/repository state, an etag, or a source version. Include every dependency that can change whether the operation succeeds. An incomplete fingerprint can cause false positives. Never accept a model's self-reported “I made progress” as evidence.
import { RepeatGuard, runGuarded, fingerprint } from '@tiny_tools_pw/runtime';
const guard = new RepeatGuard({ threshold: 3, window: 100 }); const attempt = { scope: workflowId, tool: 'run_tests', args: {
Only the beginning is shown; read the rest in the repo