Skip to main content
Glama
Sign In
Agent Genesis Tools

Agent Genesis Tools

by xvacorx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

query_codebase_graph

Traverses and searches a codebase AST graph to inspect symbol definitions, trace dependencies, identify god classes, and examine functional clusters without loading massive source files.

Instructions

Traverses and searches the codebase AST knowledge graph to inspect symbol definitions, identify architectural god classes, trace dependencies, or examine functional clusters. Safe, read-only query: performs local file reads without mutations, network calls, or authentication. If the AST graph has not been precomputed (graphify-out/ missing), safely executes a non-failing structural fallback scan of top directories and code files with instructions to run graphify.

When to use: Call during codebase onboarding, architectural review, or refactoring to retrieve targeted structural relationships without loading massive source files. When NOT to use: Do not use if you only need high-level graph health or existence; call get_graphify_status instead. Returns: Structured architectural intelligence matching the query mode: summary statistics, ranked god classes by centrality, top connected dependencies, or matched symbol occurrences.

Input Schema

NameRequiredDescriptionDefault
queryNoTarget symbol name (class, function, file) or operational keyword: 'summary' (overall metrics), 'god_nodes' (classes with highest centrality/complexity), 'dependencies' (top connected modules), or 'communities' (cluster breakdown). Case-insensitive. Defaults to 'summary'.summary
repo_pathNoAbsolute or relative path to the target repository root containing graphify-out/. If omitted, empty string, or '.', queries the current working directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.2
    • changedInput schema / properties / query / description
      Previous value: -"Query target or operation mode: enter a class/function/symbol name to look up, or one of the special commands: 'summary' (overall architecture & metrics), 'god_nodes' (classes with highest complexity/dependencies), 'dependencies' (top connected modules), or 'communities' (detected functional clusters)."New value: +"Target symbol name (class, function, file) or operational keyword: 'summary' (overall metrics), 'god_nodes' (classes with highest centrality/complexity), 'dependencies' (top connected modules), or 'communities' (cluster breakdown). Case-insensitive. Defaults to 'summary'."
    • changedInput schema / properties / repo_path / description
      Previous value: -"Absolute or relative path to the repository containing graphify-out/. If omitted or empty, queries the current working directory."New value: +"Absolute or relative path to the target repository root containing graphify-out/. If omitted, empty string, or '.', queries the current working directory."
  2. Addedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it declares read-only semantics (local file reads, no mutations, no network calls, no auth) and discloses a non-obvious fallback path when graphify-out/ is missing, including that the fallback is non-failing and emits instructions to run graphify. This is behavior an agent could not infer from the schema and materially affects trust and error handling.

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 the core action, then cleanly sectioned into usage, exclusions, and returns. Slight redundancy between the capability list in sentence one and the "Returns" line, but no sentence is wasted given the tool's complexity.

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?

No output schema exists, yet the description summarizes what comes back per mode (summary statistics, ranked god classes, dependencies, matched occurrences). Combined with the safety and fallback disclosure, an agent has everything needed to call this correctly and interpret results.

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 both parameters are already fully documented with defaults and the keyword enum-equivalents. The description's "Returns" line restates the query modes but adds no syntax, format, or edge-case guidance (e.g., symbol name matching rules, path resolution) beyond the schema. Baseline 3 applies.

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 specific verb+resource pair ("Traverses and searches the codebase AST knowledge graph") and enumerates the concrete tasks it supports: symbol definitions, god classes, dependency tracing, clusters. It explicitly distinguishes itself from the sibling get_graphify_status by scope (structure vs. graph health).

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?

Dedicated "When to use" and "When NOT to use" sections name the triggering contexts (onboarding, architectural review, refactoring) and route the agent to get_graphify_status for health/existence checks. Nothing is left to inference about alternative selection.

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