The Repo Test Architect server provides deterministic, audit-first test strategy tooling over MCP for codebases. It allows you to:
Perform a full repository analysis (analyze_repository): detect projects, audit them, and receive a complete summary with findings, test candidate rankings, a test plan, execution hints, and statistics in one pass.
Discover project structure: list language adapters, detection rules, and detect project roots (list_adapters, list_project_detection_rules, detect_projects).
Audit projects: obtain raw audit artifacts for all supported roots (audit_projects) or a single selected project (audit_repo), and validate existing audit graphs (get_audit_graph).
Process audit artifacts: summarize coverage, rank test candidates, generate test plans, collect findings, analyze test placement, and gather project statistics (summarize_project_audits, rank_project_candidates, generate_project_test_plan, collect_project_findings, analyze_project_test_placement, collect_project_stats).
Generate detailed test plans: produce deterministic plans from an audit, and derive execution hints for parallel safety, context, and repository reasoning (generate_test_plan, get_plan_execution_hints).
Explain audit targets by stable ID (explain_target).
Rank test candidates and analyze placement from a single audit (rank_test_candidates, analyze_test_placement).
Deferred test generation: returns a structured deferred artifact without writing test code (generate_selected_test).
All operations are deterministic, model- and subagent-free, exposing CLI-style capabilities for automated test strategy auditing.
Detects and incorporates Bun test runner usage into JavaScript/TypeScript audit and test planning.
Audits PHP projects using Composer, including PSR-4 autoloading and PHPUnit test configuration.
Detects Cypress end-to-end test usage in JavaScript/TypeScript projects and integrates it into test strategy.
Analyzes Django web projects, including static test-client route evidence for test planning.
Audits Elixir applications, including Mix project structure, task ownership, and ExUnit test detection.
Supports Express and Supertest-based projects, contributing route evidence for test planning in JavaScript/TypeScript audits.
Analyzes FastAPI projects, including static test-client route evidence for test planning.
Analyzes Flask projects, including static test-client route evidence for test planning.
Audits JVM projects built with Gradle, including dependency-qualified module evidence and test framework support (JUnit, kotlin.test, TestNG, etc.).
Provides comprehensive repository audit and test planning for JavaScript projects, detecting multiple test frameworks and project structures.
Detects Jest test framework usage in JavaScript projects and integrates it into test strategy analysis.
Audits Kotlin/JVM projects, including Gradle/Maven module roots and support for JUnit, kotlin.test, and TestNG tests.
Audits Elixir Mix applications, analyzing MixProject/Mixfile and Mix task ownership for test strategy.
Detects Mocha test usage (including CommonJS) in JavaScript projects and integrates it into test strategy.
Audits .NET (C#) test projects, including xUnit, NUnit, MSTest, and project file configuration for test planning.
Audits PHP projects, including Composer structure and PHPUnit test class analysis.
Analyzes Python projects using Poetry for dependency management and integrates with test strategy.
Detects pytest configuration and usage in Python projects, including fixture reachability and async extensions.
Provides comprehensive auditing and test planning for Python projects, supporting multiple frameworks and packaging tools.
Detects React component testing patterns, including React Testing Library, for JavaScript/TypeScript projects.
Supports auditing of Ruby projects, providing test strategy analysis based on repository structure.
Audits Cargo packages and workspaces, handling #[test] and #[cfg(test)] modules for test planning.
Supports auditing of Swift projects, providing test strategy analysis based on repository structure.
Detects Testing Library usage (e.g., React Testing Library) in JavaScript/TypeScript projects and integrates it into test strategy.
Provides comprehensive repository audit and test planning for TypeScript projects, including TypeScript execution scripts and test framework detection.
Detects Vitest as a test runner and incorporates it into JavaScript/TypeScript test strategy.
Audit-first test strategy tooling for codebases.
Repo Test Architect builds a deterministic audit graph before asking any model or agent to reason about tests. The goal is to identify repo-native, high-value test work from facts the tool can inspect locally: project roots, framework signals, existing tests, source classifications, blockers, and remaining risk.
The current implementation can:
audit JavaScript/TypeScript, PHP, Python, Ruby, and Swift projects through supported adapters
audit supported, bounded Kotlin/JVM fixtures through the same shared artifact model
audit conventional Go modules and literal repository-contained go.work members through a supported bounded adapter
audit conventional Cargo packages and literal repository-contained workspace members through a supported bounded Rust adapter
audit one conventional SDK-style C# test project or one unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, literal and one-hop root-aliased target frameworks, one repository-contained direct *.cs compile include, finite target-conditioned package shapes, bounded nearest-file build and central-package props, exact immutable test-field receivers, stable direct-call results, inline out results, framework exception and collection/string assertions, one-hop test helpers, and guarded well-known System type collisions, through a supported bounded .NET adapter
audit one conventional Composer/PSR-4 project with PHPUnit through a supported bounded PHP adapter
audit one conventional Mix application with exact MixProject/Mixfile, bounded source and Mix-task ownership, literal local ExUnit wrapper discovery, and test-body evidence through a supported bounded Elixir adapter
detect polyglot project roots and report unsupported ecosystems without hiding them
produce a complete repository analysis, findings, ranking, plan, execution hints, and verification commands in one audit pass
classify source files by likely test value and defer low-value direct tests
rank candidates and generate test plans from the audit graph
derive provider-neutral execution, context, parallel-safety, and repository-reasoning hints without selecting models or spawning subagents
analyze conservative test placement findings across project boundaries
collect project-level stats for coverage, candidate counts, frameworks, commands, and adapter usage
provide disabled-by-default local MCP diagnostics, safe internal-error report IDs, runtime checks, and inspectable sanitized bundles without external reporting
expose the same deterministic behavior through CLI commands, a local invoke harness, and a stdio MCP SDK server
lock behavior with golden snapshots, model-consistency scenarios, package checks, and cross-OS CI
Native test generation is intentionally deferred. generate_selected_test returns a structured deferred artifact until adapter-specific generation policy and repair-loop fixtures exist.
Repo Test Architect 1.0.0-beta.1 is available as an opt-in public beta. The unqualified npm command remains on 0.3.0 while the beta is evaluated. Treat its findings as evidence-backed review input rather than an automatic instruction to change a repository. See the beta release notes.
Node.js 20 or newer is required.
Run the CLI without a global install:
npx --yes repo-test-architect doctor
npx --yes repo-test-architect analyze .Try the public beta without changing the default npm channel:
npx --yes repo-test-architect@beta doctor
npx --yes repo-test-architect@beta analyze .Or install the CLI and MCP server binaries:
npm install --global repo-test-architect
repo-test-architect doctor
repo-test-architect analyze .Add the local stdio MCP server to an MCP-capable client:
{
"mcpServers": {
"repo-test-architect": {
"command": "npx",
"args": [
"--yes",
"repo-test-architect",
"mcp"
]
}
}
}To opt into the public beta, pin the npm beta channel in the MCP configuration:
{
"mcpServers": {
"repo-test-architect": {
"command": "npx",
"args": [
"--yes",
"repo-test-architect@beta",
"mcp"
]
}
}
}The client launches the server locally. Repository source stays on the machine unless the client or another configured tool sends it elsewhere. Connected models receive instructions to start with analyze_repository for a general repository review. See MCP client config and agent install paths for global-install, local-checkout, and host-specific guidance.
Related MCP server: graphward
For a human-readable review of the current repository:
npx --yes repo-test-architect analyze .analyze detects every project root, runs each supported adapter once, and derives the audit summary, top findings, candidate ranking, test plan, execution hints, project stats, and verification commands. Markdown stays compact; JSON preserves the complete evidence bundle:
npx --yes repo-test-architect analyze . --format json
npx --yes repo-test-architect analyze . --changedUseful focused views:
Goal | Command |
Complete repository review |
|
Concise architecture findings |
|
Actionable cross-project plan |
|
Raw reusable project audits |
|
Runtime readiness |
|
Run repo-test-architect --help for the short command map or repo-test-architect <command> --help for options. The CLI reference documents the full surface.
For an MCP-connected model, the equivalent default is analyze_repository. Use narrower tools only when the request asks for one artifact or already supplies an audit artifact.
Available adapters:
csharp: one static SDK-style test project or one unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, exact literal or one-hop root-aliased target membership, one repository-contained direct *.cs compile include, finite project-local target-conditioned package predicates, and a pair selected amid unrelated projects, with bounded nearest-file Directory.Build.props metadata and static Directory.Packages.props versions, xUnit, NUnit, or MSTest attributed tests, exact project-file commands, runnable-body-owned direct type calls, bounded concrete-local or immutable test-field receivers, one-hop stable direct-call, receiver-call, or inline out var result assertions, bounded exception assertions, and one same-class private-static test-helper hop; see the C# alpha support matrix
elixir: one conventional Mix application with literal app and exact MixProject/Mixfile ownership, conventional/app-prefixed modules and protocols, exact Mix tasks, bounded acronym, terminal-plural, repeated-declaration, and compiled local ExUnit-wrapper ownership, static startup options, test-body-scoped direct fully qualified or exact-alias calls, conservative filename evidence, and a blocker-free mix test command; see Elixir alpha support
javascript: JavaScript/TypeScript repositories with Node's test runner (including TypeScript execution scripts), Bun test, AVA, Mocha/CommonJS, Vitest, Jest, Playwright, Cypress, Express/Supertest, React Testing Library detection, and bounded literal browser request-to-route evidence; see the alpha support matrix for evidence boundaries and known gaps
go: conventional go.mod projects and literal repository-contained go.work members using runnable standard-library TestXxx, FuzzXxx, or ExampleXxx tests, package-local filename, unique top-level and parser-owned concrete receiver-method symbols through explicit types, exact simple constructor results, or exact statically typed test-helper results, bounded standard-library and Testify assertion usage, parser-scoped local shadow checks, same-package or exact external-package imports (including dot imports), generic top-level functions, and bounded callable-body-owned same-package or module-local source hops, module-local commands, and optional explicit GOOS/GOARCH/custom-tag selection; see the alpha support matrix for the supported boundary and blockers
kotlin: conventional Gradle/Maven JVM module roots, settings-owned Gradle aggregates, and root-declared Maven reactors with Kotlin and/or Java standard source sets, dependency-qualified direct/exported-transitive module evidence, JUnit 4/5, kotlin.test, bounded Gradle/JUnit Platform Kotest common specs, conventional Gradle/Spock features, and method-level TestNG through direct Maven dependencies or Gradle useTestNG(); see the Kotlin/JVM alpha support matrix
php: one root Composer project with literal string-valued PSR-4 source/test ownership, bounded literal autoloaded function files, statically declared PHPUnit, exact bounded commands or explicit safe command withholding, conventional runnable test classes including one unique source- or test-owned PHPUnit base edge, direct imported or exact same-namespace class calls, and conservative basename fallback; see PHP alpha support
python: bounded Python package, FastAPI, Django, and Flask layouts with declarative multi-package/namespace ownership, configured pytest discovery, exact absolute/relative imports, one-hop source dependency evidence, static framework test-client route evidence, pytest/unittest, async and property-based extensions, fixture reachability, pip/setuptools, uv, Poetry, Hatch, tox, nox, and coverage configuration; see the Python alpha support matrix
rust: conventional Cargo packages and literal repository-contained workspace members using the built-in #[test] harness, inline #[cfg(test)] modules, exact exclusion of external test-only module graphs, exact crate-module imports from tests/, and exact unconditional crate-root symbol re-exports; see the Rust alpha support matrix
ruby: one conventional Bundler project with lib/ sources, one root gemspec or a complete exact named root-gemspec set, runnable Minitest::Test test_* methods or RSpec examples, exact bounded commands, root .rspec and exact per-file spec_helper loading, three-edge literal require/unique-constant evidence, exact singleton calls, exact constant-owned RSpec described_class, direct immutable constructor-local, one-line RSpec let/subject, exact source-factory and same-group RSpec helper receivers, and exact same-file literal shared-example inclusion, bounded assertion usage, conservative basename fallback, and explicit Minitest-spec/Rails/mixed-runner blockers; see the Ruby alpha support matrix
swift: Swift Package Manager, Xcode-style and Bazel/rules_swift layouts, Swift Testing, XCTest, Quick/Nimble, SnapshotTesting, VaporTesting/XCTVapor, reactive frameworks, and generic Fluent database boundaries with driver-specific qualifiers; see the Swift alpha support matrix
Project detection reports Elixir Mix roots through the supported bounded adapter. Unsupported ecosystems remain visible so clients can distinguish "not audited yet" from "not present."
Don't see your stack? Open an adapter request with the language or ecosystem, build system, test frameworks, and—when possible—a representative public repository. Requests help prioritize adapters against real repository shapes and user demand.
The public package exposes the audit CLI, the stdio MCP server, and a deterministic MCP invoke harness under the stable binary names documented below.
The commands below expose focused artifacts, fixtures, evals, diagnostics, and release checks for advanced use and repository development.
Run the complete analysis directly or against the polyglot example:
npm run analyze
npm run analyze:json
npm run analyze:example
npm run analyze:example:jsonCheck runtime and diagnostics readiness:
npm run doctor
npm run doctor:jsonLocal MCP diagnostics are disabled by default. They can be explicitly directed to stderr or a bounded local JSONL file; see Local diagnostics. Build a sanitized, inspectable bundle with:
npm run diagnostic-bundle -- --diagnostics-file ./.repo-test-architect/diagnostics.jsonl --format json
node ./src/cli/index.js diagnostic-bundle --diagnostics-file ./.repo-test-architect/diagnostics.jsonl --format jsonList registered adapters:
npm run adapters
npm run adapters:jsonInspect project detection marker rules:
npm run detect-rules
npm run detect-rules:jsonDetect project roots and adapter matches:
npm run detect:example
npm run detect:example:json
npm run detect:kotlin-fixture
npm run detect:kotlin-fixture:json
npm run detect:apple-fixture
npm run detect:apple-fixture:json
npm run audit-projects:example
npm run audit-projects:example:json
npm run audit-projects:changed-since
npm run summarize-projects:example
npm run summarize-projects:example:json
npm run rank-projects:example
npm run rank-projects:example:json
npm run plan-projects:example
npm run plan-projects:example:json
npm run hints-projects:example
npm run hints-projects:example:json
npm run findings-projects:example
npm run findings-projects:example:json
npm run placement-projects:example
npm run placement-projects:example:json
npm run placement-projects:split-example:json
npm run stats-projects:example
npm run stats-projects:example:jsonFor project-aware self-audits, exclude checked-in fixture or sample roots with a quoted subtree pattern:
node ./src/cli/index.js findings-projects . --exclude-project "examples/**"Reuse a saved project audit artifact:
node ./src/cli/index.js audit-projects ./examples/polyglot-workspace --format json
node ./src/cli/index.js summarize-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js rank-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js plan-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js findings-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js placement-projects --from-project-audits ./project-audits.json --format json
node ./src/cli/index.js stats-projects --from-project-audits ./project-audits.json --format jsonnpm run audit:example
npm run audit:kotlin-fixtureOutput the structured audit graph:
npm run audit:example:json
npm run audit:kotlin-fixture:jsonGenerate an actionable test plan from the audit graph:
npm run plan:example
npm run plan:example:json
npm run hints:example
npm run hints:example:json
npm run plan:kotlin-fixture
npm run plan:kotlin-fixture:json
npm run plan:item:example
npm run plan:changed
npm run plan:changed-sinceDerive advisory execution hints while leaving the plan artifact unchanged:
node ./src/cli/index.js hints ./examples/node-vitest-basic --item add-test:src/authService.ts
node ./src/cli/index.js hints-projects ./examples/polyglot-workspace --format jsonThe installing CLI or agent host remains responsible for model choice, budgets, permissions, context loading, and subagent lifecycle.
Explain one audited target by stable target ID:
npm run explain:exampleRank test candidates without generating tests:
npm run rank:exampleAnalyze existing test placement from audit evidence:
npm run placement:example
npm run placement:example:json
npm run placement:from-audit:exampleExercise the MCP-style tool surface:
npm run mcp:tools
npm run mcp:analyze:example
npm run mcp:adapters
npm run mcp:detect-rules
npm run mcp:detect:example
npm run mcp:audit-projects:example
npm run mcp:summarize-projects:example
npm run mcp:rank-projects:example
npm run mcp:plan-projects:example
npm run mcp:findings-projects:example
npm run mcp:placement-projects:example
npm run mcp:placement-split:example
npm run mcp:stats-projects:example
npm run mcp:audit:example
npm run mcp:audit:kotlin-fixture
npm run mcp:placement:example
npm run mcp:audit:envelope
npm run mcp:stdio
npm run mcp:smokeGenerate a plan from an existing audit JSON file:
npm run plan:from-audit:exampleRun the auditor regression tests:
npm test
npm run alpha:check
npm run release:checkFind and rank active public repositories for real-world adapter validation:
npm run validation:repos -- --profile react
npm run validation:repos -- --profile workspace --limit 10
npm run validation:repos -- --profile swift,gradle,maven --format jsonThe finder uses authenticated GitHub repository search, verifies exact ecosystem markers in root manifests, and ranks candidates using maintenance recency, stars, repository size, lockfiles, CI, and license metadata. Run npm run validation:repos -- --list-profiles for the available profiles and --help for quality-filter options.
Check that every supported adapter has a complete, pinned hardening corpus:
npm run corpus:check
npm run corpus:scorecard
npm run corpus:measure -- --case python-asyncer --checkout /path/to/pinned/asyncer
npm run corpus:measure -- --case python-django --checkout /path/to/pinned/django --profile-phases
npm run csharp:performance:check
npm run javascript:performance:check
npm run python:performance:check
npm run kotlin:performance:check
npm run rust:performance:check
npm run swift:performance:check
npm run go:performance:check
npm run ruby:performance:check
npm run php:performance:checkThe versioned evals/validation-corpus.json manifest records one conventional library or service, one framework-heavy application, and one difficult ownership graph per adapter cohort. Every supported adapter must have a complete cohort; a registered experimental adapter may be added only with all three roles. Each record carries the shared detection, ownership, command, evidence, ranking, stability, and performance scorecard. All 30 current pins across the ten supported adapters pass all 210 scorecard areas. A reviewed command may be null when the adapter correctly withholds unsafe execution. Cases may also carry bounded adapter audit options, such as an explicit Go build target, so repeated measurements remain host-independent.
corpus:scorecard renders the review contract for humans. It reports review completeness separately from the pass rate among reviewed checks and keeps PASS, FAIL, and PENDING visible for every area. Use npm run corpus:scorecard -- --format json for the deterministic validation-scorecard/v1 view. These are validation-review results, not a repository-quality rating.
corpus:measure verifies the checkout's exact pinned Git SHA, runs the selected adapter at least three times, rejects canonical audit drift, and reports the raw durations, median duration, evidence-link count, and normalized audit digest used to update the scorecard. For the exact Python and Swift pins, --profile-phases defaults to five runs and additionally reports ordered samples and medians for traversal/text reading, project/build ownership, source discovery/indexing, test parsing/indexing, and evidence/classification/artifact assembly. These development timings are callback-only and never enter audit/v1, CLI/MCP audit output, or local MCP diagnostics.
Each adapter performance check separately runs a generated 400-source/200-test project, verifies its candidate and evidence counts, and enforces a broad cross-platform regression ceiling. The Rust gate includes one additional skipped src/lib.rs module-wiring target required to declare the 400 behavioral modules. These synthetic gates complement the recorded per-repository corpus distributions.
Use alpha:check for the adapter-support milestone. release:check additionally covers packaging and installed-binary readiness.
The CI workflow keeps one stable Linux pr-gate: documentation-only changes run focused contract tests, normal changes run npm run alpha:check, and distribution-sensitive changes run npm run release:check. Windows runs only for runtime and portability changes; macOS runs only for Swift-sensitive changes. A merge to master runs the complete release gate on Linux, while manual dispatch runs the full release gate on all three operating systems.
The tests include golden audit and plan snapshots under evals/expected, driven by evals/fixtures.json, plus shared adapter-conformance checks for deterministic JSON, portable paths, evidence semantics, and downstream artifact agreement.
JSON schemas and the signal registry for versioned artifacts live under schemas/.
Refresh snapshots after intentional audit behavior changes:
npm run eval:check
npm run eval:summary
npm run eval:test
npm run eval:updateCheck model-consistency scenario locked fields against deterministic tool results:
npm run model-consistency:check
npm run model-consistency:json
npm run model-consistency:json -- --profile local-small
npm run model-consistency:compare -- baseline-summary.json candidate-summary.json
npm run model-consistency:statsNode 20 or newer is required for the CLI. The default smoke check is portable across platforms:
npm run smokeIf Node is not available yet, the repository still includes a PowerShell smoke check:
powershell -ExecutionPolicy Bypass -File ./scripts/smoke.ps1Check package contents before publishing:
npm run pack:check
npm run bin:check
npm run installed-package:check
npm run distribution:check
npm run release:checkdistribution:check validates packaging and MCP metadata preparation. The stricter distribution:check:publish verifies that the public npm and MCP Registry identities are aligned before a release. See Distribution.
src/
core/
audit-model.ts
audit-phase-timing.js
plan-execution-hints.js
plan-execution-hints.ts
repository-text-files.js
report.js
report.ts
diagnostics/
diagnostics.js
adapters/
csharp/
audit.js
javascript/
audit.js
audit.ts
kotlin/
audit.js
python/
audit.js
rust/
audit.js
swift/
audit.js
cli/
index.js
examples/
csharp-sdk-project-pair/
csharp-sdk-unique-pair/
csharp-sdk-xunit-basic/
node-vitest-basic/
express-supertest/
react-testing-library/
kotlin-junit-basic/
kotlin-gradle-groovy-junit/
kotlin-gradle-module-graph-junit/
kotlin-maven-junit/
kotlin-maven-reactor-junit/
kotlin-maven-wrapper-junit4/
kotlin-gradle-aggregate-kotest/
kotlin-gradle-spock/
kotlin-maven-testng/
python-pytest-service/
python-uv-pytest/
python-poetry-pytest/
rust-cargo-basic/
rust-cargo-workspace-basic/
swift-spm-xctest/
swift-spm-swift-testing/
swift-spm-quick-nimble/
swift-spm-custom-paths/
swift-spm-alternate-roots/
swift-bazel-xctest/
swift-xcode-test-plans/
vapor-service-tests/
vapor-mongodb-boundaries/
evals/
expected/
model-consistency/
schemas/JavaScript/TypeScript, PHP, Python, Ruby, Swift, bounded Kotlin/JVM modules, bounded Go modules, bounded C# SDK project shapes, and bounded Rust Cargo packages are supported adapter proof points. PHP support covers the bounded Composer/PSR-4/PHPUnit ownership, command-withholding, and evidence rules in PHP Alpha Support. Ruby support covers the bounded Bundler/Minitest/RSpec ownership and evidence rules in Ruby Alpha Support. Rust support includes literal repository-contained workspace members, exact package commands, built-in test ownership, literal module graphs, exact test-only module exclusion, direct logical-module imports, inherent associated calls, and exact unconditional crate-root symbol re-exports as defined in Rust Alpha Support. C# support covers one conventional SDK-style test project or one unique literal production/test project edge, including bounded native xUnit MTP-v2 and MSTest.Sdk v4 ownership, exact literal or one-hop root-aliased target membership, one repository-contained direct *.cs compile include, finite target-conditioned package predicates, and a pair amid unrelated projects, with bounded nearest-file build metadata and static central package versions, exact test-project commands, runnable-body-owned direct type calls, bounded concrete-local or immutable test-field receivers, one-hop stable direct-call, receiver-call, or inline out var result assertions, bounded exception assertions, and one same-class private-static test-helper hop while solution ownership remains excluded. Go support includes literal repository-contained go.work members, explicit static build-target selection, bounded standard-library/Testify assertion usage, parser-scoped receiver identity through concrete local and test-helper bindings, and callable-body-owned source evidence as defined in Go Alpha Support. Kotlin/JVM support is limited to conventional Gradle/Maven modules and directly declared aggregate graphs, JUnit, the documented Kotest common-spec and Spock feature variants, or method-level TestNG, and standard source sets as defined in Kotlin/JVM Alpha Support.
Important runtime surfaces:
CLI: src/cli/index.js
MCP tool definitions: src/mcp/tool-definitions.js
stdio MCP SDK server: src/mcp/stdio.js
local invoke harness: src/mcp/invoke.js
release gate: scripts/check-release-readiness.js
Analyze project-aware test placement from a project-audits artifact.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the analysis is 'project-aware' and operates 'from a project-audits artifact', providing some context beyond annotations, but it does not elaborate on the analysis's nature or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Analyze', and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not describe the return value or the nature of the analysis output. It also leaves 'project-aware test placement' undefined. Given the analytical nature of the tool, this is insufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with projectAudits described as 'A project-audits/v1 artifact.' The tool description repeats this by saying 'from a project-audits artifact', adding no further semantic detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'analyze' and identifies the resource as a 'project-audits artifact'. The phrase 'project-aware' clearly distinguishes this tool from the sibling 'analyze_test_placement', which lacks the project-aware qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a project-audits artifact is available, but it does not explicitly state when to prefer this over sibling tools like analyze_test_placement or generate_project_test_plan, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here for an unfamiliar repository or a general test-architecture review. Detect and audit all project roots once, then return the complete deterministic summary, blockers, findings, ranking, plan, execution hints, verification commands, and stats. Prefer this over audit_repo unless one project root and adapter were explicitly selected.
| Name | Required | Description | Default |
|---|---|---|---|
| goTarget | No | ||
| repoRoot | Yes | Repository root path. | |
| changedPaths | No | Optional repository-relative source paths to limit target selection inside detected projects. | |
| excludeProjectRoots | No | Optional exact project roots or subtree patterns such as examples/** to exclude before analysis. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by stating it 'Detect and audit all project roots once, then return the complete deterministic summary...' This communicates the one-time detection scope, deterministic output, and the exact list of return sections. No contradiction with the readOnly/idempotent annotations; it complements them with concrete behavior details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary use case, and dense with useful information. Every phrase earns its place—'Start here', 'Detect and audit all project roots once', the output list, and the alternative preference. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-level orchestration tool with no output schema, the description enumerates all expected outputs (summary, blockers, findings, ranking, plan, execution hints, verification commands, stats) and clarifies the scope. It also provides the decision context relative to audit_repo, making the tool's role complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 75% of parameters with descriptions (repoRoot, changedPaths, excludeProjectRoots, and the nested goTarget properties), so the description is not required to elaborate. The description adds no direct parameter semantics beyond implying the repoRoot and excludeProjectRoots usage, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('analyze') and resource ('repository'), and clearly positions it as the entry point for unfamiliar repositories or general test-architecture review. It explicitly distinguishes itself from the sibling tool audit_repo by prescribing when to prefer each, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage criteria: 'Start here for an unfamiliar repository or a general test-architecture review' and directly advises against using it over audit_repo when one project root and adapter are explicitly selected. This gives clear when-to-use and when-not-to-use guidance, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze existing test placement from an audit graph and return advisory placement findings.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | An audit/v1 artifact. | |
| owner | No | Optional owner label for the audited project. Defaults to audit.profile.root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds that findings are 'advisory,' indicating non-authoritative output. It does not disclose more specific behaviors such as how the audit graph is interpreted or edge cases, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the action and outcome.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required nested object and no output schema, so the description should explain the structure of the audit graph and what 'advisory placement findings' contain. It does neither, and it fails to differentiate from the sibling analyze_project_test_placement, leaving the tool incomplete for an agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds 'audit graph' as a synonym for the audit parameter, but adds no details about the owner parameter or how it affects results. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Analyze'), a target resource ('test placement'), and an input source ('audit graph'), making the core purpose understandable. However, it does not distinguish this tool from the sibling analyze_project_test_placement, which is likely similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from an audit graph' implies the appropriate context: use when an audit graph is available and placement analysis is needed. However, there is no explicit guidance on when to prefer this over the similarly named sibling analyze_project_test_placement, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return raw per-project audit artifacts for all detected supported roots and report unsupported roots. Use when a downstream specialist tool needs project-audits/v1; for a complete first-pass review, prefer analyze_repository.
| Name | Required | Description | Default |
|---|---|---|---|
| goTarget | No | ||
| repoRoot | Yes | Repository root path. | |
| changedPaths | No | Optional repository-relative source paths to limit target selection inside detected projects. | |
| excludeProjectRoots | No | Optional exact project roots or subtree patterns such as examples/** to exclude before auditing detected projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds behavioral context by specifying that the tool returns raw artifacts (not summaries), detects supported roots, and reports unsupported ones. It also implies the output format is project-audits/v1, which is useful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action and output, and every phrase adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, a nested object, and no output schema, the description provides sufficient context for an agent to decide when to invoke it and what to expect (raw artifacts, unsupported roots report). It does not fully detail the return structure, but the explicit output type and purpose make it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema already covers all parameter meanings. The description does not add detail about individual parameters beyond implying repoRoot is the base for detection. The description's reference to 'detected supported roots' adds some context but does not meaningfully enrich parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and a precise resource 'raw per-project audit artifacts', and explicitly scopes to 'all detected supported roots' plus 'report unsupported roots'. It clearly differentiates from sibling tools by noting a preference for analyze_repository for first-pass reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a concrete trigger: 'Use when a downstream specialist tool needs project-audits/v1', and provides an explicit alternative: 'for a complete first-pass review, prefer analyze_repository'. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit one explicitly selected project root and return audit/v1. Use only when the caller selected a single adapter or project boundary; adapterId defaults to javascript. For an unfamiliar or complete repository review, use analyze_repository.
| Name | Required | Description | Default |
|---|---|---|---|
| goTarget | No | ||
| repoRoot | Yes | Repository root path. | |
| adapterId | No | Optional adapter id. Defaults to javascript. | |
| changedPaths | No | Optional repository-relative source paths to limit target selection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: the audit returns a versioned format ('audit/v1'), the adapter defaults to 'javascript', and the tool is strictly scoped to a single project root. These details go beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose and output, followed by a directly relevant usage condition and alternative. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description's mention of 'return audit/v1' provides at least a version hint. It also clarifies scope (single project) and the default adapter. Given the complexity (nested goTarget param, changedPaths), the description covers the key decision points, although it does not detail what audit/v1 contains or error conditions—acceptable since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, so the schema already documents most parameters. The description mentions that adapterId defaults to javascript, but this is already in the schema's adapterId property description. No additional parameter semantics (such as changedPaths or goTarget behavior) are provided by the description, so it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Audit one explicitly selected project root') and a defined output ('return audit/v1'), clearly identifying the scope and distinguishing it from siblings. It explicitly names analyze_repository as the alternative for broader reviews, which differentiates the tool from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('only when the caller selected a single adapter or project boundary') and provides an alternative for other cases ('For an unfamiliar or complete repository review, use analyze_repository'). This gives clear decision-making guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect concise top findings from an existing project-audits/v1 artifact. analyze_repository already includes this result.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the prerequisite 'existing project-audits/v1 artifact' and the nature of output ('concise top findings'), but this is minimal additional behavioral context beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and both are purposeful: the first states the tool's action and input, the second warns about redundancy. There is no wasted verbiage or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers what it does, what it takes in, and its relationship to analyze_repository. It does not detail the output format or differentiate from summarize_project_audits, but overall it is sufficiently complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, and the schema already describes 'projectAudits' as 'A project-audits/v1 artifact.' The description's mention of 'existing' adds slight emphasis but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('collect') and resource ('project-audits/v1 artifact'), and indicates the output ('concise top findings'). It also distinguishes itself from analyze_repository by noting that analyze_repository already includes this result, though it does not differentiate from other similar siblings like summarize_project_audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'analyze_repository already includes this result' provides clear guidance that this tool is redundant if analyze_repository has been used, offering a contextual exclusion. However, it does not explicitly state when to prefer this tool over alternatives like summarize_project_audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collect local deterministic project audit stats for coverage, counts, risk and signal distributions, framework distribution, and adapter usage.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive. The description adds 'local deterministic' which implies consistent output and local-only execution, but provides no further behavioral context such as side-effect limitations or required permissions. This is a modest addition beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence that front-loads the verb and resource, and lists the specific stats areas. No filler words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally clarify what the return value looks like. It lists the categories of stats, which partially indicates the output, but does not specify structure, format, or how the input artifact is used. Given the one-param input and nested object, the description is serviceable but leaves some gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'projectAudits' is fully described in the schema as 'A project-audits/v1 artifact.' The description does not add any further parameter semantics, so it rides on the schema's 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool collects project audit stats and enumerates specific categories (coverage, counts, risk/signal distributions, etc.). This is specific and informative, but it does not explicitly differentiate from sibling tools like summarize_project_audits or collect_project_findings, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only defines what it does, with no mention of prerequisites, workflow position, or exclusions. Sibling tools are present but unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect project roots and matching adapters inside a repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repoRoot | Yes | Repository root path. | |
| excludeProjectRoots | No | Optional exact project roots or subtree patterns such as examples/** to exclude before returning detected projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description does not need to restate that. It adds that adapters are matched to projects, but does not describe output format, error behavior, or whether it follows ignore files. With annotations present, the score is baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with ten words, front-loaded with the key action and object. There is zero filler or redundant content, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not explain what the tool returns (e.g., list of project roots with adapter names). The purpose is clear, but the absence of return-value details and minimal behavioral context leaves gaps, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, including clear definitions for repoRoot and excludeProjectRoots. The description does not add extra parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('detect') and a specific resource ('project roots and matching adapters') within a repository. It distinguishes the tool's main function but does not explicitly contrast it with sibling tools like list_adapters or list_project_detection_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_project_detection_rules or analyze_repository. There are no explicit exclusions, prerequisites, or context for when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain one audit target by stable target id.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | An audit/v1 artifact. | |
| targetId | Yes | Stable audit target id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the 'stable target id' detail, which reinforces idempotency, but it does not describe what 'explain' returns or any other behavioral traits. This is acceptable given annotation coverage, but not additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, and it communicates the essential purpose and scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema and annotations provide useful context, the description remains vague about what 'explain' actually produces, especially since there is no output schema. Given the nested 'audit' parameter and the tool's role among many audit-related siblings, the description is adequate but not complete enough to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 documented. The description adds no new meaning beyond echoing the targetId field's schema text. It is a baseline 3 because the schema carries the parameter-semantics load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (explain) and resource (audit target) and notes the key scoping parameter (stable target id). It is clear enough to convey what the tool does, though it does not explicitly distinguish it from sibling tools beyond the verb choice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It simply states the action without any context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a project-aware plan from an existing project-audits/v1 artifact. analyze_repository already includes this result.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description carries less burden. It adds that the tool is project-aware and that the result is already included in analyze_repository, which is useful context, but it does not describe output behavior or internal processing beyond that. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and input. The second sentence adds a key alternative without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one input, no output schema) and rich annotations, the description covers the essential purpose and usage context. It could be improved by explaining what a 'project-aware plan' contains, but the mention of the artifact and the alternative make it adequately complete for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (projectAudits), so the schema already explains it. The description rephrases the same idea ('from an existing project-audits/v1 artifact') without adding new details like validation rules or expected structure, matching the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('project-aware plan'), and clearly specifies the input ('existing project-audits/v1 artifact'). It also distinguishes from a sibling by noting that analyze_repository already includes this result, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you have an existing project-audits/v1 artifact. The mention that analyze_repository already includes this result implicitly warns against redundant use, though it does not explicitly compare with other siblings like generate_test_plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a structured deferred result. This tool does not generate or write test code while native generation remains disabled.
| Name | Required | Description | Default |
|---|---|---|---|
| planItemId | Yes | Stable plan item id selected for future generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns a deferred result and does not perform actual code generation, providing context beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and immediately clarifying what it does not do. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output schema, the description adequately covers the tool's behavior: it defers generation. It could specify what the structured deferred result contains, but that is somewhat outside the description's minimal scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter, planItemId, already well-described as a stable plan item id. The description adds no extra parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a structured deferred result and explicitly says it does not generate or write test code. It distinguishes itself from sibling generation tools by noting native generation is disabled, though the term 'deferred result' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for use when native generation is disabled, but does not explicitly state when to use this tool versus alternatives like generate_test_plan. No direct comparison or conditional guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a deterministic test plan from an audit graph.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | An audit/v1 artifact. | |
| itemId | No | Optional stable plan item id to select. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds the behavioral trait 'deterministic' and specifies the input source ('from an audit graph'), which is useful context. However, it does not go beyond that to describe any other behavioral nuances, so the additional value is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence. It is front-loaded with the primary action and includes the key qualifier 'deterministic' without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description bears the burden of explaining return values. The description does not mention what the generated test plan looks like or how the optional itemId parameter affects the result. It also lacks usage context. This is adequate for a simple read-only tool but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters (audit and itemId) have descriptions in the schema. The tool description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a deterministic test plan from an audit graph. It names a specific verb, resource, and source, making it easy to understand. However, it does not distinguish this tool from the sibling generate_project_test_plan, which appears to be a related alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like generate_project_test_plan or generate_selected_test. The description only states what the tool does, not the context in which it should be chosen, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate and return an existing audit/v1 artifact unchanged; this does not scan a repository. Use audit_repo or analyze_repository for repository discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | An audit/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe/read-only. The description adds valuable context beyond this: the artifact is returned 'unchanged' and that the tool performs no repository scanning, which clarifies its non-side-effect behavior and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, followed by a clear exclusion/alternative. Every word earns its place; no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with rich annotations, the description covers purpose, usage boundary, and behavior. No output schema exists, but saying the artifact is returned unchanged is sufficient. Sibling context confirms differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'audit' parameter is described as 'An audit/v1 artifact.'). The description repeats 'audit/v1 artifact' and adds 'existing' but doesn't meaningfully extend the parameter semantics beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Validate and return an existing audit/v1 artifact unchanged.' It uses a specific verb ('validate and return') and resource ('audit/v1 artifact'), and explicitly distinguishes from siblings by noting it does not scan a repository, unlike audit_repo or analyze_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use audit_repo or analyze_repository for repository discovery.' This tells the agent when not to use this tool and names the alternatives, making usage boundaries clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive provider-neutral execution, context, parallel-safety, and repository-reasoning hints from a plan without invoking models or subagents.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | A plan/v1 or project-test-plan/v1 artifact. | |
| itemId | No | Optional stable plan item or project item id to select. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by disclosing that it does not invoke models or subagents, and that hints are provider-neutral and include repository-reasoning—useful behavioral context beyond the structured safety flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'Derive' and packs all essential information—purpose, inputs, outputs, and behavioral constraints—without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and no output schema, the description communicates the core purpose and the categories of hints returned. It omits details about the result structure or how itemId affects behavior, but the schema covers the parameters, and the description is sufficient for an agent to select and invoke the tool correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters: 'plan' is described as a plan/v1 or project-test-plan/v1 artifact, and 'itemId' as an optional stable id. The description does not add any parameter-specific guidance beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'derive' and clearly states the resource ('a plan') and the outputs (execution, context, parallel-safety, repository-reasoning hints). It distinguishes from sibling tools by emphasizing 'provider-neutral' and 'without invoking models or subagents', which are unique attributes not present in most other tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: when you have a plan and need hints without additional model or subagent calls. It provides a practical differentiator ('without invoking models or subagents'), suggesting when this lighter-weight analysis is appropriate, though it does not explicitly name alternatives or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List registered language adapters available to audit repositories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety semantics. The description adds domain-specific context ('registered language adapters' for auditing), which goes beyond what annotations provide, though it does not detail return format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence that conveys the core functionality without any wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list tool with comprehensive annotations and no output schema, the description fully captures what the tool does and why it exists. No additional details are necessary for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema fully documents the input. The description adds no parameter-specific detail, but the baseline for zero-parameter tools is 4 since there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('registered language adapters') with clear scope ('available to audit repositories'). It clearly distinguishes itself from sibling tools that focus on project detection and audit rather than adapter listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (before auditing repositories) but does not explicitly state when to use this tool over alternatives or mention any exclusions. It provides clear context without explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deterministic project marker rules and ignored directories used during project detection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a meaningful behavioral detail: the rules are 'deterministic' and include 'ignored directories,' giving context about the content and nature of the listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It immediately states the action and the object, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the trivial complexity (zero parameters, no output schema), the description adequately covers what the tool returns: rules and ignored directories. However, it could elaborate on the shape of a 'rule' or the format of the returned list, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing to explain. The description focuses on the output content, which is appropriate; since there are no parameters, no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and identifies the exact resource: 'deterministic project marker rules and ignored directories used during project detection.' This clearly differentiates it from sibling tools like detect_projects and audit_projects by focusing on the configuration underlying detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool instead of alternatives. The phrase 'used during project detection' implies it is useful for inspecting detection configuration, but there are no conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank candidates from an existing project-audits/v1 artifact while preserving project identity. analyze_repository already includes this result.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, lowering the burden. The description adds behavioral context by specifying that it operates on an existing artifact and 'preserving project identity,' which explains how the operation is scoped. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes a valuable note about analyze_repository. Every word earns its place with no fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter input, no output schema, and strong annotations, the description is mostly complete. It tells the agent what the tool does, what input it needs, and a key relationship to analyze_repository. The only gap is that it does not explicitly describe the output format, but the name and purpose imply a ranked result, and the mention of analyze_repository provides context for where this fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the sole parameter is described as 'A project-audits/v1 artifact.'), so baseline is 3. The description adds value by explicitly stating that the tool ranks candidates 'from' this artifact, clarifying the parameter's role in the operation beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Rank candidates from an existing project-audits/v1 artifact' with a specific verb and resource. It distinguishes itself from sibling tools by specifying the input artifact and noting that analyze_repository already includes this result, which differentiates it from similar ranking tools like rank_test_candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-not-to-use signal: 'analyze_repository already includes this result.' This implicitly tells the agent that if they have called analyze_repository, this tool may be redundant. It does not explicitly list alternatives, but the context implies this tool is for when you have an existing artifact and need ranking without re-analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank testable audit targets by risk reduction and maintenance cost.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | An audit/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds meaningful context by specifying the ranking criteria (risk reduction and maintenance cost), which goes beyond what annotations convey. It does not contradict any annotation, and there are no hidden side effects implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and resource. It contains no filler, repetition, or unnecessary details. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description should convey what the result looks like. It states that ranking is done, but does not specify the output format (e.g., sorted list, scores attached, ordering direction). This leaves some ambiguity about the return value for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'audit' parameter as 'An audit/v1 artifact' with 100% coverage. The description refers to 'testable audit targets' but does not add any new semantics for the parameter itself, such as format requirements or how the audit should be structured. Baseline of 3 is appropriate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rank), the resource (testable audit targets), and the specific criteria (risk reduction and maintenance cost). This distinguishes it from the sibling tool rank_project_candidates, which ranks projects rather than test candidates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when you have an audit artifact and want to rank test candidates, use this. It does not explicitly list exclusions or mention alternatives like rank_project_candidates, but the scope is evident from the wording. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize an existing project-audits/v1 artifact. Use only when a compact coverage view is needed separately; analyze_repository already includes this result.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | A project-audits/v1 artifact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about the 'compact coverage view' and the separate use case, but does not describe additional behavioral details like return format or edge cases. This is adequate but not extraordinary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first conveying the core purpose and the second providing usage guidance. It is front-loaded and every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and relatively simple functionality, the description is mostly complete. It clearly states the operation and usage context. However, the phrase 'compact coverage view' is somewhat ambiguous and the description does not hint at what the summary includes, which could be clearer. Still, for a tool with strong annotation support, the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter, and its description ('A project-audits/v1 artifact') is minimal. The tool description adds that the artifact is 'existing' and the purpose is summarization, but it does not elaborate on the artifact's structure or how to obtain it. With full schema coverage, this meets the baseline for parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Summarize') and the specific resource ('an existing project-audits/v1 artifact'). It also distinguishes this tool from the sibling 'analyze_repository' by noting that the latter already includes the same result, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use only when a compact coverage view is needed separately' and points to the alternative 'analyze_repository already includes this result.' This provides clear when-to-use and when-not-to-use guidance, directly comparing to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_project_test_placementanalyze_repositoryanalyze_test_placementaudit_projectsaudit_repocollect_project_findingscollect_project_statsdetect_projectsexplain_targetgenerate_project_test_plangenerate_selected_testgenerate_test_planget_audit_graphget_plan_execution_hintslist_adapterslist_project_detection_rulesrank_project_candidatesrank_test_candidatessummarize_project_auditsMost tools have clearly distinct purposes, and descriptions explicitly guide when to use which (e.g., analyze_repository vs audit_repo vs audit_projects). Some overlap exists among tools that operate on the same project-audits/v1 artifact, but their scopes and usage notes are clearly differentiated.
Tool names generally follow a verb_noun pattern with underscores (e.g., list_adapters, detect_projects, generate_test_plan). Minor deviations include using 'repo' instead of 'repository' (audit_repo vs analyze_repository) and inconsistency between 'project_test_plan' and 'test_plan', but the overall pattern is predictable.
The server has 19 tools, which falls in the borderline heavy range. While each tool has a specific role, many are specialized subsets of the umbrella analyze_repository tool, making the count feel slightly inflated for the core purpose.
The tool set covers the major steps of repository analysis: detection, audit, summarization, ranking, planning, placement analysis, and execution hints. However, generate_selected_test is a deferred stub that does not actually generate test code, and there is no tool to modify detection rules or adapters, leaving some gaps in the full lifecycle.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RepoAssay/repo-test-architect'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
