Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ravenroot Second Brain MCP what are the god nodes in my second brain?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Run the Ravenroot knowledge graph as a local Model Context Protocol server. The repository contains a read-only graph snapshot generated from ravenroot-ai/ravenroot, the FastMCP server, and the code that rebuilds the graph. It does not require Google Cloud, Horizon, Qwen, or access to the source repository to answer queries.
Install uv and clone this repository. On macOS or Linux:
git clone https://github.com/ravenroot-ai/ravenroot-second-brain.git
cd ravenroot-second-brain
./start-mcp.shOn Windows, run ./start-mcp.ps1 from PowerShell after cloning. Both scripts perform the same verification and start the stdio server.
Use the absolute path to start-mcp.sh as the command for an MCP client that launches local stdio servers. The first start installs the pinned Python dependencies, rebuilds second_brain/composed/graph.json, verifies its SHA-256 against second_brain/provenance.json, and starts the server. Subsequent starts reuse the verified graph. Python 3.12 or 3.13 is selected by uv.
For a client on the same machine that requires an HTTP URL, run:
MCP_TRANSPORT=http MCP_HOST=127.0.0.1 MCP_PORT=8765 ./start-mcp.shThe endpoint is http://127.0.0.1:8765/mcp. It has no authentication; keep it bound to loopback unless you add access controls yourself. This repository does not host a shared public endpoint. Each clone runs its own server.
Related MCP server: intelligraph-mini
second_brain/parts/graph_partN.json is the committed distribution format. GitHub blocks ordinary Git files above 100 MiB, so the single rebuilt graph is ignored. second_brain/graph_parts.py compose joins the parts in order and refuses a result whose SHA-256 differs from the split header. second_brain/verify_bundle.py also checks the published provenance. The graph and provenance identify the indexed Ravenroot source commit; they are an immutable snapshot until this repository publishes a new one.
The private graph generation workflow and canonical source graph stay outside this repository. Maintainers publish a newly accepted snapshot by updating only the parts and provenance together, then running the tests from a clean checkout before pushing. Never commit second_brain/graph.json, provider settings, credentials, local caches, or agent configuration.
The read-only server provides graphify_query, graphify_path, graphify_explain, graphify_neighbors, graphify_stats, and graphify_god_nodes, plus graphify://stats and graphify://provenance resources.
uv sync --frozen --dev
uv run pytest -q second_brainThe code and bundled data are distributed under Apache License 2.0.
Get all nodes in a community by community ID.
| Name | Required | Description | Default |
|---|---|---|---|
| community_id | Yes | Community ID (0-indexed by size) | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. | |
| token_budget | No | Max output tokens |
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 implies a read operation but does not mention side effects, permissions, output truncation, or what happens with the token_budget parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is minimally sufficient but leaves gaps. It does not explain what a 'community' represents, how the output is structured, or how token_budget affects the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (community_id, project_path, token_budget) are documented in the schema itself. The description only references community_id and adds no meaningful semantics beyond the schema, which is the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('all nodes in a community') plus the required key ('by community ID'). It is clear and actionable, but it does not differentiate this tool from siblings like get_neighbors or query_graph that might also return graph nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all direct neighbors of a node with edge details.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. | |
| token_budget | No | Max output tokens | |
| relation_filter | No | Optional: filter by relation type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and largely fails: it does not state that the operation is read-only, whether traversal is directed or undirected, how token_budget truncation affects results, or whether neighbors are paginated. Only the vague phrase 'with edge details' hints at the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler, which is appropriately sized for a tool whose parameters are mostly self-describing. It is arguably over-terse, but nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a graph-traversal tool with no annotations and no output schema, the definition omits essentials: traversal direction, output shape beyond 'edge details', and how token_budget bounds the result. An agent could call it, but not confidently predict or handle the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so most parameters (project_path, token_budget, relation_filter) are already documented in the schema, establishing a baseline of 3. The description adds nothing about how label matching works or what values relation_filter accepts, so it does not exceed that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource (get all direct neighbors of a node) plus a scope qualifier (with edge details), so an agent can immediately tell what the tool returns. It does not, however, differentiate itself from siblings like get_node or query_graph, which could plausibly also surface adjacency information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to reach for get_neighbors versus query_graph, get_node, or shortest_path, and no mention of prerequisites or typical contexts. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific node by label or ID.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Node label or ID to look up | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., read-only nature, potential errors, or data freshness). Merely states 'get full details' without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words, though could be slightly more informative without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with two parameters and no output schema; description omits what 'full details' includes, and no return value is specified, leaving some ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds minimal value beyond the schema's parameter descriptions (e.g., 'by label or ID' is already in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves full details for a specific node by label or ID, a specific verb-resource pair that distinguishes it from sibling tools focused on communities, stats, or paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_community or get_neighbors, nor any exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed graph impact for a specific PR: which files it changes, which knowledge-graph communities are affected, and how many nodes are touched. Use this to assess merge risk or check for overlap with your current work.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | GitHub repo (owner/repo). Defaults to current repo. | |
| pr_number | Yes | PR number to analyse | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool's function but does not disclose side effects, rate limits, or whether it is read-only. More behavioral context needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information. No wasted words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, description covers main output aspects (files, communities, nodes). Could benefit from more detail on return format, but sufficient for core purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add extra meaning to parameters beyond what schema already provides. No additional detail on defaults or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed graph impact for a specific PR, listing what it provides (files changed, communities affected, nodes touched). It distinguishes from siblings by focusing on PR impact rather than general graph queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to assess merge risk or check for overlap with your current work,' giving clear context. Does not explicitly mention when not to use, but siblings provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most connected nodes - the core abstractions of the knowledge graph.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | ||
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states the return type. It does not explain how 'most connected' is determined, sorting order, or any side effects. For a read operation, minimal behavioral info is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with 12 words, efficiently conveying the core purpose. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It omits details on connectivity metric, error cases, and proper use of parameters, leaving the agent insufficiently informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'project_path' has a description). The tool description does not help explain 'top_n' beyond its default value, failing to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'most connected nodes', with context as 'core abstractions of the knowledge graph'. It distinguishes this tool from sibling tools like 'get_node' or 'get_neighbors' by focusing on connectivity abstraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_community' or 'graph_stats'. The description implies usage but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return summary statistics: node count, edge count, communities, confidence breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states it returns read-only summary statistics, but lacks details on performance (e.g., costly for large graphs), side effects, or prerequisites (e.g., graph must be loaded). This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the verb 'return'. Every word adds value, no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lists four return fields but omits details like data format, ordering, or whether the confidence breakdown is per community or overall. It is minimally complete but could be richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'project_path' is well-described in the schema. The tool description adds no additional semantic meaning beyond the schema, but since the schema already covers it, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses verb 'return' and lists specific items (node count, edge count, communities, confidence breakdown), clearly distinguishing it from siblings like 'get_community' (returns a specific community) or 'shortest_path' (pathfinding). It precisely states the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., 'get_community' for a specific community). It is implied that for summary statistics one uses this tool, but explicit when-to-use or when-not-to-use is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open GitHub PRs with CI status, review state, and graph impact (which communities each PR touches, blast radius). Use this before starting work to check if a PR already covers the area you're about to change.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base branch to filter PRs by (auto-detected if omitted) | |
| repo | No | GitHub repo (owner/repo). Defaults to current repo. | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions the data returned (CI status, review state, graph impact) but does not state that it is a read-only operation or disclose any side effects, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence clearly states purpose and outputs; second sentence gives usage context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, description provides a reasonable overview. However, it lacks explanation of the output structure for 'graph impact' and does not specify pagination or filtering beyond parameters. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds minimal value beyond schema descriptions; it does not provide additional parameter details like default behavior for omitted parameters or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool lists open GitHub PRs with CI status, review state, and graph impact. Action verb 'List' and specific resource 'open GitHub PRs' along with key data points, distinguishing it from siblings like get_pr_impact and triage_prs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this before starting work to check if a PR already covers the area you're about to change.' Does not explicitly mention when not to use or list alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the knowledge graph using BFS or DFS. Returns relevant nodes and edges as text context.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | bfs=broad context, dfs=trace a specific path | bfs |
| depth | No | Traversal depth (1-6) | |
| question | Yes | Natural language question or keyword search | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. | |
| token_budget | No | Max output tokens | |
| context_filter | No | Optional explicit edge-context filter, e.g. ['call', 'field'] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It states the tool returns 'relevant nodes and edges as text context' but does not explain output structure, side effects, or required permissions. The description adds limited behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too brief for a 6-parameter tool. It front-loads the main purpose but omits important details, making it borderline underspecified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema, no annotations) and multiple siblings, the description is incomplete. It does not explain what 'text context' looks like, how to interpret results, or provide usage examples. Sibling tools like graph_stats are not differentiated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no extra meaning over the schema; it repeats the mode choices but without enriching parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a knowledge graph using BFS or DFS, distinguishing it from siblings like get_node (single node retrieval) and shortest_path (path-specific). The verb 'Search' and resource 'knowledge graph' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use BFS vs DFS, nor compared to alternative tools like get_neighbors or shortest_path. The description implies use for traversal but lacks contextual decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the shortest path between two concepts in the knowledge graph. Follows stored edge direction by default; set undirected=true to ignore it.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source concept label or keyword | |
| target | Yes | Target concept label or keyword | |
| max_hops | No | Maximum hops to consider | |
| undirected | No | Ignore stored edge direction when searching | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the default directed-traversal behavior and the undirected escape hatch, but says nothing about the return shape (path vs. node list), behavior when no path exists, or traversal cost limits beyond max_hops in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero filler, with the core purpose front-loaded and the behavioral modifier second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter read tool with no annotations and no output schema, the definition covers purpose and the direction flag but leaves the result format and no-path behavior unstated, which an agent would need to call and interpret it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented in the schema; the description only re-explains undirected, which the schema already covers. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Find the shortest path between two concepts in the knowledge graph'), which is unambiguous and distinct from siblings like get_neighbors or query_graph. It does not explicitly name which sibling to prefer in which situation, but the operation itself is clearly scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('between two concepts') and explains the undirected toggle condition, but never says when to choose this over get_neighbors or query_graph, nor any preconditions (e.g., concepts must exist in the graph). Usage is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return all actionable open PRs (correct base, not stale) with full graph impact data so you can reason about review priority, merge order, and conflict risk. Call this when the user asks 'what PRs should I review?' or 'what's ready to merge?'
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Base branch to filter PRs by (auto-detected if omitted) | |
| repo | No | GitHub repo (owner/repo). Defaults to current repo. | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the filtering criteria (correct base, not stale) and mentions graph impact data. However, it doesn't define 'actionable' or 'stale' precisely, nor does it disclose any side effects, rate limits, or output structure details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: first sentence states purpose and value, second sentence gives usage guidance. It is front-loaded, concise, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks output schema, so it should provide more detail on the return value. While it mentions 'full graph impact data' and reasoning use cases, it does not specify the structure or fields included, leaving the agent partially informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all three parameters (base, repo, project_path) with clear defaults. The tool description does not add additional parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('return') and a clear resource ('actionable open PRs with graph impact data'). It distinguishes from sibling tools like list_prs (raw list) and get_pr_impact (single PR) by emphasizing triage and priority reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call the tool ('when user asks what PRs to review or what's ready to merge'). It provides clear context but does not explicitly mention when not to use it or which sibling alternatives to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_communityget_neighborsget_nodeget_pr_impactgod_nodesgraph_statslist_prsquery_graphshortest_pathtriage_prsScored across 10 tools
The graph tools (query_graph, get_node, get_neighbors, get_community, god_nodes, graph_stats, shortest_path) each target a clearly distinct operation. The PR tools are mostly distinct, though list_prs and triage_prs overlap heavily—both return open PRs with graph-impact data—and only the descriptions' filtering nuance (actionable/correct base/not stale) separates them.
All names use consistent snake_case, which is predictable and readable. However, the verb pattern is not strictly uniform: several are noun phrases (god_nodes, graph_stats, shortest_path) while others are verb_noun (get_node, list_prs), a minor deviation.
Ten tools is well-scoped for a knowledge-graph query plus PR-triage server, with each tool earning its place. No redundancy that would push it toward bloat.
Read-side graph coverage is solid (search, fetch, neighbors, community, hubs, stats, pathfinding) and the PR workflow is covered from listing to impact to triage. The only gap is the absence of any mutation tools (add/update/delete node or edge), which an agent might expect for a 'second brain'.
Repository knowledge graph MCP server for codebase understanding and debugging.
Personal knowledge graph as an AI memory layer over MCP - read, save, and link your memories.
MCP server for querying BrainKB, a knowledge base for neuroscience knowledge graphs.
Read-only MCP server for wafergraph.com's semiconductor & AI supply-chain data: 30 tools, no auth.