Skip to main content
Glama
Sign In
gograph

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_flow

Read-onlyIdempotent

Trace potential untrusted-data flows from HTTP, JSON, or environment sources to SQL, process, filesystem, or outbound HTTP sinks during Go security reviews.

Instructions

Find potential untrusted-data paths from HTTP request objects, decoded JSON values, or environment variables to SQL query text, process execution arguments, filesystem paths, or outbound HTTP targets. The MCP server refreshes source analysis before this call; run gograph build . --precise first for stronger method/interface targets. Read-only; no side effects. WHEN TO USE: During a security review or before changing request parsing, command execution, file access, SQL construction, or URL handling. NOT TO USE: As proof of exploitability; the analysis is path-insensitive and call/return context for the 3 most recent call sites by default (context depth up to 16; deeper returns that lose their call site are kept at low confidence), bounded by a size-derived work budget that reports incomplete runs explicitly. RETURNS: Structured findings with source, sink, severity, confidence, and path steps. Configure trusted return-value sanitizers in .gograph/flow.json or with config.

Input Schema

NameRequiredDescriptionDefault
rootNoAbsolute path of the checkout you are working in (your cwd or git worktree). Must be this server's repository or one of its git worktrees; the answer then comes from that checkout's own graph. A path elsewhere is refused. Alias: cwd. Omit only when the configured checkout is the one you mean.
sinkNoOptional sink kind: sql_query, process_execution, filesystem, or outbound_http
termNoOptional substring filter matched against functions, files, endpoints, and path steps
configNoSanitizer policy path inside the graph root (default .gograph/flow.json when present)
sourceNoOptional source kind: http_request, decoded_json, or environment
max_workNoOptional propagation work budget; defaults to a value derived from the number of flow facts. An exhausted budget returns completeness.complete=false with partial findings.
no_testsNoExclude functions in *_test.go files
intentionNoTechnical rationale, required for analytical calls selecting an active session.
session_idNoCaller selector returned by session_create. Omission means an independent caller; never inherits server environment or another caller's session.
context_depthNoOptional call-site frames kept per value (default 3, max 16). Deeper settings are more precise and need more work.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.7.18
    • addedInput schema / properties / context_depth
      Added value: +{
+  "description": "Optional call-site frames kept per value (default 3, max 16). Deeper settings are more precise and need more work.",
+  "type": "number"
+}
    • addedInput schema / properties / intention
      Added value: +{
+  "description": "Technical rationale, required for analytical calls selecting an active session.",
+  "type": "string"
+}
    • addedInput schema / properties / max_work
      Added value: +{
+  "description": "Optional propagation work budget; defaults to a value derived from the number of flow facts. An exhausted budget returns completeness.complete=false with partial findings.",
+  "type": "number"
+}
    • addedInput schema / properties / root
      Added value: +{
+  "description": "Absolute path of the checkout you are working in (your cwd or git worktree). Must be this server's repository or one of its git worktrees; the answer then comes from that checkout's own graph. A path elsewhere is refused. Alias: cwd. Omit only when the configured checkout is the one you mean.",
+  "type": "string"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Caller selector returned by session_create. Omission means an independent caller; never inherits server environment or another caller's session.",
+  "type": "string"
+}
  2. Addedv1.5.3
  3. Removedv1.5.3
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, no side effects, but the description goes well beyond them: it discloses that the server refreshes source analysis before the call, that the analysis is path-insensitive, that call/return context defaults to 3 frames (max 16) with deeper returns degrading to low confidence, and that a size-derived work budget can return an explicitly incomplete run. That is substantive operational context an agent cannot get from annotations.

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?

Front-loaded with purpose, then clearly labeled WHEN TO USE / NOT TO USE / RETURNS blocks. The NOT TO USE sentence is dense and packs several caveats (path-insensitivity, context depth, work budget) into one long construction, which slightly hurts scannability but every clause carries information.

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?

For a 10-parameter analytical tool with no output schema, the description covers what it does, prerequisites, explicit limitations, what the findings contain (source, sink, severity, confidence, path steps), and how to configure sanitizers. An agent has everything needed to decide and invoke it correctly.

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 description coverage is 100%, so the schema already carries parameter meaning. The description nonetheless adds value by explaining that trusted return-value sanitizers are configured via .gograph/flow.json or the config parameter, and by naming the confidence/completeness consequences of the context_depth and max_work settings, which the schema states only briefly.

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 opens with a precise verb+resource pair ('Find potential untrusted-data paths') and enumerates both source kinds (HTTP request objects, decoded JSON, environment variables) and sink kinds (SQL text, process execution args, filesystem paths, outbound HTTP). This is a specific taint-flow analysis, clearly distinguishable from a generic path or trace tool.

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 has explicit WHEN TO USE ('during a security review or before changing request parsing, command execution, file access, SQL construction, or URL handling') and NOT TO USE sections, plus a stated prerequisite to run `gograph build . --precise` first. Alternatives aren't named by sibling, but the exclusion criteria do the routing work.

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

Deploy Server

Other Tools