Seshat MCP server

Read from the package source without running it. The installed server may list more.

• conflict_matrix

  Given multiple planned tasks, check which ones can run in parallel safely. Classifies every task pair: Tier 1 (different files, safe), Tier 2 (same file different symbols, careful), Tier 3 (same symbol, must sequence). Returns a matrix and suggested execution order.

• create_symbolwrite action

  Register a planned new symbol in the graph before it exists on disk. This lets simulate_mutation and conflict_matrix reason about code you haven't written yet. Nothing is written to disk.

• diff_bundle

  Compare a worktree against the loaded project to see what changed structurally — not a line diff, but which symbols were added, removed, or had their signatures/dependencies changed. Use this after making changes to verify the structural impact.

• estimate_task_cost

  Before starting a code change, estimate how many tokens it will consume. Computes the blast radius, sums source tokens across all affected symbols, and projects total burn including iteration cycles. Use this to check if a task fits your context budget before committing to it.

• find_by_constraint

  Find every function with a specific syntactic constraint tag — AUTH (requires authentication), DB_ACCESS (touches database), THROWS (explicit throw statement), PURE (no side effects), NETWORK_IO (makes HTTP calls), VALIDATED (has input validation). Also supports table-level queries: pass table="walks" to find every function that reads or writes the walks table (answers "what touches this table?" f

• find_dead_code

  Find functions that nothing calls. Walks the call graph from all entry points (routes, exports, tests) and flags symbols that are unreachable. Use this during cleanup or before a release to find safe deletion candidates.

• find_entry_points

  List the ways into the system: route/controller handlers, test entries, framework plugin registrations, and exported symbols (the public API surface), classified by kind and ranked by reach. Call it first when orienting in an unfamiliar codebase — it answers "where does execution start, and what is the public surface?" Complements list_modules (structure) and find_dead_code (its exact inverse: the

• find_error_gaps

  Find crash risks: functions that throw or have network/DB side effects whose callers don't catch errors. Returns the specific caller→callee pairs where exceptions can propagate unhandled. Use this before shipping to find missing error handling.

• find_exposure_leaks

  Find places where public/API code directly accesses private internals, bypassing the intended abstraction boundary. Use this during API design reviews or before extracting a module.

• find_layer_violations

  Find places where the architecture is broken — a database repository calling a route handler, a utility importing a component. Returns every backward or skip-layer dependency that violates clean architecture.

• find_ownership_violations

  Find memory and lifecycle issues — entities with complex ownership, unsafe blocks, escaping references, or illegal mutability on borrowed data. Returns 0 for most JS/Python codebases — a non-zero result in those languages indicates a serious boundary violation worth investigating. Most detailed results for Rust and C++.

• find_semantic_clones

  Find duplicated logic across the codebase. Normalizes variable names and compares code structure to catch identical algorithms in different files — even across different languages. Use this before a DRY refactor.

• get_account_status

  See your current plan, available tools, and credit balance. Call this if a tool returns a tier error or you want to know what tools are available.

• get_auth_matrix

  Audit authentication coverage. Shows which API routes and controllers require auth and which don't, plus inconsistencies like database access without auth checks. For large codebases, use the module parameter to drill into a specific module/directory. Most useful for backend codebases with middleware-based auth. Frontend frameworks (React, Vue) handle auth via component wrappers, which this tool w

• get_blast_radius

  Before modifying a function, call this to see everything that could break. Returns all transitively affected symbols — both upstream callers and downstream callees — with distance from the change point. Like git log --follow but for runtime impact. Designed for repeated use: as you discover new symbols with other tools, call this again on them to expand your understanding of the affected surface.

• get_co_change_clusters

  The codebase's hidden modules: groups of symbols that historically change together (≥3 shared commits, sweep commits excluded), computed from real commit history. Clusters that span multiple directories reveal coupling the file tree doesn't show. Call it when planning a change or splitting work across agents — touching one member of a cluster usually means touching the rest, even when no static de

• get_coupling_metrics

  Measure how tangled your code is. Returns coupling (cross-boundary dependencies), cohesion (within-group dependencies), and instability scores. High coupling + low cohesion = refactoring candidates. Start with group_by: "layer" for the architectural health view ("are my controllers more coupled than my services?"), then drill into group_by: "module" for specific hotspots.

• get_data_flow

  See what data a function reads, returns, and mutates (DB writes, state changes). Use this when debugging data bugs or when you need to verify whether a function has side effects before refactoring it.

• get_dependencies

  Trace who calls a function and what it calls, up to N levels deep. Use this instead of grep-for-function-name when you need the actual call chain — returns the dependency graph, not text matches. Covers callers (upstream), callees (downstream), or both.

• get_entity

  Get everything about one function or class — its signature, callers, callees, data flow, constraints, source location, and database operations (which tables it reads/writes). Use this when you need to deeply understand a single symbol before modifying it. Returns more than reading the source file because it includes the dependency context.

• get_hotspots

  Project-level change-history orientation: the most-changed entities (and what kind of change dominates each), low-survival thrash spots where changes don't stick, heavily-depended-on entities that haven't changed all window (interface freeze), and directories with no recent changes. Call it after list_modules when orienting in a codebase — it answers "where does development actually happen, and wh

• get_lineage

  The change history of one symbol, typed by what kind of change each commit made (body, calls, data, signature, constraints…), with CI verdicts, reverts, rename tracking, co-change partners, and rejected PRs that touched it. Call before modifying anything load-bearing: it answers "how does this entity usually change, and what happened last time someone tried?" — which no text diff can. Complements

• get_optimal_context

  Before working on a function, call this to get the most relevant related code ranked by importance and fitted to a token budget. Returns a prioritized reading list of symbols you should understand — better than guessing which files to open. Designed for iterative use: call it on your target, read the top results, then call it again on any surprising dependencies to build a complete picture.

• get_test_coverage

  See which production functions are actually exercised by tests via the call graph — semantic coverage, not line coverage. Optionally ranks uncovered functions by blast radius so you know which missing tests are riskiest.

• get_topology

  Get the full API surface map in one call — all routes, middleware, auth patterns, and database tables. Use this when you need to understand the overall architecture without reading every file. Returns the information you'd normally piece together from dozens of file reads.

• list_modules

  Get a bird's-eye view of how the codebase is organized. Groups all symbols by architectural layer (route/service/component), module, file, or language with counts. Use this to orient yourself in an unfamiliar codebase before diving into specifics.

• list_projects

  Start here. Returns all synced codebases with their size, language, and project name. You need the project name for every other tool. If this returns empty, use sync_project to import the current repo.

• query_data_targets

  Find every function that reads from or writes to a specific database table, state object, or data source. Use this when you need to understand all the code paths that touch a particular data store.

• query_entities

  Like grep but for code structure. Find functions, classes, and routes by name, architectural layer (route/service/component), or module. Returns matching symbols with their type, file, and layer — use this instead of grep when you need to find code by what it does, not by text content.

• query_traits

  Find functions by inferred behavioral trait — "fallible" (can fail, including transitively via callees that throw), "asyncContext" (carries async state), "generator" (yields values). Traits are semantic properties inferred from the call graph, not just syntax. Use this when you need to find all code with a specific capability. For syntactic tags (explicit throw statements, DB access), use find_by_

• simulate_mutation

  Simulate a hypothetical code change without writing anything. Five mutation dimensions: constraints/traits (behavioral tags — who upstream breaks), edges (add/remove calls — orphaned callees, inherited error handling and data contracts), data (add/remove table access — which co-tenants of the table must be reviewed), signature (param changes — which call sites break). Use this to plan a change bef

• sync_project

  Import a public GitHub repo into Seshat for structural analysis. Call this when list_projects returns empty or when the user wants to analyze a new repo. Detects the git remote automatically if no URL is provided. Extraction typically takes 5-30 seconds. After syncing, call list_projects to confirm the project is available. Use force: true to re-extract even if a cached snapshot exists (useful aft

• trace_boundaries

  Identify the boundary surface of one or two codebases — entities that face outward (expose an API, accept network input, make network calls). When given two projects, surfaces both boundary sets so you can trace the handshake between a backend and frontend, detect orphaned routes with no consumer, or find frontend calls with no matching backend handler. Works across any language — boundaries are d

• trace_data_path

  Follow data from one function through the call graph to its sinks. From a start entity it walks callees, records the data each hop consumes/produces/mutates, and reports the chain from the start to every sink the data reaches — database writes, network egress, filesystem writes — plus the tables touched. Call it before changing a function that handles real data: it answers "where does this data en

• Code scan2 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitystatic API keys via environment variables6/15
• Maintenancelast push 0 days ago15/15
• Maintainer identitynamespace and repository owner differ; website matches verified namespace6/10

Safety score

80/100

higher than 60% of 48,255 servers

Tools

34

the typical server has 7

Tools that change things

3%

typical: 0%. Fewer write tools means less an agent can break

Downloads a week

2

more than 0% of 12,191 servers with a package

Seshat: common questions

Is Seshat MCP server safe?

Mostly: it is graded B (80/100). Read the Seshat safety report

How do I install Seshat?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Seshat need an API key?

Yes. The registry entry asks for SESHAT_API_KEY.

Is Seshat maintained?

The last commit was 33 days ago (2026-10-02). The latest release is v0.20.2.

How does Seshat compare with other MCP servers?

safety score 80/100 (higher than 60% of 48,255 servers); tools 34 (the typical server has 7); tools that change things 3% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.