Skip to main content
Glama

topos_evaluate_project

Recursively score all supported source files in a directory on SIMPLE, COMPOSABLE, and SECURE dimensions, with automatic language detection and project-wide rollup.

Instructions

Recursively score every supported source file in a directory on the SIMPLE / COMPOSABLE / SECURE lattice, with a project rollup (side-effecting). Autodetects all supported languages (Python, Rust, JavaScript, TypeScript, C++, Go) in one walk — no language argument — and skips unsupported files. The rollup takes the project-wide minimum per dimension (weakest file floors it). Returns a paginated per-file table (worst first) plus per-language rollups; page with limit / offset. Unless no_composable is set, generates/refreshes .gitnexus when missing or stale before scoring, same as topos_evaluate_file and the CLI's topos evaluatecoupling_available/warnings explain it when that isn't possible, without failing the evaluation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory to evaluate, walked recursively. Must resolve inside the trusted file root; paths outside it are refused. All supported languages are autodetected — no language argument is needed.
allowNoDangerous-call patterns to acknowledge for this run only.
limitNoPer-file rows to return per page (1–500, default 25).
offsetNoZero-based row offset for pagination; pass the response's `next_offset` to fetch the next page.
verboseNoWhen true, include each file's raw metric values alongside scores.
preferencesNoOptional ranking of simple/composable/secure (best first). The top-ranked generator sets scorer priority; omit to default to SIMPLE priority.
gitnexus_dirNoPath to a `.gitnexus` dependency-graph directory, for COMPOSABLE scoring. When omitted, it is auto-detected from the project root; if missing or stale, this tool generates/refreshes it first (see `no_composable`). If generation isn't possible (GitNexus not installed, generation failure), COMPOSABLE is reported as unavailable rather than failing the whole evaluation.
no_composableNoSkip GitNexus detection/generation; score SIMPLE/SECURE only, exactly like a missing `.gitnexus` did before this tool started generating it automatically.
include_security_findingsNoWhen true, attach per-file SECURE findings to each entry; off by default to keep responses compact.
Behavior5/5

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

The description fully discloses the side-effecting nature (generating/refreshing .gitnexus), pagination behavior, handling of missing dependencies (graceful non-failure), and the rollup logic (minimum per dimension). Annotations already provide readOnlyHint=false, so the description aligns and adds depth.

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?

The description is well-structured, front-loading the core purpose and then detailing behavior and parameters. It is slightly verbose (e.g., explaining the rollup in multiple sentences) but every sentence adds value. Could be trimmed slightly without losing clarity.

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

Completeness4/5

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

Given 9 parameters and no output schema, the description covers the main input semantics, side-effect, pagination, and return structure ('paginated per-file table plus per-language rollups'). It lacks detailed output field descriptions but is sufficient for an agent to understand the tool's behavior.

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 coverage is 100%, so the schema documents all parameters. The description adds overarching context (e.g., path must be within trusted root, pagination via limit/offset, auto-detection of gitnexus_dir) but does not provide new semantics beyond what the schema descriptions already offer.

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 verb ('recursively score'), the resource ('every supported source file in a directory'), and the specific lattice (SIMPLE / COMPOSABLE / SECURE). It distinguishes from sibling tools like topos_evaluate_file (single file) and topos_assess_* (changeset analysis) by explicitly mentioning project-wide recursion and rollup.

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 clear context on when to use: for scoring an entire project directory. It mentions autodetection of languages and the side-effect of generating .gitnexus. However, it does not explicitly state when not to use (e.g., for single files) or name alternatives, though the sibling tools list implicitly covers this.

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/Krv-Labs/topos'

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