What can you do with this server?

Ariadne is a cross-service API dependency graph and semantic code navigation tool for microservice architectures. It exposes four core tools: * query_chains — Search for cross-service API chains using a business term or endpoint name (e.g. "createOrder"). Returns ranked clusters of related GraphQL operations, HTTP endpoints, Kafka topics, and frontend queries across all indexed services. * expand_node — Trace one-hop relationships from a known node (e.g. a Kafka topic, REST endpoint, or GraphQL mutation) to discover directly connected components with similarity scores. * ariadne_help — Retrieve setup and usage guidance, including how to index microservices or troubleshoot empty results. Requires no database access. * log_feedback — Record thumbs-up/thumbs-down feedback on results, stored locally in feedback.db to gradually improve cluster rankings over time. It supports GraphQL, Spring (Java/Kotlin), TypeScript, and cube.js codebases; operates offline via static analysis; and integrates with MCP-compatible tools like Claude Code and Cursor.

Which integrations are available for this server?

Scans GraphQL SDL files to extract Query, Mutation, Subscription, and Type definitions for cross-service API dependency analysis and semantic code navigation. Analyzes Kotlin code with Spring framework annotations to identify HTTP endpoints, Kafka topics, and backend client calls for microservice API dependency analysis. Analyzes Spring framework code to identify HTTP endpoints via @RestController annotations, Kafka topics via @KafkaListener and application.yaml configurations, and backend client calls via RestClient/RestTemplate. Scans TypeScript files to extract frontend GraphQL queries/mutations from gql template literals and REST API calls from axiosRequest/fetch statements for cross-service feature mapping.

de en es ja ko ru zh

ariadne

by whyy9527

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Ariadne

License: MIT MCP ariadne MCP server Awesome MCP Servers

Ariadne's thread — a way out of the microservice maze.

Cross-service API dependency graph for Spring Boot + TypeScript microservice stacks. MCP stdio server for AI coding assistants (Claude Code, Cursor, Windsurf), with a CLI twin. Local SQLite + TF-IDF. Zero ML dependencies.

Ariadne demo — scan Spring PetClinic microservices and ask "owner"

70-second deterministic terminal walkthrough. Reproduce it from docs/demo.tape.

What it does

Indexes the contract layer — GraphQL mutations, REST endpoints, Kafka topics, frontend queries. Nothing else. That's why results fit an AI context window.

Ask Claude "where does createOrder live across the stack?" and query_chains returns:

Top Cluster #1  [confidence: 0.91]
  Services: gateway, orders-svc, billing-svc, web
  - [web]          Frontend Mutation: createOrder
  - [gateway]      GraphQL Mutation:  createOrder
  - [orders-svc]   HTTP POST /orders: createOrder
  - [orders-svc]   Kafka Topic:       order-created
  - [billing-svc]  Kafka Listener:    order-created → chargeCustomer

The response is intentionally bounded for an AI context window. See the reproducible public-stack benchmark for measured retrieval, serialized token, and timing results against rg and grep.

Current public-stack benchmark (48 reviewed queries across Spring REST, GraphQL/TypeScript, Kafka, and FastAPI):

Backend	Top-1	Top-3	MRR	Warm query	Mean output
Ariadne	89.6%	95.8%	0.927	<0.4 ms	375 tokens
`rg`	37.5%	56.2%	0.510	~9 ms	591 tokens
`grep`	37.5%	56.2%	0.510	~9 ms	591 tokens

Full methodology and per-stack results · raw JSON evidence

This corpus is operation-name-heavy and measures deterministic contract lookup compatibility. It is not yet a natural-language relevance benchmark.

Supports: GraphQL · Spring HTTP/Kafka/RestClient · Python FastAPI · TypeScript Apollo/fetch/axios · Cube.js.

Related MCP server: TempoGraph

Try it in 30 seconds (zero config)

pip install ariadne-mcp
ariadne-mcp demo

Clones spring-petclinic-microservices into ~/.cache/ariadne-mcp/demo, scans it, and prints the top cluster for owner — a real cross-service call chain. No config file, no workspace setup.

Did Ariadne find the chain you expected? Share one minute of structured feedback. Ariadne sends no usage data automatically; the form opens only when you choose to submit it.

Install on your own workspace

pip install ariadne-mcp
cp "$(python -c 'import ariadne_mcp, os; print(os.path.join(os.path.dirname(ariadne_mcp.__file__), "ariadne.config.example.json"))')" ariadne.config.json
# edit ariadne.config.json (list the repos you want indexed)
ariadne-mcp install ariadne.config.json ~/your-workspace

Restart Claude Code. install is idempotent — re-run after pulling new code, or let the assistant call rescan on a stale_warning.

After your first real query, you can optionally send closed-ended usage feedback. No source, query, or usage data is transmitted by Ariadne itself.

Config

{ "repos": [
    { "path": "../gateway" },
    { "path": "../orders-svc" },
    { "path": "../web" }
]}

Scanners are inferred from each repo's top-level files (pom.xml / build.gradle / package.json / SDL). See docs/CONFIG.md for the detection table and override syntax.

Reproducible public samples

Each sample pins an upstream commit, scans real service source, runs one query, and verifies manually reviewed node IDs:

Example	Contract path
`spring-petclinic`	Spring REST gateway → service
`one-platform`	GraphQL/TypeScript services
`kafka-microservices`	Kafka producer → consumer
`fastapi-microservices`	Python FastAPI routes

Run one from a source checkout:

python examples/run.py kafka-microservices

Evaluate ranking

Keep a JSONL judgment list for queries that matter to your workspace:

{"hint":"createOrder","expected_node_ids":["gateway::gql::m::createOrder"],"k":3}
{"hint":"owner","expected_node_ids":["customers::http::GET /owners/{ownerId}"],"match":"any","k":5}

Run it against a built DB:

ariadne-mcp --db .ariadne/ariadne.db eval eval/queries.jsonl --top 3 --min-hit-rate 0.8

The command evaluates top-k hit rate and MRR using a stable internal candidate depth, and exits non-zero when a configured threshold fails. Add --feedback-db .ariadne/feedback.db to include local feedback reranking in the eval.

Architecture, MCP tools, scoring math, feedback boost → docs/ARCHITECTURE.md. Custom scanners (Go, Rust, anything) → docs/CUSTOM_SCANNERS.md. Maintainer adoption snapshots → docs/ADOPTION_METRICS.md.

Business acceptance and ablation

The source-backed business suite covers all nine built-in scanners and the complete MCP query/expand/rate/rescan lifecycle, including a real stdio client. It uses synthetic contracts; private workspace sources and feedback stay local.

python -m pip install -e '.[benchmark]' pytest
python -m pytest tests/ -q
python benchmarks/ablation.py --output benchmarks/.work/ablation.json

See quality experiment results for the fixed-input baseline, component ablations, output costs and remaining limitations. The current server uses MCP Python SDK v1 (mcp<2).

Available Tools

5 tools

expand_nodeA

One-hop neighbours of a known node (endpoint / Kafka topic / GraphQL operation / frontend call), with similarity scores and file paths. Read-only; no writes except a local exploration row if called within 10 min of a matching query_chains. Returns up to 3 matched source nodes × up to 10 neighbours (edges with score ≥ 0.08), plus a stale_warning field — call rescan if non-null.

Use AFTER query_chains when you already have a concrete node name and want to trace one hop further. Use query_chains (not this) when starting from a business term or when you don't yet know a node name. Partial, case-insensitive match against node id and raw_name; ambiguous inputs return multiple source groups.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; short strings (e.g. 'get') will match many nodes and only the first 3 are expanded.

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares read-only status, discloses the one exception (a local exploration row if called within 10 min of a matching query_chains), documents result caps (3 source nodes × 10 neighbours, score ≥ 0.08), and surfaces the stale_warning field with a remediation step (call rescan). That is unusually complete behavioral disclosure.

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

Conciseness4/5

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

Two dense, front-loaded paragraphs where the core purpose and the routing guidance come first; nearly every clause carries information (caps, threshold, stale handling). Slightly verbose but nothing is wasted.

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?

Although there is no output schema, the description explains the return shape (source groups × neighbours with scores), the cap, and the stale_warning field. An agent has everything needed to call it correctly and interpret the result.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the ambiguous-match behavior ('ambiguous inputs return multiple source groups') and reinforcing the substring semantics. It complements rather than repeats 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?

States a specific verb+resource ('One-hop neighbours of a known node'), enumerates the node types it operates on, and describes what comes back (similarity scores, file paths). It is immediately distinguishable from query_chains without opening any schema.

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

Usage Guidelines5/5

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

Explicitly states when to use it ('AFTER query_chains when you already have a concrete node name') and names the alternative with the condition that selects it ('Use query_chains (not this) when starting from a business term or when you don't yet know a node name'). Both the when and the when-not are covered.

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

query_chainsA

Query cross-service chains by business term or endpoint name. Returns candidate clusters of related GraphQL operations, HTTP endpoints, Kafka topics, and frontend queries across all services indexed by the local Ariadne DB. Use this when you need to understand which APIs, topics, or frontend operations are involved in a business feature.

ParametersJSON Schema

Name	Required	Description	Default
`hint`	Yes	Business term or endpoint name (e.g. 'createOrder', 'userProfile', 'subscription')
`top_n`	No	Number of clusters to return (default 3)

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (queries and returns clusters) and the scope ('across all services indexed by the local Ariadne DB'), but lacks details on permissions, rate limits, error handling, or response format. For a query tool with no annotations, this is adequate but has gaps in behavioral context.

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 appropriately sized and front-loaded, with two sentences that efficiently convey purpose and usage guidelines without unnecessary details. Every sentence adds value, making it concise and well-structured for quick understanding.

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?

Given the tool's complexity (querying cross-service chains) and lack of annotations and output schema, the description is moderately complete. It covers purpose and usage well but misses behavioral details like response format, pagination, or error cases. For a tool with no output schema, more information on return values would improve completeness.

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 description coverage is 100%, with both parameters well-documented in the schema. The description adds minimal value beyond the schema by mentioning 'business term or endpoint name' for 'hint' and implying clustering for results, but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema handles most parameter documentation.

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's purpose with specific verbs ('query', 'returns') and resources ('cross-service chains', 'candidate clusters of related GraphQL operations, HTTP endpoints, Kafka topics, and frontend queries'). It distinguishes this tool from siblings by specifying it queries by 'business term or endpoint name' and returns clusters across services, unlike expand_node, rate_result, rescan, or show_help.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: 'Use this when you need to understand which APIs, topics, or frontend operations are involved in a business feature.' This provides clear context for usage versus alternatives, though it doesn't name specific sibling tools, the guidance is sufficient for distinguishing use cases.

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

rate_resultA

Record whether Ariadne results were useful. Call this after using query_chains or expand_node to log feedback for future improvement. If node_ids is omitted after a recent query_chains call, Ariadne infers node_ids from hint + cluster_rank. Feedback is stored locally in feedback.db and survives DB rebuilds.

ParametersJSON Schema

Name	Required	Description
`hint`	Yes	The hint used in query_chains or the node name used in expand_node
`accepted`	Yes	true if results helped locate files or understand the chain; false if irrelevant or misleading
`node_ids`	No	Node IDs from the result that were actually useful
`cluster_rank`	No	Which cluster was referenced (1-based). Use 0 for expand_node results.

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It reveals that feedback is stored locally in feedback.db and survives DB rebuilds, and explains inference behavior. No side effects or permission needs are mentioned, but overall transparent enough.

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 concise, front-loaded with purpose and usage, then provides details about inference and storage. Every sentence adds value without redundancy.

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 low complexity and no output schema, the description is complete enough. It explains behavior, parameters, and storage. Minor gap: no return value description, but not critical for a feedback 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?

Schema coverage is 100%, but the description adds meaning: explains that node_ids can be inferred from hint and cluster_rank if omitted, and clarifies cluster_rank usage (0 for expand_node). This adds value 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 clearly states the tool's purpose ('Record whether Ariadne results were useful') and distinguishes it from siblings by specifying it is used after query_chains or expand_node.

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

Usage Guidelines5/5

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

The description explicitly says when to call this tool ('after using query_chains or expand_node') and explains inference behavior when node_ids is omitted, providing clear usage context.

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

rescanA

Refresh the Ariadne index from inside the conversation. Call this when query_chains or expand_node returned a stale_warning, or after you know the user's code has changed. Re-scans every repo listed in the install-time ariadne.config.json, rebuilds TF-IDF token edges, and invalidates cached DB handles so the next query sees fresh data. No arguments; zero configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: re-scans repos from a config file, rebuilds TF-IDF edges, and invalidates caches. It mentions 'No arguments; zero configuration' which clarifies operational simplicity. However, it doesn't cover potential side effects like performance impact or error handling.

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 appropriately sized and front-loaded, starting with the primary use case and then detailing the actions. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.

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 complexity (index refresh with multiple actions) and no annotations or output schema, the description is mostly complete. It covers purpose, usage, and behavior well, but lacks details on output (e.g., success confirmation or error messages) and potential limitations like execution time or prerequisites.

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?

The input schema has 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explicitly stating 'No arguments; zero configuration,' which reinforces the parameterless nature beyond what the schema indicates, helping the agent understand there are no optional or hidden 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's purpose with specific verbs ('Refresh', 'Re-scans', 'rebuilds', 'invalidates') and resources ('Ariadne index', 'TF-IDF token edges', 'cached DB handles'). It distinguishes from siblings by explaining when to use it versus query_chains or expand_node, which return stale_warnings.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool: 'Call this when query_chains or expand_node returned a stale_warning, or after you know the user's code has changed.' It provides clear alternatives by naming specific sibling tools and scenarios for usage.

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

show_helpA

Return a quick setup and usage guide for Ariadne. Call this first when you are unsure how to use Ariadne, how to index your own microservices, or why query_chains returned no results. Always safe to call — no DB required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's safe (no destructive effects), requires no database, and returns guidance. However, it doesn't specify format, length, or potential rate limits, leaving some gaps in behavioral context.

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 front-loaded with the core purpose, followed by usage guidelines and safety note. Every sentence earns its place by providing essential information without waste, making it highly efficient and well-structured.

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 (0 parameters, no annotations, no output schema), the description is nearly complete. It covers purpose, usage, and safety. However, without an output schema, it could briefly mention the type of guidance returned (e.g., text or structured data), leaving a minor gap.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by implying no inputs are required, aligning with the schema. Baseline is 4 for 0 parameters, as it appropriately handles 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 the tool's purpose with specific verbs ('Return a quick setup and usage guide') and resource ('for Ariadne'). It distinguishes from siblings by focusing on help/guidance rather than operations like querying, expanding, rating, or rescanning.

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

Usage Guidelines5/5

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

It provides explicit guidance on when to use this tool ('Call this first when you are unsure how to use Ariadne, how to index your own microservices, or why query_chains returned no results') and when it's safe ('Always safe to call — no DB required'), effectively differentiating it from alternatives like query_chains for troubleshooting.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.7Apr 16, 2026

Removedariadne_help

Changedexpand_node2 fields changed

changedInput schema / properties / name / description

Previous value: -"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; very short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."New value: +"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."

addedInput schema / properties / name / minLength
```
Added value: +2
```

Removedlog_feedback
Addedrate_result
Addedshow_help

1 tool updatev1.0.6Apr 15, 2026

Changedexpand_node1 field changed

changedInput schema / properties / name / description

Previous value: -"Endpoint method name, Kafka topic name, or GraphQL operation name (partial match supported)"New value: +"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; very short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."

1 tool updatev1.0.5Apr 15, 2026
- Addedrescan
2 tool updatesv1.0.3Apr 15, 2026
- Addedexpand_node
- Addedquery_chains
2 tool updatesv1.0.2Apr 15, 2026
- Addedariadne_help
- Addedlog_feedback
3 tool updatesv1.0.1Apr 15, 2026
- Removedexpand_node
- Removedlog_feedback
- Removedquery_chains
3 tool updatesv1.0.0Apr 15, 2026
- First observedexpand_node
- First observedlog_feedback
- First observedquery_chains

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored 2026-10-15 03:55 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: query_chains for discovery from a business term, expand_node for one-hop traversal from a known node, rescan for index refresh, rate_result for feedback, and show_help for guidance. The descriptions explicitly disambiguate the closest pair (query_chains vs expand_node) by stating when to use each. No two tools overlap in function.

Naming Consistency4/5

Four of five names follow a clear verb_noun pattern (expand_node, query_chains, rate_result, show_help). The lone 'rescan' is a bare verb without a noun object, a minor deviation that stays readable and consistent in style. Overall predictable and snake_case throughout.

Tool Count5/5

Five tools is well-scoped for a code-relationship exploration server, covering discovery, traversal, maintenance, feedback, and help. Each tool earns its place with no redundant or filler entries. The surface is focused rather than bloated.

Completeness4/5

The lifecycle is well covered: discovery (query_chains), traversal (expand_node), freshness (rescan), and feedback (rate_result) plus onboarding help. Minor gaps exist — e.g. no way to list indexed repos or enumerating all nodes — but core workflows are supported. A read-only exploration domain reasonably needs no create/update/delete operations.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

traced-multi-llm-proxy
ai.getvda
Traced Multi-LLM Proxy
AI & Machine Learning Observability
1
traced-llm-proxy
ai.getvda
Traced LLM Proxy
AI & Machine Learning Observability
1
llm-orchestration-agent-opentelemetry-api
ai.getvda
LLM Orchestration Agent (Opentelemetry Api)
Agent Orchestration Observability
1
llm-observability-orchestration-agent-langchain
ai.getvda
LLM Observability & Orchestration Agent (Langchain)
Observability Monitoring
1

Related MCP Servers

FileScopeMCP
Code Analysis Developer Tools Documentation Access
admica
F
license
A
quality
D
maintenance
A TypeScript tool that ranks files in your codebase by importance, tracks dependencies, and provides file summaries to help understand code structure through Cursor's Model Context Protocol.
Updated 5 months ago (2026-05-10 23:41 UTC)
14
302
-
TempoGraph
Autonomous Agents Code Analysis Developer Tools
Elmoaid
A
license
A
quality
C
maintenance
Code graph context engine that parses codebases with tree-sitter (170+ languages), builds structural dependency graphs, and provides 24 MCP tools for code intelligence. One prepare_context call gives your AI agent the right files for any task. Includes focus, blast radius, hotspots, dead code detection, and hybrid search.
Updated 5 months ago (2026-05-08 01:27 UTC)
24
1
AGPL 3.0
ontomics
Code Analysis Developer Tools Knowledge & Memory
EtienneChollet
A
license
A
quality
C
maintenance
Extract domain knowledge from codebases to reduce LLM token consumption by 20x and time in agentic search by 10x — gathers and makes concepts, naming conventions, and vocabulary queryable via MCP.
Updated 6 months ago (2026-04-17 01:21 UTC)
19
43
MIT
polycodegraph
Code Analysis Developer Tools
smochan
A
license
Not graded
quality
C
maintenance
Multi-language code-graph MCP server with 18 tools for structural code queries — find_symbol, callers, callees, blast_radius, dead_code, and cross-stack dataflow_trace from HTTP request through service layers to SQL. Tree-sitter parsing for Python, TypeScript, JavaScript, and Go; local-first, no API key required.
Updated 2 months ago (2026-08-24 05:21 UTC)
19
MIT