curate-ipsum
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CHROMA_HOST | No | ChromaDB host (empty for in-process) | |
| EMBEDDING_MODEL | No | Embedding model for semantic search | all-MiniLM-L6-v2 |
| MUTATION_TOOL_DATA_DIR | No | Directory for mutation tool data | .mutation_tool_data |
| MUTATION_TOOL_LOG_LEVEL | No | Log level for mutation tool | INFO |
| CURATE_IPSUM_GRAPH_BACKEND | No | Graph backend to use (sqlite or kuzu) | sqlite |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_unit_tests_toolC | Run unit tests for a project and return a summarized result. |
| run_integration_tests_toolC | Run integration tests for a project and return a summarized result. |
| run_mutation_tests_toolA | Run mutation tests and return summarized mutation statistics. Supports multiple frameworks: stryker (JS/TS), mutmut (Python). If tool is not specified, auto-detects based on project structure. |
| get_run_history_toolB | Return recent unit, integration, and mutation runs for a project and optional region. |
| get_region_metrics_toolC | Compute PID-like metrics and mutation score for a specific region within a project. |
| detect_frameworks_toolB | Detect available mutation testing frameworks and project language. Returns detected frameworks with confidence scores and a recommendation for which framework to use. |
| parse_region_toolA | Parse a region identifier string into its components. Regions use a hierarchical format: file:::class:::func:::lines:-. Useful for understanding region hierarchy. |
| check_region_relationship_toolA | Check if one region contains or overlaps another. Useful for aggregating metrics across related regions. A file region contains all functions within it; a function region contains its line ranges. |
| create_region_toolB | Create a region identifier for a specific code location. Use level='file' for whole file, 'function' for a function, 'class' for a class, or 'lines' for a line range. |
| add_assertion_toolB | Add an assertion to the synthesis theory with evidence grounding. Assertions are typed beliefs about code (type, behavior, invariant, contract). Each assertion must be grounded by evidence (test results, mutation results, etc.). |
| contract_assertion_toolA | Contract (remove) an assertion from the theory using AGM contraction. Strategies: 'entrenchment' (removes target and less-entrenched dependents), 'minimal' (target and edges only), 'full_cascade' (target and all descendants). |
| get_entrenchment_toolB | Get the entrenchment score for an assertion. Entrenchment measures belief resilience (0.0-1.0, higher = more entrenched). Highly entrenched beliefs are harder to remove via contraction. |
| list_assertions_toolA | List all assertions in the synthesis theory. Optionally filter by assertion type (type, behavior, invariant, contract) or by region ID. |
| get_theory_snapshot_toolA | Get a snapshot of the current synthesis theory. Returns the world bundle with all nodes, edges, and evidence. |
| revise_theory_toolA | Revise the theory by incorporating a new assertion. If the new assertion contradicts existing beliefs, those are first contracted (via AGM revision / Levi identity) before adding the new belief. |
| store_evidence_toolA | Store a piece of evidence (test result, mutation result, etc.) in the synthesis theory. Evidence is required to ground assertions. |
| get_provenance_toolA | Get the provenance DAG summary for a project's synthesis theory. Shows the history of belief revision operations: expansions, contractions, revisions, and evidence storage events. |
| why_believe_toolB | Trace the evidence chain for an assertion. Returns the list of evidence IDs that ground (support) a given assertion, answering 'why do we believe this?'. |
| belief_stability_toolB | Measure the stability of an assertion. Returns a score from 0.0 (constantly revised) to 1.0 (never touched). Unstable assertions may need stronger evidence or reformulation. |
| rollback_to_toolA | Revert the synthesis theory to a prior world state. Uses content-addressable storage — no data is lost, only the current world pointer changes. |
| undo_last_operations_toolA | Undo the last N belief revision operations. Walks backward through the provenance DAG to find the prior world state, then rolls back to it. |
| analyze_failure_toolA | Analyze why a synthesis attempt failed. Classifies the failure mode (type mismatch, overfitting, underfitting, etc.) and suggests which assertions to contract to fix the issue. |
| list_world_history_toolA | List all historical world states for a project's synthesis theory. Returns world hashes with timestamps and reasons, useful for understanding theory evolution and choosing rollback targets. |
| extract_call_graphA | Extract and analyze the call graph of a Python project. Returns summary statistics: node count, edge count, SCC count, connected components, and top-level function list. |
| compute_partitioningB | Compute Fiedler spectral partitioning of a project's call graph. Recursively bipartitions the graph using the Fiedler vector (2nd eigenvector of the graph Laplacian). Returns a partition tree with node assignments and algebraic connectivity (λ₂) values. |
| query_reachabilityA | Query reachability between two functions in a project's call graph. Uses Kameda O(1) index for planar subgraphs with BFS fallback for non-planar edges. Returns whether the source can reach the target, the method used, and the path if reachable via BFS. |
| get_hierarchyB | Get the hierarchical decomposition of a project's call graph. Alternates between SCC condensation and Fiedler spectral partitioning to produce a tree representing the project's modular structure. |
| find_function_partitionA | Find which partition a function belongs to in the Fiedler partition tree. Returns the partition ID, sibling functions in the same partition, and the entry/exit points of that partition. |
| synthesize_patch_toolA | Start CEGIS synthesis to generate a patch that kills a surviving mutant. The engine uses LLM candidates + genetic algorithm evolution + counterexample feedback to produce a verified patch. Returns a SynthesisResult dict. |
| synthesis_status_toolA | Check the status of a completed synthesis run. Returns iteration count, fitness history, counterexamples resolved, and outcome. |
| cancel_synthesis_toolA | Cancel a running synthesis. Sets a cancellation flag that the CEGIS engine checks between iterations. |
| list_synthesis_runs_toolB | List all synthesis runs for a project. Returns a summary of past runs with outcomes, iterations, and fitness. |
| incremental_update_toolA | Detect file changes and update the persisted call graph incrementally. Compares file hashes to find added/modified/removed files, then updates only the affected graph nodes. Much faster than full re-extraction. |
| persistent_graph_stats_toolB | Get statistics from the persistent graph store for a project. Returns node count, edge count, whether Kameda index and partitions are stored, backend type, and last update timestamp. |
| graph_query_toolB | Execute a structured graph query against the persistent store. Supports query types: 'neighbors' (get adjacent nodes), 'reachability' (check if source reaches target via Kameda O(1) index), and 'node' (get node details). Uses stored graph data without re-extraction. |
| verify_property_toolB | Run formal verification on a binary or constraint set. Supports Z3 (constraint solving), angr (Docker symbolic execution), and mock backends. Returns verification status and any counterexample found. |
| verify_with_orchestrator_toolA | Run the CEGAR verification orchestrator with budget escalation. Chains verification attempts with progressively larger budgets (10s → 30s → 120s). Returns aggregated result with iteration history. |
| list_verification_backends_toolA | List available verification backends and their capabilities. Shows which find/avoid predicates and constraint types each backend supports. |
| rag_index_nodes_toolB | Index code nodes into the RAG vector store for semantic search. Each node should have an ID, text content, and optional metadata. |
| rag_search_toolB | Search the RAG vector store for code relevant to a query. Optionally expands results using the project's call graph. |
| rag_stats_toolC | Get statistics about the RAG vector store. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/egoughnour/curate-ipsum'
If you have feedback or need assistance with the MCP directory API, please join our Discord server