Skip to main content
Glama

code_query

Query source code to trace variable references, analyze procedural flow, map field lineage, or discover dataflow dependencies across compiled programs and copybooks.

Instructions

Query parsed code knowledge. Select query_type to control behavior:

  • trace_variable: Trace all references to a variable in a parsed source file — shows where it is read, written, or passed, grouped by section/paragraph.

  • impact: Query the compiled knowledge graph for downstream impact — returns affected programs, copybooks, or datasets grouped by dependency depth, with evidence and uncertainty markers.

  • procedure_flow: Query parsed procedure/section PERFORM flow for one source file — returns section-level and paragraph-level flow, optionally focused on one procedure.

  • field_lineage: Query compiled field-lineage artifacts — returns deterministic and inferred matches for one field, optionally narrowed to a copybook or qualified name.

  • dataflow_edges: Query field-level dataflow edges — MOVE/COMPUTE/ADD assignment, EXEC SQL host-variable, and CALL USING parameter edges. Filter by from/to, or set field+transitive: true to follow chains across the full graph.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
query_typeYesQuery type: trace_variable, impact, procedure_flow, field_lineage, or dataflow_edges
pathNo[trace_variable/procedure_flow/dataflow_edges] Path to source file in raw/ (e.g. 'PAYROLL.cbl')
variableNo[trace_variable] Variable name to trace (e.g. 'WS-TOTAL-SALARY')
node_idNo[impact] Canonical node ID or logical name (e.g. 'copybook:DATE-UTILS' or 'DATE-UTILS')
kindNo[impact] Optional node kind: program, copybook, dataset, job, or step
max_depthNo[impact/dataflow_edges] Maximum traversal depth (default: 10)
languageNo[impact/field_lineage] Compiled language artifact set to read (default: 'cobol')
procedureNo[procedure_flow] Optional procedure/section/paragraph name to focus traversal from (e.g. 'A100-INIT')
procedure_kindNo[procedure_flow] Optional procedure kind filter: section or paragraph
field_nameNo[field_lineage] Field name to query (e.g. 'CUSTOMER-ID')
qualified_nameNo[field_lineage] Optional qualified field path (e.g. 'CUSTOMER-REC.CUSTOMER-ID')
copybookNo[field_lineage] Optional copybook canonical id or logical name (e.g. 'copybook:CUSTOMER-A' or 'CUSTOMER-A')
fromNo[dataflow_edges] Filter: only edges whose source field matches (e.g. 'EMP-SALARY')
toNo[dataflow_edges] Filter: only edges whose target field matches (e.g. 'WS-TOTAL-SALARY')
fieldNo[dataflow_edges] Starting field for transitive traversal (requires transitive: true)
transitiveNo[dataflow_edges] Follow edges transitively from `field` (default: false)
directionNo[dataflow_edges] Traversal direction when transitive: true — downstream (default), upstream, or both
Behavior5/5

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

For each query type, the description explains what is returned (e.g., reads/writes, affected programs, flow, lineage, edges) and mentions uncertainty markers and transitive chains, providing full behavioral clarity without annotations.

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 well-organized in a bullet list, front-loaded with purpose, and every sentence is informative without redundancy.

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?

Given 17 parameters and no output schema, the description compensates by detailing return behaviors per query type, making it sufficiently complete for an agent.

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 baseline is 3. The description adds value by grouping parameters per query type and explaining their role, which aids selection.

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 queries parsed code knowledge, lists five distinct query types with specific purposes, and differentiates from sibling tools like code_parse and knowledge_ingest.

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 provides detailed guidance on when to use each query type and which parameters apply, but lacks explicit exclusions or alternatives for sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

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/xinhuagu/agent-wiki'

If you have feedback or need assistance with the MCP directory API, please join our Discord server