SPARDA
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_healthA | Health check — returns service status and uptime |
| get_api_prospects | List today's prospects added to the CRM |
| get_api_users_by_idA | Get a single user by id |
| 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 |
| sparda_list_disabled_toolsA | Lists write tools (POST/PUT/DELETE) disabled by SPARDA write-safety, and how to enable them. |
| sparda_get_context | Call this FIRST. Returns the full living context of this app: every tool with its description, known workflows, runtime telemetry (per-tool calls/errors/latency), quarantined tools, and the immune memory of past diagnosed failures. Lets any AI session resume exactly where the previous one stopped. |
| sparda_prove | Prove this app is safe to deploy — NOW, before you commit. Compiles the current source to its behavior graph and discharges the static proof obligations (unguarded mutation, non-atomic aggregate write, unvalidated constrained write). If a baseline was saved ( |
| sparda_confirmA | Confirms a pending write or delete operation gated by human-in-the-loop policies using its confirmation token. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| prove-my-edit | Prove an edit didn't break a guard before you commit — the check an LLM can't do to itself by re-reading its own code. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: fetching a user, health check, server info, listing disabled tools, and confirming operations. No overlap or ambiguity.
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.
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.
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.