Skip to main content
Glama

SPARDA

πŸ‡«πŸ‡· FranΓ§ais β€” L'IA Γ©crit. SPARDA prouve. Un gate dΓ©terministe et hors-ligne qui dΓ©tecte quand une modif d'IA retire une garde, expose une route ou casse un invariant β€” sans clΓ© API, directement dans la boucle d'Γ©dition de l'agent. Pour tout comprendre en 10 minutes (douleur, architecture, vision) : SPARDA-EXPLIQUE.md.


The trust layer for AI-written backends. SPARDA compiles your backend β€” routes, database queries, state mutations, guards, side-effects β€” into one deterministic behavior graph, then statically proves what can and can't break before you ship: no unguarded mutation, no broken invariant, no non-atomic aggregate write.

npm CI node runtime deps license

100% local Β· deterministic Β· zero API key Β· no cloud account. It fails loudly on a real risk, and when it can only see part of your app it says PROVEN (PARTIAL) β€” never a false green. And when it can prove it was not even looking at your whole app, it says PREMISE NOT VERIFIED and claims nothing at all.

60-second proof

From your Express, FastAPI, Flask, Next.js, NestJS or Medusa app β€” nothing to configure:

npx sparda-mcp apocalypse   # prove the tree is safe to deploy β€” exit 1 on any real risk, or on an unverified premise
npx sparda-mcp prove        # the whole verdict: proof + coverage + shareable seal
npx sparda-mcp badge        # a README badge: proven Β· coverage% Β· routes

Under the hood it compiles your backend into one language-agnostic graph β€” the Unified Behavior Graph (UBG), serialized as .sparda/ubg.json under the SBIR specification (SPARDA Behavior IR) β€” and every command is a pass over that graph.

Related MCP server: mcp-anything

The wedge β€” catch an AI edit that removes a guard, in the loop

The one thing a text-diff review and a pattern scanner structurally can't do: prove that this specific edit dropped a protection the previous version had. sparda gate diffs the behavior graph before/after an edit and blocks a regression β€” deterministic, offline, sub-second, exit 2 (the Claude Code PostToolUse contract that stops the agent's edit loop). See it end-to-end in one command, zero setup:

npm run wedge     # (from a clone)  β€” or drive it on your own app with `sparda gate --arm` then `sparda gate --hook`
  1. baseline armed on the guarded code   (POST /admin/delete-user Β· requireAdmin)
  2. an AI edit "simplifies" requireAdmin β†’ a pass-through (still compiles, still 200s)
  3. sparda gate on the edit:
       βœ— [critical] GUARD_REMOVED β€” POST /admin/delete-user was guarded in the baseline
                    and is now reachable without any guard (src/app.js:11)
     ⏱  ~40 ms · deterministic · offline · no API key
     β›” exit 2 on --hook β€” Claude Code PostToolUse blocks the edit

Wire it into Claude Code in one line β€” the plugin registers a PostToolUse hook that runs npx -y sparda-mcp gate --hook after every Edit/Write, so a guard-removing edit is caught before it lands.

IMPORTANT


The Route-Compilation Proof β€” reproduce it yourself. SPARDA compiles real open-source monsters to their behavior graph with zero crashes, each in β‰ˆ1–2 seconds: Next.js Dub (579 routes), NestJS Immich (281), MedusaJS (477). It natively resolves deep Dependency Injection, external controllers, and Next.js handlers. One command clones them and re-measures on your machine:

node bench/repro.mjs        # β†’ bench/route-proof.json

Honesty first: compiling a route is a parser result (the number above); proving it safe is a separate per-repo verdict β€” and most real apps come back NOT_PROVEN, which is the true state, not a failure. (Our full 25-repo corpus stress compiles 3,565 routes at ~150 routes/s; that one needs the corpus checked out.)

What the graph unlocks β€” 100% local, deterministic, 4 exact-pinned dependencies, zero API key:

Command

What it does

prove

The whole trust verdict in one gesture β€” proof + coverage + premise check + a shareable seal (--json / --markdown)

apocalypse

Prove the deploy β€” no guard, invariant, transaction or aggregate boundary can be broken (SARIF + CI gate)

heal

Self-heal, proven β€” the gate Copilot Autofix doesn't have: a fix ships only if replay matches, verify still passes, and apocalypse finds no new risk / no dropped guard. Whoever wrote the fix, the machine judges it.

badge

The shareable artifact β€” a self-contained SVG badge + README snippet (verdict Β· coverage Β· routes)

dossier

The public report β€” one self-contained HTML page: verdict, risks, and SPARDA's own blind spots

ubg

Compile the codebase to its behavior graph (Express Β· FastAPI Β· Flask Β· Next.js Β· NestJS Β· Medusa natively; any stack via OpenAPI)

timeless

Time-travel β€” record a production request, replay it byte-identically, export the bug as a test

mirror

Execute the graph β€” serve the compiled behavior over HTTP with no framework and no source

init / dev

Runtime, optional β€” expose the graph to AI clients as a live MCP server (+ Twin, Immune, Evolution)

The prover is the product. The MCP server is one output of the graph, not the point β€” SPARDA compiles the whole system's behavior, then proves, replays, heals, and (optionally) serves it.

Nomenclature: SBIR is the specification (the format, like "JSON"); UBG is the compiled graph itself (the artifact, ubg.json). The MCP server is one output of the graph, not the product.

Optional: expose the graph to AI clients (MCP runtime)

Beyond proving, SPARDA can turn your running app into a live MCP server β€” the graph, executable, with write-safety and an immune layer. This is optional and separate from the prover above.

  1. Scan + inject β€” run once, from your app's directory:

    npx sparda-mcp init

    SPARDA parses your routes (AST), generates a marked /mcp router, injects it into your app (with a backup), and writes sparda.json. Every step is reversible.

  2. Start your app, then start the bridge:

    npx sparda-mcp dev
  3. Connect your client. init prints a ready-to-paste block for claude_desktop_config.json, pre-filled with your app's name and path:

    {
      "mcpServers": {
        "your-app": {
          "command": "npx",
          "args": ["sparda-mcp", "dev"],
          "cwd": "/absolute/path/to/your-app"
        }
      }
    }

    Claude Code connects to the same bridge. That's it β€” your running app is now a set of MCP tools your AI can call.

Try the Standalone Demo

To see SPARDA in action instantly without modifying your codebase:

npx sparda-mcp demo

This runs the entire MCP lifecycle (detect β†’ parse β†’ generate β†’ inject β†’ remove) on a bundled demo app in a temporary folder, in about 10 seconds. For the compiler itself, run npx sparda-mcp ubg then apocalypse on any Express/FastAPI app.

Black Box Report

SPARDA is designed as a local organism. To see what it remembers and how much compute it has recycled:

npx sparda-mcp report

This prints a terminal dashboard aggregating your exposed tools, write opt-ins, proof journal decisions, and crystallized composite tools.

To write a self-contained, offline HTML dashboard at .sparda/report.html, append the --html flag:

npx sparda-mcp report --html

To output raw JSON for integration:

npx sparda-mcp report --json

Deployment Proof: Apocalypse

SPARDA's Behavior Graph is a formal model of your system. Instead of waiting for runtime failures or relying on static analysis vibes, you can statically prove the safety of your backend before any deployment:

npx sparda-mcp apocalypse

This command reads the compiled .sparda/ubg.json (with zero source code parsing at runtime) and discharges five static correctness obligations:

  • Unguarded Mutation (Critical): Flags any mutation path that does not cross a security guard.

  • Non-Atomic Aggregate Write (High): Flags when an API writes to multiple tables of the same Consistency Domain (Aggregate) outside a single transaction scope.

  • Unvalidated Constrained Write (Medium): Flags writes into columns with declared invariants (CHECK, NOT NULL, UNIQUE β€” parsed from your .sql DDL or schema.prisma, Prisma enums included) without prior validation (Zod/Pydantic).

  • Irreversible Observable Effect (High): Flags out-of-process actions (like Stripe charges) that happen alongside state writes without a structural compensation path (like a catch-refund).

  • Taint Flow Analysis (High): Tracks untrusted input variables through the AST to ensure they do not corrupt critical sinks.

  • Guard Dominance (Medium): Proves that top-level security guards cannot be bypassed by nested or overlapping sibling routes.

  • Aggregate Member Bypass (Info): Flags mutating a member table directly without routing through the aggregate root.

To save your current graph as a safe baseline:

npx sparda-mcp apocalypse --save-baseline

Subsequent runs will diff the candidate graph against this baseline to detect regression vectors:

  • Deletion of any security guard (Critical).

  • Deletion of a database SQL invariant (High).

  • API blast radius expansion (Medium).

If any Critical or High finding is found, apocalypse exits with a non-zero code to block your CI pipeline.

One step in your workflow β€” findings land in the GitHub Security tab (SARIF):

- uses: zakariagharzouli/sparda@main
  with:
    sarif: 'true'

Time Travel: Timeless

Every production request is deterministic between its effects β€” the compiler knows exactly where the nondeterminism lives (db, http, clock, random, uuid: the effect nodes of the graph). Timeless records only those points (a few KB per request) and replays the request byte-identically against your current code, with the database, webhooks and clock virtualized from the recording:

npx sparda-mcp timeless                # list recorded flights
npx sparda-mcp timeless replay <id>    # re-fly it β€” byte-identical or loud divergence
npx sparda-mcp timeless export <id>    # the production bug is now a vitest test

Recording is two lines in your app (ESM), with deterministic sampling and GDPR redaction built in:

import { getFlightBox } from 'sparda-mcp/src/flight/box.js';
const box = getFlightBox();
box.arm();
app.use(box.middleware({ sample: 100 })); // 1 request in 100; passwords/tokens redacted by default
const db = box.wrapClient(pgPool); // your query client, tapped

The closed loop nobody else has: production bug β†’ recorded flight β†’ failing test β†’ AI writes the fix β†’ apocalypse proves the fix breaks no guard, invariant or transaction β†’ deploy. Replay is per-request (concurrent-race capture is out of scope for v1 β€” stated, not hidden).

Self-Healing, Proven: sparda heal

The loop above, as one gesture β€” and the machine judges the fix, whoever wrote it:

npx sparda-mcp heal <flightId>                       # diagnose + write the fix brief
# ...apply the fix (a human, or --agent "your-ai-cli")...
npx sparda-mcp heal <flightId> --check --expect '{"status":404}'

The brief is built from the graph itself β€” it hands the fixer the handler's file:line, the capabilities the fix must not grow, and the guards it must not remove. Then the gate β€” the actual product β€” proves the fix on three axes at once:

  1. Behavior β€” lenient replay of the recorded flight (same deterministic inputs) now produces the expected response, not the recorded bug. The fix may reformulate a query (the tap is relabeled, allowed); it may not change the effect order or kinds.

  2. Compiler laws β€” verify still passes: the graph is still sound and deterministic.

  3. No regression β€” apocalypse diff against the frozen pre-fix graph: zero new critical/high findings, no guard removed, no blast radius grown.

βœ“ HEALED & PROVEN β€” same recorded inputs, correct output, zero law broken, zero protection lost. Ship it.

The gate is honest in both directions: an unfixed bug, or a "fix" that silently drops a guard, keeps it closed (exit 1). This is the difference between an AI that writes plausible code and a system that proves the code is correct β€” the trust layer the agent era is missing.

Any Backend On Earth: OpenAPI Lowering

SPARDA parses Express, FastAPI, Flask and Next.js natively β€” and every other stack through the format the industry already agreed on. Go, Java, Rails, Laravel, .NET: if it has an OpenAPI spec, it compiles.

npx sparda-mcp ubg --openapi openapi.json

Security schemes become gating guard nodes, response schemas become typed returns, declared request bodies count as validated input. Pair the spec with your .sql or schema.prisma files and the full state layer β€” invariants, aggregates, state machines β€” fills in from declared truth. (JSON specs in v1; we refuse to half-parse YAML with zero dependencies.)

The Mirror VM: delete the framework, the app still answers

The graph is not a diagram β€” it executes:

npx sparda-mcp mirror
MIRROR β€” the graph is serving. 3 entrypoint(s) on http://127.0.0.1:4477
  GET    /orders/{orderId}  β†’ {amount, id, status}
  POST   /orders  πŸ”’ bearerAuth  β†’ {amount, id, status}

No Express. No FastAPI. No source code β€” just ubg.json answering HTTP: guards actually deny (401), responses render the compiled return schemas, unknown paths 404 with the full route table. Front-end teams develop against backends that aren't deployed yet β€” or aren't written yet (point mirror at an OpenAPI spec). Every response carries x-sparda-mirror: true; the mirror serves declared behavior, it never invents business values.

To undo everything: npx sparda-mcp remove restores your code byte-for-byte.

The promise β€” every word is backed by a test in CI

  1. Three minutes, one command. AST scan, router generation, reversible injection β€” no config.

  2. Try it for free, leave for free. npx sparda-mcp remove restores your code byte-for-byte (tested on JS, TS, Python, even Windows CRLF files). No trace, no lock-in.

  3. The AI cannot write until you say so. Every POST/PUT/DELETE is disabled by default; you enable per tool, and your choice survives every re-run.

  4. Your app defends itself. A route failing 3 times in a row is quarantined β€” the AI can't hammer your broken production. Latency anomalies are flagged. Zero LLM needed.

  5. Nothing leaves your machine. No telemetry to us, no cloud, local key auth, 4 exact-pinned dependencies.

  6. What it learns is never lost. Diagnoses, descriptions, settings β€” versioned with your git, surviving every re-init.

What we don't promise: the honest limits in docs/SECURITY.md.

How it works

  1. npx sparda-mcp init parses your codebase (AST), extracts every route, and injects a tiny marked router (/mcp) into your app β€” fully reversible with npx sparda-mcp remove.

  2. Tool calls run inside your live app process β€” warm DB pools, real auth chain, real data. SPARDA adds no infrastructure: compute comes from your host process, intelligence from your AI client's own model (MCP sampling), storage from sparda.json + git.

  3. Write tools (POST/PUT/DELETE) are disabled by default. You opt in per tool in sparda.json β€” your choices survive re-runs.

  4. Suspicious docstrings are sanitized before they ever reach the AI (prompt-injection defense).

  5. npx sparda-mcp doctor --app audits your codebase for drift: it detects stale tools (IA seeing ghosts), unsynced routes, schema drift via fingerprints, and zombie configurations. High severity issues trigger a non-zero exit code for your CI pipeline.

  6. npx sparda-mcp seed export/import lets you package and share your app's "genome" (semantic memory, workflows, antibodies) securely, transferring immune memory between environments or across similar stacks with zero data leak.

  7. npx sparda-mcp twin starts a safe, simulated mock server of your backend on the original port. It serves GET calls from learned exemplars (observed response shapes & mock data) and returns simulated 202 writes without ever touching your real database or production APIs. Learn exemplars by running npx sparda-mcp twin --learn.

  8. npx sparda-mcp grammar maps the graph of valid sequences of tool calls (observed circuits and candidate hypotheses) to prevent LLM hallucination of routes.

  9. npx sparda-mcp evolve mutates candidate chains and tests them against the twin in-memory, promoting successful chains to evolved workflow suggestions.

What SPARDA gives your AI

Operate, not just read

Every route becomes a tool that runs against your live process β€” real auth, real data, warm connections. One call to sparda_get_context hands the AI the whole living picture: enabled tools, suggested workflows, runtime telemetry, quarantine state, and immune memory β€” so every session resumes where the last one stopped.

Prove the edit before you commit β€” the one check an LLM can't do to itself

The AI just edited a route. Did it quietly drop a guard? It calls sparda_prove and finds out now, not in a CI run later. The tool recompiles the app to its behavior graph, discharges the same static obligations as sparda apocalypse, and returns a deterministic verdict β€” the exact word the CLI and badge emit, so it can never over-claim (a low-coverage clean app reads SURFACE, never a bare PROVEN). Save a baseline once (sparda apocalypse --save-baseline) and every later sparda_prove flags any finding with regression: true β€” the guard your edit removed, the route it dropped, the blast radius it grew. That's "AI writes. SPARDA proves." inside the edit loop. Clients that list MCP prompts also get the prove-my-edit workflow.

Write-safety: the AI can't write until you say so

  • Writes (POST/PUT/DELETE) ship disabled. Enable them per tool in sparda.json; your choice survives every re-init.

  • An enabled write is never executed on the first call. SPARDA returns an awaiting_confirmation envelope β€” a single-use token plus a preview of the action β€” and commits only after an explicit confirm step.

  • When your client supports MCP elicitation, that confirmation prompt appears in the AI's own UI.

  • Proof-after-write: every successful write is followed by a read-back of the same resource, so the AI β€” and you β€” see the real effect, not a hopeful guess.

Your app defends itself β€” zero LLM on the hot path

  • Quarantine. A tool that returns 3 consecutive 5xx is quarantined: further calls get a 503 with a reason and a retry delay instead of hammering your broken route. After a cooldown it half-opens for a single probe.

  • Latency & anomaly flags. The router learns each route's baseline and flags deviations locally, in a few lines of math.

  • Adaptive diagnosis, only on surprise. A genuinely new failure wakes your AI client's own model to diagnose it once; the diagnosis is cached as an "antibody" in sparda.json, so the same failure later costs zero tokens. Cloning your code doesn't clone its immune memory.

A free intelligence layer, zero API key

On first connection your AI client's own model (via MCP sampling) rewrites raw routes into business-language tool descriptions and proposes multi-step workflows β€” cached in sparda.json and exposed as MCP prompts. Nothing to configure, nothing to pay.

It gets cheaper the more you use it

  • Response recycling. When a read keeps returning the same answer, SPARDA serves the next identical call straight from memory β€” without touching your host app. Reads only; writes always hit the host.

  • A recycling gauge. GET /mcp/stats counts how many calls were answered from SPARDA's own knowledge vs. how many paid the host route. It reads 0% on day one and fills with usage β€” a measure, never a promise.

Tools nobody wrote β€” Labs, opt-in, default OFF

Turn it on with "labs": { "recordSequences": true } in sparda.json. SPARDA then notices when one tool's output feeds the next tool's input and records the circuit β€” structure only (tool names, argument names, counts), never your data. A read-only circuit seen enough times crystallizes into a composite tool, announced mid-session: one call runs the whole chain, auto-feeding each step from the previous step's real response. Write routes are never absorbed β€” their per-call confirmation always stands.

Living context & telemetry

GET /mcp/stats (per-tool calls/errors, tool "purity", quarantine state) and GET /mcp/events (errors, latency anomalies, cached diagnoses) expose exactly what your app is doing β€” surfaced to the AI as live notifications.

Built for AI clients: the bundled Skill

SPARDA ships with an Agent Skill (SKILL.md) that teaches any compatible AI client how to drive a SPARDA server to its full potential β€” call sparda_get_context first, exploit response recycling, honor quarantine, prefer crystallized circuits over re-walking a chain, and follow the two-phase write-confirm protocol. The live, per-project tool list always comes from sparda_get_context at runtime, so the guidance never goes stale.

Supported frameworks

  • Next.js App Router (13/14/15) β€” file-based injection. SPARDA creates a catch-all route handler. It natively resolves wrapped handlers (export const POST = withAuth(h)) and deep effect chains.

  • NestJS β€” AST-based router injection. Deeply resolves Multi-hop Dependency Injection (Controller β†’ Service β†’ Repository), inherited DI, and baseUrl/paths imports. Fully supports composite decorators (applyDecorators). Resolves ORM writes: Prisma, Kysely, and TypeORM injected repositories (@InjectRepository(Entity) β†’ this.repo.save()).

  • Strapi β€” Native AST ingestion of Strapi content-types, core controllers, and custom routes.

  • Express 4/5 (JS/TS, ESM/CJS) β€” AST-based router injection. Deeply resolves external controllers, Mongoose schemas, barrel re-exports, and inline handlers. Uses dynamic tree-scanning to find non-standard entry points (bootstrap.ts, etc).

  • MedusaJS β€” Native AST ingestion of complex e-commerce routing.

  • Any Backend On Earth (Go, Java, Rails, Laravel) β€” Compiles flawlessly from OpenAPI 3.x specs.

  • FastAPI (Python >= 3.9) β€” AST-based router injection.

Effects it resolves (what makes the irreversibility & atomicity proofs bite)

  • Databases β€” Prisma (incl. named/multiline relations and interactive $transaction(tx β‡’ …)), TypeORM, Kysely, Drizzle, Knex, Sequelize, Mongoose, and raw SQL. Foreign keys become aggregate/consistency domains, so a multi-table write outside a transaction is caught.

  • External side-effects β€” recognized by call shape and by import origin, so an irreversible outbound effect next to a DB write is proven compensable-or-not: fetch/axios/got, Stripe, Twilio, SendGrid/Resend/nodemailer, AWS SDK v3 (send(new PutObjectCommand())), and other payment/mail/cloud/queue clients. A read on such a client stays a non-observable GET β€” no false alarms.

Security posture (honest)

  • 4 runtime dependencies, exact-pinned.

  • Dynamic Local Key Resolution. The generated router contains no baked secrets. It resolves authorization keys at runtime from the SPARDA_LOCAL_KEY environment variable or the local gitignored .sparda/key file, and fails closed (503) when neither is found. For custom production or staging setups, you can override this behavior by exposing SPARDA_LOCAL_KEY in your environment.

  • Local key on every router call; self-reference loop protection; 30s timeouts; 8 KB output truncation.

  • AST-positioned injection with backup and post-injection re-parse; npx sparda-mcp remove leaves a clean git diff.

  • Persistence is value-free: SPARDA records structure (tool names, field names, fingerprints), never your payloads.

Full threat model and known gaps: docs/SECURITY.md.

Documentation

Beyond the open core

SPARDA is free, including in production (see License). Team-scale capabilities β€” fine-grained per-person access policies and a signed, tamper-evident audit log β€” are planned for a future paid tier. The open core stands on its own; nothing here is crippled to upsell you.

License

Business Source License 1.1 β€” free to use, including in production. You may not resell SPARDA or offer it as a competing commercial service. Each version converts to Apache 2.0 four years after its release.

By Residual Labs

Available Tools

5 tools
get_api_users_by_idA
Read-onlyIdempotent

Get a single user by id

ParametersJSON Schema
NameRequiredDescriptionDefault
idYespath parameter

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral information beyond what is already in the annotations.

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 a single sentence, exactly as long as needed, with no redundant information.

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?

Given the tool's low complexity (single parameter, no output schema), the description is adequate. It could mention the return value but the purpose is clear.

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 coverage is 100% with a description for 'id' ('path parameter'). The tool description does not add any additional meaning beyond the 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 'Get a single user by id' clearly states the verb+resource and matches the tool name. It distinguishes from sibling tools like 'get_api_prospects' which target a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not indicate when to use this tool vs alternatives, nor does it mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_healthA
Read-onlyIdempotent

Health check β€” returns service status and uptime

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that it returns service status and uptime, which provides some behavioral context but does not disclose any additional traits beyond what annotations cover.

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 a single concise sentence, front-loaded with the key term 'Health check', with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, no output schema, and annotations covering safety, the description sufficiently explains the tool's purpose and output ('service status and uptime'). It is complete for a simple health-check tool.

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?

There are no parameters, and schema coverage is 100% (trivially). The description does not need to add parameter details; a baseline score of 4 is appropriate given no 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 clearly states the tool is a health check that returns service status and uptime. It uses a specific verb 'returns' and resource 'service status and uptime', distinguishing it from sibling tools.

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?

The description does not provide explicit guidance on when to use this tool versus alternatives. However, the purpose is simple and self-explanatory, so usage context is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sparda_confirmA

Confirms a pending write or delete operation gated by human-in-the-loop policies using its confirmation token.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYesThe confirmation token returned by the gated invoke response.

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses the action as confirmation of a write/delete operation gated by policies, but does not detail side effects, required permissions, or error conditions. Minimal but adequate.

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?

A single concise sentence with no unnecessary words, efficiently conveying the tool's purpose and key requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficient for a simple tool with one parameter and no output schema, but lacks details about the gating mechanism, what happens after confirmation, and potential errors. Could be more complete.

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 coverage is 100% for the single 'token' parameter, and the description adds that it is a confirmation token from a gated response. This does not add significant meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool confirms a pending write or delete operation using a confirmation token. The verb 'confirms' and resource 'pending write or delete operation' are specific and distinguish it from sibling tools that are read-only or informational.

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 usage after receiving a token from a gated invoke response, but does not explicitly state when to use vs alternatives. The context of human-in-the-loop policies provides clear guidance on the workflow step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sparda_infoA

Info about this SPARDA endpoint. SPARDA is the trust layer for AI-written code β€” AI writes, SPARDA proves: deterministic, offline behavior proofs (guards, invariants, irreversible effects) plus a live gate for AI edits, no API key. By Residual Labs (residual-labs.fr) β€” github.com/zyx77550/sparda

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states it provides info but does not disclose behavioral traits like read-only nature, response format, or any limitations beyond the SPARDA description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is concise and purpose-driven. The second and third sentences are promotional about SPARDA, which adds fluff and does not directly assist in tool invocation.

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?

Given zero parameters and no output schema, the description adequately explains the tool's purpose and the SPARDA context, though it lacks details on the output format.

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?

No parameters exist, so baseline is 4. The description adds no parameter details but context about SPARDA, which is acceptable for an info tool with zero params.

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 clearly states 'Info about this SPARDA endpoint', specifying a verb+resource. It distinguishes itself from siblings like get_health and sparda_list_disabled_tools by being the only info endpoint.

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?

The description implies use for obtaining info about SPARDA but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sparda_list_disabled_toolsA

Lists write tools (POST/PUT/DELETE) disabled by SPARDA write-safety, and how to enable them.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It accurately declares it as a read-only listing operation with no side effects, but lacks details on authentication requirements or rate limits. The behavior is clear and consistent.

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 a single sentence with no extra words. It conveys the tool's purpose and scope efficiently, making it easy for an agent to parse quickly.

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?

Given no parameters, no output schema, and no annotations, the description is nearly complete. It tells the agent what to expect (list of disabled tools and enablement info). A slight improvement would be specifying the output format, but it's sufficient for a simple list tool.

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?

There are no parameters, so schema coverage is 100%. The description adds context by explaining the tool returns a list of disabled write tools and enablement instructions, which fully compensates for the lack of 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 clearly states it lists write tools disabled by SPARDA write-safety and how to enable them. It uses specific verbs and resources, and distinguishes from sibling tools like sparda_info or sparda_confirm which have different purposes.

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?

The description implies usage for checking disabled tools but does not explicitly state when to use it versus alternatives, nor provide when-not-to-use guidance. It assumes the agent knows when write-safety is relevant.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching a user, health check, server info, listing disabled tools, and confirming operations. No overlap or ambiguity.

Naming Consistency3/5

Two tools use a generic verb_noun pattern ('get_api_users_by_id', 'get_health'), while three use a 'sparda_' prefix ('sparda_info', 'sparda_list_disabled_tools', 'sparda_confirm'). This inconsistency in prefix usage lowers the overall naming coherence.

Tool Count5/5

Five tools is well-scoped for the server's purpose: providing health, user info, and safety-related operations. Each tool earns its place without being excessive or insufficient.

Completeness4/5

The tool surface covers the core aspects: service info, health, user retrieval, and write-safety management. A minor gap is the lack of a tool to enable disabled tools directly, but the listing tool explains how to enable them, so agents can work around it.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zakariagharzouli/sparda'

If you have feedback or need assistance with the MCP directory API, please join our Discord server