A
licenseNot graded
qualityD
maintenanceSecure multi-source MCP server for reading local, GitHub, GitLab, Bitbucket, and network source code with read-only-by-default access, enabling AI assistants to inspect repositories safely.
1
MIT
sec-graph
by Vadale
Click on "Install 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., "@sec-graphlist all unguarded sinks"
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.
sec-graph
An interactive security map + local‑LLM triage layer over any SAST.
sec-graph is not another taint engine. It takes the findings your existing static analyzer already produces — CodeQL, Semgrep, Bandit, anything that emits SARIF — binds them to a code map, enriches them with two layers no engine ships (a credentials / PII layer and an auth / unguarded verdict), and hands each finding to your own local LLM over MCP as a minimal, hash‑verified source→sink slice for triage. Everything runs locally and deterministically; no finding data leaves your machine.
Built on graphify (MIT). A small built‑in Python taint engine is kept as the fallback for when you don't have a SARIF report — it is not the product.
The layer no SAST ships: red glow = a dangerous sink reachable with no auth barrier (triage these first) · green ring = the same sink behind a real auth check. Colour = data layer; the right‑hand sidebar carries each finding's CWE + the hash‑verified source→sink slice an LLM triage call receives.
Why
Mature SAST engines are very good at finding data‑flows and very bad at two things a human (or an LLM) actually needs to triage them: "is this reachable without authentication?" and "does this path touch a credential/PII?" — plus they dump raw findings with no cheap way to feed just the relevant code to a model. sec-graph adds exactly those, on top of whatever engine you already run.
Related MCP server: graphward
Does it actually help? (an honest benchmark)
We pre‑registered and ran a control‑vs‑treatment benchmark — a local Gemma 3n E4B triaging the same 66 CodeQL findings on three deliberately‑vulnerable Python apps, whole‑file context vs sec-graph's MCP slices, scored against hand‑labelled, independently‑audited ground truth. The honest result:
The robust win is efficiency — sec-graph's minimal slices matched whole‑file triage quality at ~1/7th the prompt tokens and ~half the wall‑time (12× fewer tokens per finding on large files). That's what makes per‑finding triage cheap enough to run on a local model.
Accuracy: a small, statistically‑inconclusive, repo‑dependent edge (real/FP +6 pts pooled, not significant) — reported as a signal, not a result.
The self‑audit is honest about a limitation. sec-graph's
unguardedverdict over‑reports (56% precision) when an app uses a custom auth decorator/callable not in the default barrier list, or a guard in a calling function — though it never falsely claimsguarded(100%). That's configuration + a future interprocedural improvement, published, not buried.
Full methodology, numbers, and a "when it helps / when it doesn't" table: benchmark/BENCHMARK.md · pre‑registration: benchmark/PROTOCOL.md.
On a real repo (PyGoat + CodeQL's 40 findings): most web‑app findings are intra‑function, so the map is
a constellation of unguarded hotspots rather than long routes — the enriched sidebar is the workhorse
there, and the graph earns its keep on cross‑function/cross‑file data‑flow. Honest by design.
Install
pip install -e . # or: uv pip install -e .
secgraph --versionRequires Python ≥ 3.11. Pulls graphify, tree-sitter, mcp, typer, pyyaml.
Quickstart
# 1. run your SAST and export SARIF
codeql database create db --language=python && \
codeql database analyze db --format=sarif-latest -o findings.sarif \
codeql/python-queries:codeql-suites/python-security-extended.qls
# (or) semgrep scan --sarif -o findings.sarif
# 2. bind + enrich + map
secgraph analyze ./my-app --sarif findings.sarif # -> graph.json, taint.json, secgraph.html
secgraph view # open the interactive layered map
# 3. triage with your own LLM over MCP
secgraph serve # read-only MCP server (stdio)No SARIF? secgraph analyze ./my-app runs the built‑in Python fallback engine instead.
How it works
Ingest — parse SARIF (
results+codeFlows) or Semgrep JSON into one normalized finding, bound to the code graph structurally (by(file, def‑line)span, never by name).Enrich — add, per finding: sensitive‑data layers (credentials/PII identifiers & secret patterns on the tool‑verified flow lines) and, for Python sinks, an auth/unguarded verdict from a structural guard analysis, with an honest tri‑state (
analyzed/unknown— never a false "guarded").Map — a self‑contained, deterministic force‑directed HTML map: colour = data layer, red glow =
unguarded, a one‑click "Critical paths" preset.Triage over MCP —
secgraph serveexposes read‑only tools (list_paths,get_path_slice,find_unguarded_sinks,explain_layer,get_function_taint) that hand your LLM the minimal, hash‑verified code windows for a path — never the whole repo. Run it alongsidegraphify --mcp(entity‑level questions stay with graphify; data‑flow paths are ours).
Enrichment in action (credentials + untrusted-input layers): a hard‑coded secret:aws-access-key-id
and credentials‑tagged data‑flows in amber — surfaced from the same findings, with tags no engine emits.
The analysis core is deterministic — no LLM on the critical path; analyze twice is byte‑identical.
Scope & honest limits
sec-graph is bounded by your upstream SAST's recall — it adds no findings the engine missed. The
enrichment is lexical (identifier/secret patterns on a proven flow), stronger than grep but weaker than
value‑tracking taint. The auth verdict and the built‑in engine are Python‑only; other languages get
the map + slices but a guard_status: unknown. See BENCHMARK.md for the measured weaknesses (including a
current guard‑analysis bug); the licence/scope notes for each engine are in docs/.
Development
uv pip install -e ".[dev]"
pytest # 121 tests
pytest tests/contract # the graphify contract testArchitecture: docs/architecture.md · contributing: CONTRIBUTING.md.
License & credits
MIT (see LICENSE). Built on graphify (MIT); parses CodeQL / Semgrep SARIF; uses
tree-sitter. sec-graph ships no third‑party code — those are runtime dependencies / input formats.
Responsible use
Defensive and static only — sec-graph exploits nothing and ships no exploit code; the MCP triage prompts enforce a defensive framing. Audit code you own or are authorized to review, and practice coordinated disclosure. Do not use it to mass‑scan third‑party code and publish 0‑days.
Available Tools
10 toolsget_communityC
Get all nodes in a community by community ID.
ParametersJSON Schema
| 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. |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states what the tool returns ('all nodes'), with no mention of read-only nature, potential errors, side effects, or performance implications.
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?
The description is a single, straightforward sentence with no unnecessary words. It is concise, though it could benefit from more structure or bullet points for additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too sparse. It does not clarify what information about the nodes is returned, nor does it address pagination or error scenarios.
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 coverage is 100% with each parameter having a clear description. The tool's description adds no extra meaning beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get'), the resource ('all nodes in a community'), and the key identifier ('by community ID'). It is specific enough to distinguish from sibling tools like get_node or get_neighbors, though it does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor are there any conditions or prerequisites mentioned. The description does not cover when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_neighborsA
Get all direct neighbors of a node with edge details.
ParametersJSON Schema
| 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. | |
| relation_filter | No | Optional: filter by relation type |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions 'edge details' but does not specify what details (e.g., direction, properties), nor does it mention pagination, performance, or resource impact. This is minimal disclosure.
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?
Single sentence of 9 words. No filler, front-loaded. Every word adds value.
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 no output schema and no annotations, the description is adequate for a simple neighbor lookup but lacks details on output structure (node vs edge format, order). It covers basic functionality.
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 coverage is 67% (2 of 3 params described). The description adds no extra meaning to any parameter; the undocument label param is not explained. Baseline 3 is appropriate as schema already provides most info.
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 'Get all direct neighbors of a node with edge details' clearly states the action (get), the resource (direct neighbors), and distinguishes from siblings like get_node (single node) and shortest_path (paths).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when direct neighbors with edge details are needed, but no explicit guidance on when not to use or alternatives. Sibling tools like get_node or shortest_path are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nodeB
Get full details for a specific node by label or ID.
ParametersJSON Schema
| 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. |
TDQS
B3.2/5.0
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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_pr_impactA
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.
ParametersJSON Schema
| 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. |
TDQS
A3.8/5.0
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
god_nodesB
Return the most connected nodes - the core abstractions of the knowledge graph.
ParametersJSON Schema
| 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. |
TDQS
B3.1/5.0
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
graph_statsA
Return summary statistics: node count, edge count, communities, confidence breakdown.
ParametersJSON Schema
| 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. |
TDQS
A3.5/5.0
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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_prsA
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.
ParametersJSON Schema
| 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. |
TDQS
A4/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
query_graphB
Search the knowledge graph using BFS or DFS. Returns relevant nodes and edges as text context.
ParametersJSON Schema
| 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'] |
TDQS
B3.4/5.0
Behavior3/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
shortest_pathC
Find the shortest path between two concepts in the knowledge graph.
ParametersJSON Schema
| 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 | |
| project_path | No | Absolute path to a project directory containing graphify-out/graph.json. Optional — defaults to the graph this server was started with. |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It only states the high-level function without disclosing algorithm complexity, output format, error handling (e.g., no path found), or other behavioral traits.
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?
Single sentence, no extraneous words. However, it lacks structure such as bullet points or separated sections; the minimalism is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should explain what 'concepts' are, what the output looks like, and limitations. It fails to provide enough context for an agent to fully understand the tool's behavior.
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 covers all 4 parameters with descriptions, so description adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (find) and resource (shortest path) clearly, specifying it operates on two concepts in the knowledge graph. It distinguishes from sibling tools like get_node or get_neighbors but does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 query_graph or get_neighbors. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
triage_prsA
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?'
ParametersJSON Schema
| 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. |
TDQS
A3.9/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
10 tool updates
v0.1.0- First observed
get_community - First observed
get_neighbors - First observed
get_node - First observed
get_pr_impact - First observed
god_nodes - First observed
graph_stats - First observed
list_prs - First observed
query_graph - First observed
shortest_path - First observed
triage_prs
TDQS
A3.6/5.0
Disambiguation5/5
Each tool has a distinct purpose: graph exploration tools (get_community, god_nodes, graph_stats, shortest_path, query_graph, get_node, get_neighbors) and PR impact tools (list_prs, get_pr_impact, triage_prs) are clearly separated with no overlap.
Naming Consistency4/5
Most tools follow verb_noun pattern (get_community, graph_stats, list_prs, etc.), but 'god_nodes' breaks the pattern with an unclear verb. Otherwise consistent.
Tool Count5/5
10 tools cover both graph querying and PR impact analysis without being excessive. Each tool earns its place for a knowledge graph with CI integration.
Completeness4/5
Graph operations are well-covered (nodes, communities, paths, stats, neighbors) and PR impact analysis is thorough. Minor gaps: no tool to update/close PRs, but triage_prs covers review priority.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
MCP server for static security analysis of Android source code
Related MCP Servers
- AlicenseNot gradedqualityBmaintenancePrivate, local-first code intelligence MCP server that builds a static graph of repositories and exposes search, architecture, impact analysis, and review tools via MCP.MIT
- AlicenseNot gradedqualityAmaintenanceA secure, local-first MCP server for read-only inspection and troubleshooting of development environments, exposing narrow, typed, auditable capabilities for repository inspection, log summarization, Docker review, and security scanning without granting unrestricted machine access.MIT
- AlicenseNot gradedqualityBmaintenanceStandalone MCP server that provides security scanning, project mapping, and vulnerability fix generation to AI coding assistants.7912MIT
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/Vadale/sec-graph'
If you have feedback or need assistance with the MCP directory API, please join our Discord server