Skip to main content
Glama
Sign In
Agent Genesis Tools

Agent Genesis Tools

by xvacorx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

build_codebase_graph

Builds an indexed AST knowledge graph for a repository, mapping classes, functions, and import dependencies into dependency maps and structural summaries so coding agents can explore and refactor code before querying it.

Instructions

Generates and indexes the AST knowledge graph for a repository, creating precomputed dependency maps, god classes, and structural summaries in graphify-out/. Mutating file operation: creates or updates only the local graphify-out/ artifact directory inside the target repository root; leaves all existing source code files unmodified. Requires zero network access or external credentials. If the external graphify CLI is installed in PATH, invokes it; otherwise, automatically executes a native, zero-dependency Python AST parser to extract classes, functions, and import dependencies.

When to use: Call before deep codebase refactoring or exploration when inspect_codebase_graph indicates no graph exists. When NOT to use: Do not use if graphify-out/ is already active and up-to-date; use query_codebase_graph to query the existing graph directly. Returns: Build report containing extracted node count, edge count, detected god classes, and path to the generated graphify-out/ directory.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_codebase_graph"
  }
}

Input Schema

NameRequiredDescriptionDefault
repo_pathNoAbsolute or relative path to the target repository root where graphify-out/ will be built. If omitted, empty string, or '.', defaults to the current working directory.
force_rebuildNoWhether to overwrite an existing graphify-out/ directory if already present. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it discloses the exact mutation scope ('creates or updates only the local graphify-out/ artifact directory... leaves all existing source code files unmodified'), that no network or credentials are needed, and the CLI-vs-native-parser fallback behavior. These are precisely the facts an agent needs before invoking a write operation.

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?

Information is front-loaded (action, mutation scope, requirements, fallback) and then clearly delimited with 'When to use', 'When NOT to use', and 'Returns' labels. It is denser than strictly necessary for a two-parameter tool, but each sentence contributes a distinct, non-redundant fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although there is no output schema, the description supplies a 'Returns' section covering node count, edge count, god classes, and output path. Combined with the mutation scope, side-effect bounds, and fallback behavior, an agent has everything required to call this tool correctly and interpret the result.

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 repo_path and force_rebuild are already fully documented in the schema. The description adds only indirect context — the 'when NOT to use if graphify-out/ is up-to-date' clause indirectly motivates force_rebuild — so it does not meaningfully extend parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Generates and indexes the AST knowledge graph for a repository') and names the concrete artifacts produced (dependency maps, god classes, structural summaries in graphify-out/). It is immediately distinguishable from the sibling read tools inspect_codebase_graph and query_codebase_graph.

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?

Includes explicit 'When to use' (before refactoring/exploration, only when inspect_codebase_graph reports no graph) and 'When NOT to use' (if graphify-out/ is fresh, use query_codebase_graph instead). The alternative tool and the condition selecting it are both stated, leaving nothing to inference.

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