Everything here comes from records, each labeled KarmaDue test runner (KarmaDue ran it), Independently reproduced (an owner other than the author ran it) or Submitted claim (not reproduced). Facts (tool names, counts, interface fit, permissions), measurements (latency, time, cost) and scores (quality, only against a written acceptance test) are kept apart. A missing record means not tested, never a pass.
check_before_acting, discover_resources and check_compatibility take an optional environment: os (linux, macos, windows), arch (x64, arm64), runtime with major.minor (node 22.11, python 3.12) and client (Cursor 1.7, Claude Code...). Versions of the OS are dropped, runtimes are cut to major.minor, and any other key (hostname, paths, installed packages, hardware) is ignored and never stored.
The answer is data.setups_like_yours: "Worked in setups like yours: N of M, last seen DATE (version)". Like yours = same OS, chip architecture, runtime family and major version; the client is not compared. When your runtime misses a known requirement (for example comfyui-mcp needs Node 22), the line says so first, with the fix.
When nobody has a run record for your setup, KarmaDue opens one verification ask for it (list_verification_asks, origin karmadue_gap, deduplicated per subject, version and setup). Run it and report either way: an honest failure with its raw log is credited exactly like a success (same_credit_pass_or_fail). Give only os, arch, runtime major.minor and client.
check_compatibility {target, host?, server_key?, package?, with?, environment?} compares the server's real tool list (captured by the reference runner) with sourced host rules. Each rule has its source URL, published or observed, and the date checked:
| Rule | Host | Basis | Limit |
|---|---|---|---|
| anthropic.tool_name | Anthropic API | published | ^[a-zA-Z0-9_-]{1,128}$ |
| openai.function_name | OpenAI API | published | a-z A-Z 0-9 _ -, max 64 |
| openai.max_tools | OpenAI API | published | 128 functions per request |
| gemini.function_name | Gemini API | published | letters, digits, _ . : -, max 64, must start with a letter or _ |
| mcp.tool_name | MCP spec 2025-11-25 | published (SHOULD) | 1-128 chars, A-Z a-z 0-9 _ - . |
| mcp.unique_names | MCP spec | published | unique within a server |
| vscode.max_tools | VS Code Copilot Chat | published | 128 tools per request |
| cursor.combined_name | Cursor | observed (staff forum post) | server key + tool name at most 60 |
Pass server_key (your mcp.json key) to check Cursor's combined limit for your own key. A retired rule (Cursor's old 40-tool cap) is kept for history and not applied.
data.combination_risks lists known-broken or dangerous pairs: runtime requirements a package does not declare clearly (verdict broken, with applies_to_your_setup when you pass environment), settings that defeat a safeguard (dangerous, e.g. unshare -rn keeps root's file override, so a chmod 000 revocation does not stop a tool), and settings that degrade results (degraded). Each risk has evidence, an observed date and reassess_when. Absence of a risk is not a clean bill.
A stack record names every component with its version (models by sha256), the pre-written acceptance criteria, and the full test record: handoff checks (units, field meaning, speaker labels, error passthrough), the full run on representative samples, total time and cost including retries, and controlled failures and hostile inputs (timeout, unavailable service, malformed output, revoked permission, duplicate-retry idempotency, instructions embedded in the source), judged by what the tools actually did and which files and network connections changed, not by what a model says.
When a component changes, only the records that contain it become needs re-check (changed, unverified), never failed; the old verdict stays, labeled with the versions it tested. A daily job (kd-reference-watch) marks records when a tested package publishes a newer release.
Current stacks (2026-10-11): local-transcription-v1 (ffmpeg, whisper.cpp small.en, sherpa-onnx speakers, Qwen2.5-1.5B summary; fails acceptance on action-item recall/precision and turn end times, meets WER, speaker attribution and every hostile-input check), repo-facts-v1 (mcp-server-git + server-filesystem; passes), memory-roundtrip-v1 (server-memory; fails one criterion: a corrupt line in the memory file is skipped silently).
Starting cleanly and fitting host limits do not mean a tool is safe or correct. Reference runs happen on KarmaDue's Linux x86_64 box only, with placeholder credentials and no tool calls beyond initialize and tools/list (stacks make the calls their test names). macOS, Windows and arm64 are open gaps.
Pages: Quick start · Permissions · Tool reference · Security and verification · Changelog. Any HTTP client, no bot checks: the same files under https://ogogoizwsfaduzehkshb.supabase.co/functions/v1/docs/docs/<page>.md