Skip to main content
Glama
AbdessamadTzn

FastAPI Architect MCP

graph_neighbors

Explore relationships and dependencies around any code node in a FastAPI project. Filter by direction and edge types to trace usage, calls, and references.

Instructions

Explore the knowledge graph around a node.

node can be a graph id, a route ("GET /api/users/" or "/api/users/"), a table name, or a function/class name. direction is "out" (what it uses), "in" (what uses it) or "both". edge_types filters edges, e.g. ["DEPENDS_ON", "CALLS"]. Valid types: INCLUDES, HAS_ROUTE, HANDLED_BY, DEPENDS_ON, ACCEPTS, RETURNS, CALLS, USES, QUERIES, RENDERS, MIDDLEWARE, INHERITS, MAPS_TO, REFERENCES, RELATES_TO, MIRRORS, DEFINES (excluded by default).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeYes
depthNo
directionNoboth
edge_typesNo
project_rootYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It honestly conveys the flexible node resolution, direction semantics, and edge-type filtering, including the fact that DEFINES is excluded by default. It does not mention output shape, depth behavior, or any read-only/safety expectations, though 'explore' implies a non-mutating operation.

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 front-loaded with the core action, then compactly explains each relevant parameter and valid values. The edge-type list is dense but necessary. There is no filler or redundant repetition of the schema.

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 covers the main behavior and several parameter nuances, making it minimally viable for an agent to invoke the tool with defaults. However, it omits meaningful context about `project_root`, the semantics/bounds of `depth`, and what output the agent should expect. Given five parameters and no output schema or annotations, this is a noticeable gap.

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 0%, so the description must compensate for all parameters. It does explain `node`, `direction`, and `edge_types` in detail, adding meaning beyond the schema. However, `depth` and `project_root` are not described, leaving two of five parameters underspecified.

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 a specific action ('Explore the knowledge graph around a node') and identifies the tool's resource. It clarifies the flexible forms `node` can take, which sharpens the purpose. However, it does not explicitly distinguish this from siblings like `get_dependencies` or `find_references`.

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 first line implies the usage context: exploring neighbors in the knowledge graph. Parameter semantics are explained well, but there is no explicit guidance on when to choose this over sibling tools such as `find_path`, `get_dependencies`, or `find_references`. No alternatives or exclusions are named.

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