lachesis-mcp
OfficialServer 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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| load_graphA | Switch/attach the active graph the whole server reasons over — point it at a different target (e.g. bnxt -> igb) mid-session with no restart. Takes a canonical graph JSON path and an optional overlay + profile; the graph loads once and every subsequent tool hits the in-memory copy. |
| build_graphA | Build a Lachesis graph from a source directory and attach it — the zero-config way to start on a repo that has no graph yet, no separate lachesis build step needed. Content-addressed: an unchanged tree returns instantly from cache; pass refresh=true to force a rebuild. On success the new graph is loaded, so the next tool call reasons over it. Toolchain: Python needs nothing extra; TypeScript/JavaScript need |
| hubsA | The subsystem's spine: the N highest-degree functions over the UNION call graph (direct CALLS + indirect function-pointer / ops-struct / runtime dispatch), ranked by fan_in + fan_out — no name knowledge needed. Each row carries node_id + handle (file:line), fan_in/fan_out/degree, and entry-point flags (exported | dispatch_target | callback). Language-agnostic cold-start: start here to find what a subsystem is built around, THEN callers/callees/read_body to traverse. |
| communitiesA | The codebase's SUBSYSTEMS: partitions the call graph into clusters that call each other more than the rest of the tree (label propagation), independent of the directory layout — the structure the code HAS, not how it was filed. Each community carries a label (its highest-degree member), size, cohesion, the files it spans, and its top members with node_id + handle. Reports the graph modularity and lifts out cross-cutting connector hubs. Partitions over precise compiler calls by default; set include_dispatch for C function-pointer trees. Use AFTER hubs to go from 'what is central' to 'what are the parts'. |
| searchA | Resolve a function/method/type/file name to its canonical node id(s) with file:line. Teleport to any symbol, fuzzy by default. Returns a real match total with paging (limit/offset), and de-prioritizes test/spec symbols. NOTE: on a cold graph prefer |
| callersA | Who calls this symbol — direct + indirect dispatch (function-pointer / ops-struct / runtime), external stubs filtered. Each row tagged via: direct | indirect(may_invoke|context|fn-pointer). Set direct_only to get only resolved decl->decl CALLS. A jump move. |
| calleesA | What this symbol calls — direct + indirect dispatch, in-repo only. Each row tagged via: direct | indirect(...); an indirect row with resolved:false is an unresolved function-pointer slot (the indirection is real, the target isn't pinned). Set direct_only for resolved decl->decl CALLS only. A jump move. |
| read_bodyA | Read a function/method's real source (L3) — the 'open this and read it' move, so an agent never falls back to cat. Accepts a name or a node_id; returns the exact source span from byte offsets plus {node_id, name, file, start_line, end_line}, capped at max_chars (default 4000) with a truncated flag. If the file/offsets are unavailable it reconstructs a best-effort body from the function's L3 body nodes in line order. |
| open_fileA | L1 file graph: imports, declarations, intra-file calls, cross-file jump-stubs for one file (repo-relative path). Returns a {nodes,edges,manifest} graph. |
| open_folderA | Read-only. L0 folder graph rooted at a path prefix: folder -> file -> declarations. The coarsest orientation move — use it to see what lives under a directory before drilling in with |
| unknownsA | Read-only. List the graph's explicit comprehension frontiers: unresolved calls, dynamic/reflective runtime behavior, and parser/compiler diagnostics. It separates proven-absent from couldn't-cross, so you never read a missing fact as 'none'. Call it to gauge how much of an answer is trustworthy; scope to one |
| coverage_mapA | Read-only. Report deterministic graph coverage by component: how many files and callable bodies are indexed, plus diagnostics and unmodeled frontiers. It measures what the graph contains, not per-client session activity — use it to decide whether an empty result means 'clean' or 'not analyzed'. All params optional. |
| field_historyA | For a field/property, list graph-evidenced initialization, modification, reads, checks, and value-flow events with owning functions. |
| sibling_compareA | Compare structurally similar callables by callees and control structure. Returns differences as facts only; it does not rank anomalies or issue verdicts. |
| type_explainA | Read-only. Explain a type from graph facts: its fields plus the methods that construct, mutate, consume, or destroy it, each role graph-derived. Use it to learn a struct/class's shape and how it is handled before reading call sites. Paginate fields with offset and methods with member_offset. |
| component_boundaryA | Read-only. Show every call, callback, and type reference crossing between two path components, in both directions, with confidence and file:line. Use it to audit the contract between two modules/dirs; |
| indirect_targetsA | Resolve function-pointer, callback, ops-table, and runtime dispatch sites inside a function. Keeps unresolved sites visible and reports confidence. |
| architecture_mapA | Read-only. Map the codebase's architecture: deterministic file communities over the call + dependency graph, each with internal/boundary edge counts and its call-graph hubs (labels are graph-derived member names, never generated prose). A directory-independent 'what are the big pieces' view — use |
| execution_storyA | Read-only. Bounded forward call-and-branch trace from an entry point, following resolved indirect dispatch — the ordered structure of what runs, not generated narrative prose. Use it to see the control skeleton reachable from an entry; bound cost with max_depth/max_steps and page the branches/frontier. For pure centrality use |
| change_contextA | Read-only. Join a symbol to its Git history: the exact commits that touched it with author, date, and subject. Returns history facts only — no generated 'why' narrative. Use it to date a change or find who last touched a function; newest first, paged with limit/offset. |
| tests_forA | Find exact references to a symbol in test/spec files, including nearby assertion evidence. Reads the recorded source tree because tests are normally excluded from the production graph. |
| spec_linksA | Read-only. Link a symbol to its documentation and source comments, preserving any standards URLs (RFCs, CVEs) and exact file:line evidence. Use it to recover the spec/standard a function implements; returns comment/doc references paged with limit/offset. Reads recorded source, so it works even where comments are outside the production graph. |
| concept_searchA | Search code by behavior rather than spelling using an optional local embedding model. Search is offline-only and never downloads implicitly; install the concept-search extra and run |
| context_packA | Return a minimal coherent factual set for a code question: relevant symbols, call relationships, conditions, tests, specs, and explicit unknowns. Uses identifier/graph relevance until concept_search embeddings are configured. |
| scanA | Return ranked leads from the whole taxonomy by default (lens=all): questions to investigate, never verdicts. Use lens=guard-diff for the entrypoint-to-effect guard view or lens=flow for native object-lifetime leads. Results are bounded and paged; the response includes coverage and whether the requested temporal work completed. Calls against one session are serialized; the native runtime is selected internally. |
| wrapper_modelA | Infer wrapper semantics from graph evidence: allocator, deallocator, I/O, validator, and forwarding call roles. This is evidence with confidence, not a registry mutation. |
| guard_dominanceA | Check whether recognized guards on an entry-to-effect call path dominate the effect. Returns proven, skippable, or undecided evidence and never emits a safety verdict. |
| counterexampleA | Find a bounded call path from src to sink that avoids a named validator/guard. This is the inverse reachability move; absence of a path is not proof when the search is truncated. |
| invariant_traceA | Read-only. Trace the producers, mutators, checkers, and consumers of a value or field over a bounded local flow cone — who sets it, who guards it, who reads it. Use it to reconstruct an invariant around one value; returns role-tagged nodes with file:line, bounded by |
| representation_roundtripA | Read-only. Compare two functions/paths side by side for graph-visible calls, control structure, conversions, and side-effect differences — e.g. an encode/decode or serialize/parse pair. Returns the differences as facts only, inferring no semantic verdict. Use |
| cross_boundary_pathsA | List crossings between two components with boundary tags and rarity ranking, preserving direction and confidence. |
| range_analysisA | Read-only. Return the lightweight numeric evidence graph guards expose for a value (comparisons, bounds checks) — not a full interval solve: real value-range analysis stays unavailable until the numeric model ships, and the response names that frontier honestly. Scope with |
| object_lifecycleA | Read-only. Report what lifecycle evidence the graph holds for a value or function — Pass 3 alloc/release/deref/alias/generation events and its source-rooted coverage — plus the matcher leads that relate them. Give |
| error_path_summaryA | Read-only. For one function, report its exit paths (returns / error branches) and the resource-handling evidence on them, plus the honest frontier: complete transfer summaries remain a separate frontier from the lifecycle graph. Use it to see how a function leaves on its error paths; pair with |
| flowA | Read-only. Forward value-flow cone from a value/symbol: everything it can reach over VALUE_FLOWS_TO + POINTS_TO, bridging aliases through the heap. Use it to answer 'where does this value go?'; for the reverse (what feeds a sink) use |
| reachesA | Read-only. Does src reach sink through value flow? Returns the labeled witness path when it does, or an honest negative when it doesn't (a negative under truncation is not proof of no path). Use it to confirm one specific source->sink pair; use |
| sources_ofA | Read-only reverse value-flow cone for a sink. Use this after a candidate or sink is selected to find values that may feed it; it returns labeled nodes and edges plus explicit truncation/frontier metadata. A missing path is not proof that no flow exists. |
| points_toA | Read-only. Return the heap objects a value may point to through POINTS_TO edges — the alias set behind a pointer. Use it for pointer/alias follow-up, not for callers ( |
| aliasesA | Read-only. Return the values that alias this one — those sharing a heap object through POINTS_TO (the destructuring / alias set). Use it to find every name for the same object before reasoning about a mutation; complements |
| candidatesA | Enumerate and rank every observable obligation site as leads. This is a pointer, not a safety check: leads are never suppressed because a size is constant, a guard seems nearby, or no input flow was witnessed. The result is bounded and paged with |
| candidate_detailC | Return the complete neutral evidence capsule for one candidate id. It contains observations and bounded inferences, but no safe/unsafe verdict. |
| candidate_censusA | Report constructor metadata, exhaustive counts, and explicit analysis frontiers. Use this to distinguish an empty result from missing coverage. |
| explainA | One shot from a candidate (by id, or by the sink's file:line) to a judgeable picture: the obligation and where it lands, the guard the enclosing function does or does not place over it, the bounded reverse value-flow cone into the sink, and the enclosing function's source read inline -- the census->candidates->detail->sources_of->read_body chain composed into one result. Provenance and guard are evidence, not verdicts: an empty cone is 'nothing observed under this tier', not 'unreachable'. Pass candidate_id, or file and line. |
| skeletonA | Render a function's sink map as a pseudo-function: every catalogued sink (all families -- memory, os, file, ...) shown in place, each annotated with its size expression, destination-capacity status, and guard dominance (fall-through | guarded-region | none-observed), plus the branch/loop structure that scopes them, with everything else elided. A sink is not adjudicable alone -- the guard that dominates it decides it -- so co-locating each sink with its controlling branches and loops makes closure a local read. Every obligation on a line is shown, highest-rank first; operand provenance is a drill-down (candidate_detail / sources_of). Pass |
| enrichB | Warm this graph's sidecars once (the 2nd pass), so later flow_pass / leads / candidates / explain answer fast instead of paying the cost cold. Folds the dataflow tier over the whole graph and binds the catalog, and persists both beside the store (.dataflow.pb / .bind.pb) -- the difference between a >120s cold census and an instant one. Idempotent: a store already enriched is a no-op that just reports what is on disk. An unevaluated temporal family is reported as 'not evaluated', never 'clean'. No arguments. |
| flow_passA | Run the interprocedural flow pass (the 3rd pass) over the whole graph and return its per-function SUMMARY census -- the layer beneath the skeletons. For each function: its taxonomy, whether it is a taint source, the ordered sink-flow signatures (which value reaches which sink, guarded or not, and the callee it flows through), and the pointer lifetime signatures (alloc->use->free->escape). This is the composed, interprocedural summary the shape matcher runs on -- one call materializes and caches the pass. The response returns counts and a bounded lead page, never the whole semantic graph. Use |
| leadsA | Query the flow pass's LEADS in memory -- the shape-matcher findings the 3rd pass already computed and cached, not a fresh cold run. This is the warm counterpart to re-deriving leads by hand every question: the pass is materialized once (via |
| flow_skeletonA | Interprocedural flow skeletons: compose per-function summaries into linear, nesting-aware {control|sink|lifecycle} streams STITCHED across call seams -- the cross-function flow a single-function |
| taintA | Taint witnesses from the Atropos catalog: where untrusted input actually reaches a dangerous sink through value flow. Folds the Atropos taint models (sources / sinks / summaries) onto this graph's exact nodes and runs propagation, returning each source->sink reach with the catalog model id, CWE, and file:line for both ends. |
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/UnboundCompute/lachesis'
If you have feedback or need assistance with the MCP directory API, please join our Discord server