Use this MCP server for deterministic, audit-first test strategy analysis across local repositories without generating or writing tests.
Run a full repository review: detect project roots, audit supported ecosystems, and return summary, blockers, findings, rankings, plan, execution hints, verification commands, and stats.
Audit specific projects/adapters to get raw audit/v1 artifacts, or detect projects and list adapters/detection rules without auditing.
Derive downstream artifacts from existing audits: project summaries, candidate rankings, test plans, findings, placement advice, and stats.
Inspect results: validate/return audit graphs, explain individual targets, and get plan execution hints.
Query deferred test generation to receive a structured “not yet implemented” response (no test code is ever written).
Operate read-only and idempotently against local repository data; no model selection, subagent spawning, or external reporting.
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 is available on npm as latest and in the Official MCP Registry, with stable support for the documented CLI, MCP tools, configuration and versioned artifact contracts. Treat its findings as evidence-backed review input rather than an automatic instruction to change a repository. See the 1.0.0 release notes for changes, compatibility and publication status.
Ten adapters are supported within their documented boundaries. Dart/Flutter remains experimental, and native test generation remains deferred.
Maintenance is provided as time permits, with no guaranteed response time or feature schedule. Focused community PRs are welcome; see Contributing and Support.
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 .Pin the stable version:
npx --yes repo-test-architect@1.0.0 doctor
npx --yes repo-test-architect@1.0.0 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 keep an MCP client on this exact release, pin its version:
{
"mcpServers": {
"repo-test-architect": {
"command": "npx",
"args": [
"--yes",
"repo-test-architect@1.0.0",
"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:
dart (experimental): Dart and Flutter pubspec packages, conventional package:test and flutter_test entrypoints, exact library-import evidence, widget test recommendations, and bounded dart test / flutter test commands; see Dart and Flutter support
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. The 33 current pins span ten supported adapters and experimental Dart, with all 231 bounded scorecard areas passing. Dart live validation also records native upstream suite results and remaining limits. 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
Derive advisory test-placement findings across an existing project-audits/v1 artifact while preserving project identity. Use this for multiple audited projects; use analyze_test_placement for one audit/v1 artifact. Does not rescan the repository, execute tests, or create, move, or modify files.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | The project-audits/v1 object returned by audit_projects; pass the artifact itself, not a file path. |
| Name | Required | Description |
|---|---|---|
| findings | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds useful context beyond that: findings are 'advisory', the repository is not rescanned, and no files are created, moved, or modified — meaningful scope limits for an agent gauging side effects and cost.
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?
Three tight sentences: purpose/scope first, sibling routing second, negative constraints last. No filler, and the most important routing information is front-loaded.
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?
With an output schema present, return values need no explanation. The description covers what the tool consumes (an existing artifact, not the repo), what it produces (advisory findings), and what it refuses to do, which is complete for a 1-parameter read-only analysis 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?
Schema coverage is 100% and the single parameter's description already explains it must be the project-audits/v1 object from audit_projects, not a file path. The tool description adds nothing about the parameter, so the schema carries the load and 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?
States a specific verb (derive), resource (advisory test-placement findings), and input scope (across an existing project-audits/v1 artifact). It explicitly contrasts with the sibling analyze_test_placement, so an agent can distinguish it without opening either schema.
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 routing rule: 'Use this for multiple audited projects; use analyze_test_placement for one audit/v1 artifact.' It also states what it does not do (no rescan, no test execution, no file mutation), giving clear boundaries.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| stats | Yes | |
| summary | Yes | |
| findings | Yes | |
| testPlan | Yes | |
| auditSummary | Yes | |
| projectAudits | Yes | |
| schemaVersion | Yes | |
| executionHints | Yes | |
| candidateRanking | Yes | |
| verificationCommands | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, idempotentHint=true, non-destructive), so the description rightly does not repeat that. It adds the operational fact that project roots are detected 'once' and that the return is a deterministic summary across several named artifact classes (blockers, findings, ranking, plan, etc.). It does not disclose performance limits or failure behavior for unreadable roots.
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?
Three tight sentences: entry condition first, then scope and return contents, then the sibling routing rule. Every clause carries information; there is no 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?
An output schema exists, so the description need not enumerate return fields in full; naming the artifact classes is sufficient. With annotations covering the safety profile, four parameters, and a 75%-documented schema, the description is complete enough for an agent to select and invoke this tool 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 75% and the nested goTarget object is self-documenting, so the baseline is 3. The description adds no parameter-specific syntax or constraint details beyond what the schema already carries; its only parameter-adjacent signal is the audit_repo contrast, which implies single-root vs multi-root selection but does not explain repoRoot, changedPaths, or excludeProjectRoots.
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 ('Detect and audit') over a specific resource ('all project roots'), and explicitly distinguishes itself from a sibling: 'Prefer this over audit_repo unless one project root and adapter were explicitly selected.' This lets an agent route correctly without opening the other schema.
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?
It opens with 'Start here for an unfamiliar repository or a general test-architecture review,' which is an explicit entry-point signal, and names the condition under which audit_repo is preferred. Both the when and the when-not are specified, along with the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Derive advisory test-placement findings from an existing single-project audit/v1 artifact. Use this for one audited project; use analyze_project_test_placement for a project-audits/v1 artifact. Does not rescan the repository, execute tests, or create, move, or modify files.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path. | |
| owner | No | Optional owner label for the audited project. Defaults to audit.profile.root. |
| Name | Required | Description |
|---|---|---|
| findings | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds meaningful context beyond that: it does not rescan the repository, execute tests, or modify files, and its findings are advisory. This tells the agent it is a pure derivation step rather than an execution step; richer detail on output shape is unnecessary since an output schema exists.
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?
Three short sentences, each earning its place: the action, the alternative-sibling routing rule, and the non-mutation boundary. The core purpose is front-loaded with no 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 read-only derivation tool with a full output schema and complete annotation coverage, the description supplies everything needed: the required artifact form, the sibling disambiguation, and the explicit guarantee that no rescanning or file mutation occurs.
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%, with the schema already explaining that the audit object is the artifact itself (not a path) and defining the optional owner default. The description reinforces the artifact type but adds no syntax or format detail beyond the schema, so the 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?
States a specific verb+resource ('Derive advisory test-placement findings') and names the exact input artifact type (audit/v1). It also explicitly contrasts itself with the sibling analyze_project_test_placement, so an agent can disambiguate without opening either schema.
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?
Gives explicit when-to-use ('for one audited project') and names the alternative that applies to a different artifact type ('project-audits/v1 artifact'). The conditions selecting one tool over the other are unambiguous.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| audits | Yes | |
| summary | Yes | |
| schemaVersion | Yes | |
| skippedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description still adds the artifact contract name (project-audits/v1) and the behavior of reporting unsupported roots, which is useful context beyond the 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?
Two sentences, zero filler, with the primary purpose front-loaded and the alternative routing placed second. Every clause 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?
An output schema exists, so return-value documentation is not required, and the description still names the artifact version and the unsupported-root reporting behavior. It is nearly complete for a 4-parameter tool, with only minor gaps in how output is surfaced.
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?
At 75% schema description coverage with nested objects (goTarget), the schema largely documents its own parameters. The description adds no parameter-level detail such as how changedPaths interacts with target selection or how excludeProjectRoots patterns are matched, so it does not exceed the schema baseline.
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?
States a specific verb and resource ('Return raw per-project audit artifacts') plus a scope ('all detected supported roots') and a side output ('report unsupported roots'). It also implicitly separates itself from summarize_project_audits and analyze_repository by claiming raw artifacts rather than a reviewed summary.
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?
Gives an explicit use condition ('when a downstream specialist tool needs project-audits/v1') and names the alternative for the other case ('for a complete first-pass review, prefer analyze_repository'). Nothing is left to inference.
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. |
| Name | Required | Description |
|---|---|---|
| risks | Yes | |
| profile | Yes | |
| skipped | Yes | |
| recommended | Yes | |
| schemaVersion | Yes | |
| coveredButRisky | Yes | |
| untestedCandidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is handled. The description adds real context beyond that: the audit/v1 return format, the single-project-boundary scope, and the adapterId javascript default. It does not discuss limits of what gets audited, but the added facts are substantive.
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?
Three short sentences with zero filler, and the scope constraint plus output format are front-loaded before the sibling routing clause. Every sentence 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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile; the description handles tool selection and the key default. It is nearly complete, with only parameter-level guidance for changedPaths/goTarget left implicit in the schema.
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 75%, so the schema documents most parameters itself. The description reinforces repoRoot scoping ('one explicitly selected project root') and repeats the adapterId javascript default that the schema already states; changedPaths and goTarget are left entirely to the schema, so no meaning is added beyond it.
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?
States a specific verb and resource ('Audit one explicitly selected project root'), plus the output contract ('return audit/v1'). It explicitly contrasts with the sibling analyze_repository, so an agent can separate the two without opening any schema.
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?
'Use only when the caller selected a single adapter or project boundary' gives an explicit precondition, and 'For an unfamiliar or complete repository review, use analyze_repository' names the alternative and the condition that selects it. Both when-to-use and when-not-to-use are present.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| summary | Yes | |
| findings | Yes | |
| schemaVersion | Yes | |
| unsupportedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only that the operation is a pure transform over an existing artifact, which is mildly useful but not behavioral depth beyond the annotations; no mention of size limits, cost, or failure modes.
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 short sentences with zero padding; the primary purpose is front-loaded and the sibling caveat follows immediately. Every sentence 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?
With a rich annotation set, full schema coverage, and an output schema covering return values, the description supplies what remains: what it consumes and its relation to analyze_repository. Only the concrete nature of the returned findings is unspecified, which is a minor 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?
Schema description coverage is 100% with a single documented parameter, so the schema already carries the semantics. The description restates the artifact identity but adds no format, versioning, or shape guidance 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?
States a specific verb+resource ('Collect concise top findings') and names the exact input artifact type (project-audits/v1), which tells an agent what it operates on. It also names the sibling analyze_repository as an overlapping alternative. Slightly ambiguous what 'findings' concretely means, keeping it below 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?
The clause 'analyze_repository already includes this result' gives an implicit when-not-to-use signal, steering agents away from redundant calls. However, it never states when this tool IS the right choice (e.g., when you already hold an audit artifact and want the digest without re-analyzing), nor names other siblings 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.
Aggregate coverage, counts, risk and signal distributions, frameworks, and adapter usage from an existing project-audits/v1 artifact. Use this for separate reporting or comparisons; analyze_repository already includes the same stats. Returns project-stats/v1 without rescanning the repository, executing tests, or writing files.
| Name | Required | Description | Default |
|---|---|---|---|
| projectAudits | Yes | The project-audits/v1 object returned by audit_projects; pass the artifact itself, not a file path. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| counts | Yes | |
| summary | Yes | |
| adapters | Yes | |
| sourceFiles | Yes | |
| distributions | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description still adds real behavioral value by stating the tool does NOT rescan the repository, execute tests, or write files, and that it returns project-stats/v1, which clarifies cost profile and side-effect surface beyond the 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?
Three compact sentences, each earning its place: purpose/inputs, usage routing, and behavioral guarantees. Front-loaded with the core action and free of 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?
With an output schema present, return values need no elaboration, yet the description still names the output type (project-stats/v1). Source artifact, usage context, and non-side-effect guarantees are all covered, leaving no gap an agent needs to call 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?
Only one parameter with 100% schema description coverage, so the schema already documents that it takes the project-audits/v1 object rather than a file path. The description's mention of 'existing project-audits/v1 artifact' adds no syntax or format detail beyond the schema, so 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?
States a specific verb (aggregate) plus the resource and exact field set (coverage, counts, risk/signal distributions, frameworks, adapter usage) sourced from a project-audits/v1 artifact. It clearly distinguishes itself from sibling analyze_repository and audit_projects by naming the source artifact type.
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?
Explicitly says when to use it ('separate reporting or comparisons') and names the overlapping alternative ('analyze_repository already includes the same stats'), giving the agent a routing decision rule. This is the exact when/when-not/alternative structure the top score requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover project roots, support status, and matching adapters without auditing source targets. Use this when project boundaries are needed before a specialized workflow; use analyze_repository for a complete review. Reads local repository markers and returns project-detection/v1 without executing tests or writing files.
| Name | Required | Description | Default |
|---|---|---|---|
| repoRoot | Yes | Readable repository directory whose project markers should be inspected. | |
| excludeProjectRoots | No | Optional exact project roots or subtree patterns such as examples/** to exclude before returning detected projects. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| summary | Yes | |
| projects | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: it reads local repository markers, returns a versioned shape (project-detection/v1), and explicitly does not execute tests or write files. It stops short of describing exclusion semantics or output granularity, so not a 5.
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?
Three sentences, front-loaded with the core capability, then the usage routing, then behavioral limits. No filler and every clause carries 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?
An output schema exists, so return values need not be explained, and the description still names the result shape. Combined with full schema coverage and rich annotations, the only minor gap is exclusion-pattern behavior, which is left to the parameter schema.
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 repoRoot and excludeProjectRoots are already documented with examples (e.g. 'examples/**'). The description adds nothing beyond what the schema provides, so the 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 opens with a specific verb and resource set ('Discover project roots, support status, and matching adapters') and immediately scopes it against auditing ('without auditing source targets'). An agent can distinguish this detection tool from analyze_repository or audit_projects without opening any schema.
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?
It states exactly when to reach for it ('when project boundaries are needed before a specialized workflow') and names the alternative for a different need ('use analyze_repository for a complete review'). The routing condition and the alternative are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the evidence, risk, testability, and recommendation for one target in an existing audit/v1 artifact. Use this after audit_repo or audit_projects when one target needs detail beyond the audit summary. Returns target-explanation/v1 without rescanning the repository, executing tests, or writing files.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path. | |
| targetId | Yes | Exact stable id from an audit target in untestedCandidates, coveredButRisky, recommended, or skipped. |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| path | Yes | |
| risk | Yes | |
| target | Yes | |
| signals | Yes | |
| category | Yes | |
| targetId | Yes | |
| rationale | Yes | |
| testLevel | Yes | |
| testability | Yes | |
| schemaVersion | Yes | |
| recommendation | Yes | |
| maintenanceCost | Yes | |
| existingTestPaths | Yes | |
| riskReductionScore | Yes | |
| existingTestEvidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds real value by stating it does not rescan the repository, execute tests, or write files, and by naming the returned artifact type (target-explanation/v1).
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?
Three tight sentences: purpose, usage condition, and behavioral constraints/return type, with the core purpose front-loaded and no 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?
Given an output schema exists and annotations cover the safety profile, the description supplies everything else an agent needs: prerequisites, scope, side-effect exclusions, and the return artifact type.
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% and both parameters are thoroughly documented there, so the baseline is 3. The description reinforces that the audit is an existing artifact and that only one target is explained, but adds no syntax or format detail 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?
States a specific verb and resource - explaining evidence, risk, testability and recommendation for one target in an existing audit/v1 artifact - and differentiates itself from siblings by positioning against audit summaries.
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?
Explicitly names the prerequisite tools (audit_repo, audit_projects) and the condition that selects this tool: when one target needs detail beyond the audit summary. No explicit when-not or sibling exclusions such as summarize_project_audits, so it stops just short of a full 5.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| items | Yes | |
| summary | Yes | |
| projectPlans | Yes | |
| schemaVersion | Yes | |
| unsupportedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the input-provenance constraint (must come from an existing artifact), which is useful, but says nothing about determinism, cost, or the scale/size of the generated plan.
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 short sentences with zero filler; the output-first framing is front-loaded and the caveat about analyze_repository is appended afterwards.
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?
An output schema exists, so return values need no explanation, and annotations cover safety and idempotency. The only real gap is that 'project-aware plan' is not defined and the tool's relationship to the sibling generate_test_plan is left unstated.
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% and the single parameter's description already identifies it as a project-audits/v1 artifact, so the schema carries the semantics. The description restates the same artifact type without adding format, shape, or validation detail.
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?
States a specific verb (generate) and a specific resource (project-aware plan) and names the required input artifact type, project-audits/v1. It is clear what the tool produces, though it doesn't explicitly distinguish itself from the sibling generate_test_plan.
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 note that 'analyze_repository already includes this result' tells the agent when this tool is redundant and implicitly routes it to analyze_repository for combined flows. It stops short of an explicit when/when-not rule or naming an alternative tool by name.
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. |
| Name | Required | Description |
|---|---|---|
| reason | Yes | |
| status | Yes | |
| nextSteps | Yes | |
| planItemId | Yes | |
| schemaVersion | Yes |
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 important non-obvious behavior: the tool returns a deferred result and performs no test code writing or generation, which prevents the agent from expecting a normal generation effect.
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 short sentences, front-loaded with the purpose and followed by a crucial clarification. There is no redundant or filler content, making it appropriately sized for a simple one-parameter tool.
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 one-parameter schema, its 100% description coverage, and the existing output schema, the description supplies the key missing context—that the tool is a deferred stub while generation is disabled. Minor potential gaps (e.g., what triggers re-enablement) are outside the tool's immediate contract.
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%, and the single parameter planItemId is fully documented in the schema as 'Stable plan item id selected for future generation.' The description adds no parameter-level detail, so the baseline of 3 applies for 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 states a specific outcome ('Return a structured deferred result') and explicitly contrasts it with generation ('does not generate or write test code'), which helps an agent understand the tool despite its generation-suggesting name. However, it does not name any sibling tool or further differentiate from the many generation/planning siblings.
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 clause 'while native generation remains disabled' gives an implied condition for use, but there is no explicit guidance on when to choose this tool over alternatives like generate_test_plan or generate_project_test_plan. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deterministic plan/v1 from an existing single-project audit/v1 artifact. Use this after audit_repo, optionally selecting one exact plan item; use generate_project_test_plan for multiple audited projects. Does not rescan the repository, execute tests, or generate or write test code.
| Name | Required | Description | Default |
|---|---|---|---|
| audit | Yes | The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path. | |
| itemId | No | Optional exact plan item id to return; omit it to return the complete deterministic plan. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| summary | Yes | |
| blockers | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so safety is covered structurally. The description adds genuinely useful negative scope: it does not rescan the repository, does not execute tests, and does not generate or write test code. It could go further on what 'deterministic' guarantees or on failure if the audit is invalid, but the boundary-setting is strong.
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?
Three tight sentences: purpose first, then prerequisites and disambiguation, then explicit non-capabilities. Every sentence carries load and nothing is padded.
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?
With an output schema present, return values need no explanation, and the description covers source artifact, sequencing, alternative, and exclusions. For a read-only two-parameter tool with fully covered schema, this is 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 coverage is 100%, and the schema already documents both 'audit' (pass the object, not a path) and 'itemId' (exact plan item, omit for full plan). The description only echoes the itemId behavior ('optionally selecting one exact plan item') without adding syntax, format, or id-source detail beyond the schema, so the 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?
States a specific verb and resource ('Create a deterministic plan/v1') plus the exact source artifact type ('existing single-project audit/v1 artifact'). It explicitly names the multi-project sibling generate_project_test_plan, so an agent can distinguish the two without opening either schema.
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?
'Use this after audit_repo, optionally selecting one exact plan item' gives the prerequisite and the optional narrowing condition, and 'use generate_project_test_plan for multiple audited projects' states the exclusion and alternative. Nothing is left to inference.
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. |
| Name | Required | Description |
|---|---|---|
| risks | Yes | |
| profile | Yes | |
| skipped | Yes | |
| recommended | Yes | |
| schemaVersion | Yes | |
| coveredButRisky | Yes | |
| untestedCandidates | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds real value beyond them: 'return unchanged' discloses passthrough/no-mutation semantics, and 'does not scan a repository' rules out a costly side effect an agent might otherwise assume. It does not mention error behavior for invalid artifacts, keeping it short of a 5.
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?
One sentence plus one routing sentence, zero waste, with the core behavior front-loaded before the alternatives.
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?
With an output schema present, annotations covering safety, and a fully documented single parameter, nothing an agent needs in order to call this correctly is missing. The negative-scope statement closes the main ambiguity against its siblings.
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% and the single 'audit' parameter is documented as an audit/v1 artifact, so the description's 'audit/v1 artifact unchanged' adds only marginal framing beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
States a specific verb pair (validate and return) and a specific resource (an audit/v1 artifact), and explicitly disambiguates from the sibling repository-discovery tools. An agent can distinguish it from audit_repo/analyze_repository without opening any schema.
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?
Explicitly states what this tool is NOT for ('this does not scan a repository') and names the two alternatives to use instead. The when-not and the alternative routing are both spelled out.
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. |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| source | Yes | |
| summary | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world. The description adds a meaningful behavioral constraint: it runs without invoking models or subagents, which tells the agent there is no LLM cost or non-determinism involved. It still doesn't cover auth requirements or rate limits, but that's a minor gap.
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?
A single, dense sentence front-loads the verb and the output categories, then immediately adds the key constraint. No filler or 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?
The tool has an output schema and full annotation coverage, so the description needn't explain return values or safety. It adequately covers input expectations and the no-model constraint. Slightly lacking in guidance on itemId or prerequisites, but still complete enough for correct invocation.
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 descriptions for both `plan` and `itemId`, so the schema carries the parameter semantics. The description only implies the `plan` input and adds no format, syntax, or selection details beyond what the schema provides. 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?
States a specific verb ('derive') and resource ('hints'), and scopes them to a plan and to a no-model/no-subagent computation. It does not name a sibling alternative, but it clearly differentiates itself from model-invoking tools in the same family.
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 you use this when you have a plan artifact and want hints without incurring model calls, but it never states when to prefer this over siblings like generate_test_plan or explain_target, nor does it list prerequisites or exclusions. Usage is left to inference.
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 | |||
| Name | Required | Description |
|---|---|---|
| adapters | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is well covered. The description adds only modest context by clarifying that the adapters are language adapters registered for auditing repositories; it does not discuss auth needs, rate limits, or output behavior beyond what the output schema and 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 definition is a single front-loaded sentence with no wasted words. It states the action and resource immediately and stays appropriately sized for a zero-parameter listing tool.
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, rich annotations, and the presence of an output schema, the description is nearly complete: it explains what is being listed and the audit-related context. A slightly fuller definition could have added usage routing against sibling tools, but nothing essential is missing for correct invocation.
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?
This tool has zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain parameter meanings, and the empty schema is consistent with the described listing purpose.
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') and adds the scoping phrase 'available to audit repositories.' It clearly conveys what the tool returns, though it does not explicitly differentiate itself from nearby listing tools such as 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?
The description provides no guidance on when to use this tool versus alternatives. The phrase 'available to audit repositories' hints at an audit-related context, but it does not state prerequisites, when-not conditions, or which sibling tool to prefer.
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 | |||
| Name | Required | Description |
|---|---|---|
| markers | Yes | |
| fallbackRules | No | |
| schemaVersion | Yes | |
| ignoredDirectories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds context that the listed rules are deterministic and related to project detection, but does not disclose further behavioral traits beyond what 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 a single, front-loaded sentence with no wasted words. It states the tool's scope immediately and clearly.
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 zero-parameter, read-only list tool with rich annotations and an output schema, the description adequately conveys what is returned. The only minor gap is the absence of usage context relative to sibling tools.
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?
There are zero parameters, so the schema baseline applies. The description does not need to describe parameter semantics, and no additional parameter information is required for this tool.
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 names a specific verb ('List') and precise resources ('deterministic project marker rules and ignored directories used during project detection'). It clearly distinguishes this tool's output from sibling tools like detect_projects or list_adapters.
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 gives no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. It only states what is listed, leaving usage context entirely implicit.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| summary | Yes | |
| candidates | Yes | |
| schemaVersion | Yes | |
| unsupportedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that it operates on an existing artifact and preserves project identity, which is a useful trait, but says nothing about what ranking means or how ties/ordering are handled.
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 short sentences, front-loaded with the core action, no redundant filler. It is slightly terse on the substantive behavior, but every sentence 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?
An output schema exists, so return values need not be explained, and the read-only annotations cover the safety dimension. The description is adequate for a single-artifact read tool, though what 'candidates' and 'rank' concretely mean is left implicit.
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?
Only one parameter with 100% schema description coverage, so the schema does the documenting. The description adds no format or structure detail about the projectAudits artifact beyond the schema, giving a baseline 3.
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?
States a specific verb (rank) and resource (candidates from a project-audits/v1 artifact), and notes the identity-preservation scope. It does not fully disambiguate from the sibling rank_test_candidates, so it falls short of 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?
Explicitly tells the agent that analyze_repository already includes this result, which is an actionable when-not-to-use signal. However it doesn't state the positive condition under which calling this standalone tool is preferred, so it isn't a full 5.
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. |
| Name | Required | Description |
|---|---|---|
| summary | Yes | |
| blockers | Yes | |
| candidates | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds the ranking criteria (risk reduction, maintenance cost), which is useful behavioral context beyond annotations, but does not disclose output format, required audit structure, or other operational 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?
A single, front-loaded sentence with no wasted words. It directly conveys the tool's core action and ranking basis.
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?
With annotations covering safety, a 100%-covered input schema, and an output schema that explains return values, the description is nearly complete for this tool. The only gap is the absence of usage guidance relative to siblings like rank_project_candidates.
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 single parameter 'audit' is fully documented in the schema. The description adds no parameter-specific information, which is acceptable given the high coverage baseline.
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?
States a specific verb ('Rank') and resource ('testable audit targets') with ranking criteria ('risk reduction and maintenance cost'). Implicitly distinguishes from rank_project_candidates by focusing on audit targets rather than project candidates, but does not name the sibling explicitly.
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 states what it does, not when it is appropriate or what prerequisites exist, leaving the agent to infer from context.
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. |
| Name | Required | Description |
|---|---|---|
| root | Yes | |
| summary | Yes | |
| projects | Yes | |
| schemaVersion | Yes | |
| unsupportedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds that it consumes an existing artifact and returns a compact coverage view, but says nothing about cost, failure modes for malformed artifacts, or output shape.
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 short sentences, zero filler, with the purpose stated first and the routing caveat second. Every clause 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?
An output schema exists, so return values need not be described, and the single parameter is documented in the schema. For a read-only derived-view tool, nothing an agent needs to call it correctly is missing.
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% and there is a single nested-object parameter, so the baseline is 3. The phrase 'existing project-audits/v1 artifact' reinforces that the input must already exist but adds no syntax or format detail 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?
States a specific verb (summarize) and resource (an existing project-audits/v1 artifact), and explicitly distinguishes itself from the sibling analyze_repository. An agent can tell immediately that this re-derives a view rather than performing analysis.
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?
Gives an explicit condition for use ('only when a compact coverage view is needed separately') and names the alternative plus why it is usually unnecessary ('analyze_repository already includes this result'). This is textbook when/when-not guidance.
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.
v1.0.0analyze_project_test_placement2 fields changedInput schema / properties / projectAudits / descriptionPrevious value: -"A project-audits/v1 artifact."New value: +"The project-audits/v1 object returned by audit_projects; pass the artifact itself, not a file path."Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "test-placement-findings-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "findings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "move",
+ "split",
+ "keep"
+ ]
+ },
+ "currentOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "suggestedOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testFile": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "testFile",
+ "currentOwner",
+ "suggestedOwner",
+ "action",
+ "reason",
+ "evidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "test-placement-findings/v1"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "findings"
+ ],
+ "title": "Test Placement Findings Artifact",
+ "type": "object"
+}analyze_repository1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "auditSummary": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-audit-summary/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "candidateRanking": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-candidate-ranking/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "executionHints": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "plan-execution-hints/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "findings": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-findings/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "projectAudits": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-audits/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "stats": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-stats/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ },
+ "testPlan": {
+ "additionalProperties": true,
+ "properties": {
+ "schemaVersion": {
+ "const": "project-test-plan/v1"
+ }
+ },
+ "required": [
+ "schemaVersion"
+ ],
+ "type": "object"
+ }
+ },
+ "$id": "repository-analysis-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "auditSummary": {
+ "$ref": "#/$defs/auditSummary"
+ },
+ "candidateRanking": {
+ "$ref": "#/$defs/candidateRanking"
+ },
+ "executionHints": {
+ "$ref": "#/$defs/executionHints"
+ },
+ "findings": {
+ "$ref": "#/$defs/findings"
+ },
+ "projectAudits": {
+ "$ref": "#/$defs/projectAudits"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "repository-analysis/v1"
+ },
+ "stats": {
+ "$ref": "#/$defs/stats"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "blockerCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "candidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "findingCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "planItemCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verificationCommandCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage",
+ "blockerCount",
+ "findingCount",
+ "candidateCount",
+ "planItemCount",
+ "verificationCommandCount"
+ ],
+ "type": "object"
+ },
+ "testPlan": {
+ "$ref": "#/$defs/testPlan"
+ },
+ "verificationCommands": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "command": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectCount": {
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "command",
+ "projectCount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "verificationCommands",
+ "projectAudits",
+ "auditSummary",
+ "findings",
+ "candidateRanking",
+ "testPlan",
+ "executionHints",
+ "stats"
+ ],
+ "title": "Repository Analysis Artifact",
+ "type": "object"
+}analyze_test_placement2 fields changedInput schema / properties / audit / descriptionPrevious value: -"An audit/v1 artifact."New value: +"The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path."Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "test-placement-findings-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "findings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "move",
+ "split",
+ "keep"
+ ]
+ },
+ "currentOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "suggestedOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testFile": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "testFile",
+ "currentOwner",
+ "suggestedOwner",
+ "action",
+ "reason",
+ "evidence"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "test-placement-findings/v1"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "findings"
+ ],
+ "title": "Test Placement Findings Artifact",
+ "type": "object"
+}audit_projects1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-audits-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "audits": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "audit": {
+ "additionalProperties": true,
+ "properties": {
+ "coveredButRisky": {
+ "type": "array"
+ },
+ "profile": {
+ "type": "object"
+ },
+ "risks": {
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "audit/v1"
+ },
+ "skipped": {
+ "type": "array"
+ },
+ "untestedCandidates": {
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "profile",
+ "untestedCandidates",
+ "coveredButRisky",
+ "skipped",
+ "risks"
+ ],
+ "type": "object"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "adapterId",
+ "audit"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-audits/v1"
+ },
+ "skippedProjects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterMatches": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "matchedEcosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matchedLanguages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ }
+ },
+ "required": [
+ "adapterId",
+ "maturity",
+ "matchedEcosystems",
+ "matchedLanguages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "reason",
+ "ecosystems",
+ "languages",
+ "adapterMatches",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skippedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "skippedProjectCount"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "audits",
+ "skippedProjects"
+ ],
+ "title": "Project Audits Artifact",
+ "type": "object"
+}audit_repo1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "auditTarget": {
+ "additionalProperties": false,
+ "properties": {
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "enum": [
+ "filename-convention",
+ "direct-relative-import",
+ "referenced-relative-reexport",
+ "tsconfig-path-import",
+ "package-entry-import",
+ "bounded-dependency",
+ "browser-route-match",
+ "csharp-symbol-reference",
+ "csharp-test-helper",
+ "swift-symbol-reference",
+ "python-module-import",
+ "python-package-reexport",
+ "python-pytest-fixture",
+ "python-test-client-route",
+ "jvm-symbol-reference",
+ "go-symbol-reference",
+ "go-source-dependency",
+ "rust-symbol-reference",
+ "ruby-constant-reference",
+ "php-symbol-reference",
+ "elixir-module-reference"
+ ]
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommendedTestLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ },
+ "risk": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "testability": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "id",
+ "path",
+ "kind",
+ "signals",
+ "risk",
+ "testability",
+ "recommendedTestLevel",
+ "riskReductionScore",
+ "maintenanceCost",
+ "reasons",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "skippedTarget": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "preferredCoveragePath": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "id",
+ "path",
+ "kind",
+ "signals",
+ "riskReductionScore",
+ "maintenanceCost",
+ "reason"
+ ],
+ "type": "object"
+ }
+ },
+ "$id": "https://repo-test-architect.local/schemas/audit-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "coveredButRisky": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ },
+ "profile": {
+ "additionalProperties": false,
+ "properties": {
+ "architectures": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "blockers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "detectedConventions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "existingTestLocations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "packageManagers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "root": {
+ "type": "string"
+ },
+ "setupSignals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "testCommand": {
+ "type": "string"
+ },
+ "testFrameworks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "root",
+ "languages",
+ "packageManagers",
+ "testFrameworks",
+ "architectures",
+ "detectedConventions",
+ "existingTestLocations",
+ "setupSignals",
+ "confidence",
+ "blockers"
+ ],
+ "type": "object"
+ },
+ "recommended": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ },
+ "risks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "audit/v1"
+ },
+ "skipped": {
+ "items": {
+ "$ref": "#/$defs/skippedTarget"
+ },
+ "type": "array"
+ },
+ "untestedCandidates": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "profile",
+ "untestedCandidates",
+ "coveredButRisky",
+ "recommended",
+ "skipped",
+ "risks"
+ ],
+ "title": "Repo Test Architect Audit",
+ "type": "object"
+}collect_project_findings1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-findings-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "findings": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "move",
+ "split",
+ "keep"
+ ]
+ },
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "category": {
+ "enum": [
+ "missing-coverage",
+ "weak-existing-coverage",
+ "misplaced-coverage",
+ "low-value-direct-test",
+ "blocked-project"
+ ]
+ },
+ "currentOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "evidence": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "kind": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "path": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "rationale": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "severity": {
+ "enum": [
+ "high",
+ "medium",
+ "low"
+ ]
+ },
+ "suggestedOwner": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "target": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "targetId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testFile": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ },
+ "title": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "category",
+ "severity",
+ "priority",
+ "projectId",
+ "projectRoot",
+ "title",
+ "rationale",
+ "evidence",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-findings/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "blockedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "categoryCounts": {
+ "additionalProperties": false,
+ "properties": {
+ "blocked-project": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "low-value-direct-test": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "misplaced-coverage": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "missing-coverage": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "weak-existing-coverage": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "missing-coverage",
+ "weak-existing-coverage",
+ "misplaced-coverage",
+ "low-value-direct-test",
+ "blocked-project"
+ ],
+ "type": "object"
+ },
+ "displayedFindingCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "findingCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "highSeverityCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "maxFindings": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "placementFindingCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedReasons": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array",
+ "uniqueItems": true
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage",
+ "unsupportedReasons",
+ "findingCount",
+ "displayedFindingCount",
+ "maxFindings",
+ "highSeverityCount",
+ "placementFindingCount",
+ "blockedProjectCount",
+ "categoryCounts"
+ ],
+ "type": "object"
+ },
+ "unsupportedProjects": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "adapterMatches": {
+ "type": "array"
+ },
+ "ecosystems": {
+ "type": "array"
+ },
+ "languages": {
+ "type": "array"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "reason",
+ "ecosystems",
+ "languages",
+ "adapterMatches",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "findings",
+ "unsupportedProjects"
+ ],
+ "title": "Project Findings Artifact",
+ "type": "object"
+}collect_project_stats2 fields changedInput schema / properties / projectAudits / descriptionPrevious value: -"A project-audits/v1 artifact."New value: +"The project-audits/v1 object returned by audit_projects; pass the artifact itself, not a file path."Output schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "countRecord": {
+ "additionalProperties": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "type": "object"
+ }
+ },
+ "$id": "project-stats-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "adapters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "adapterId",
+ "projectCount"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "counts": {
+ "additionalProperties": false,
+ "properties": {
+ "blockerCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "coveredButRiskyCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "riskCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skippedTargetCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "untestedCandidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "untestedCandidateCount",
+ "coveredButRiskyCount",
+ "skippedTargetCount",
+ "riskCount",
+ "blockerCount"
+ ],
+ "type": "object"
+ },
+ "distributions": {
+ "additionalProperties": false,
+ "properties": {
+ "confidence": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "evidenceKinds": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "evidenceStrengths": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "evidenceUsage": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "evidenceViaUsage": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "riskLevels": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "signals": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "targetKinds": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "testCommands": {
+ "$ref": "#/$defs/countRecord"
+ },
+ "testFrameworks": {
+ "$ref": "#/$defs/countRecord"
+ }
+ },
+ "required": [
+ "confidence",
+ "testFrameworks",
+ "testCommands",
+ "targetKinds",
+ "riskLevels",
+ "signals",
+ "evidenceStrengths",
+ "evidenceKinds",
+ "evidenceUsage",
+ "evidenceViaUsage"
+ ],
+ "type": "object"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-stats/v1"
+ },
+ "sourceFiles": {
+ "additionalProperties": false,
+ "properties": {
+ "audited": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "byLanguage": {
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "audited": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupported": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "audited",
+ "unsupported"
+ ],
+ "type": "object"
+ },
+ "type": "object"
+ },
+ "total": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupported": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "audited",
+ "unsupported",
+ "byLanguage"
+ ],
+ "type": "object"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "sourceFiles",
+ "counts",
+ "distributions",
+ "adapters"
+ ],
+ "title": "Project Stats Artifact",
+ "type": "object"
+}detect_projects2 fields changedInput schema / properties / repoRoot / descriptionPrevious value: -"Repository root path."New value: +"Readable repository directory whose project markers should be inspected."Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-detection-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "projects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "absoluteRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "adapterIds": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "adapterMatches": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "matchedEcosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matchedLanguages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ }
+ },
+ "required": [
+ "adapterId",
+ "maturity",
+ "matchedEcosystems",
+ "matchedLanguages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "markerFiles": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supported": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "id",
+ "root",
+ "absoluteRoot",
+ "ecosystems",
+ "languages",
+ "markerFiles",
+ "adapterIds",
+ "adapterMatches",
+ "supported",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-detection/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "supportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectCount",
+ "supportedProjectCount",
+ "unsupportedProjectCount"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "projects",
+ "summary"
+ ],
+ "title": "Project Detection Artifact",
+ "type": "object"
+}explain_target3 fields changedInput schema / properties / audit / descriptionPrevious value: -"An audit/v1 artifact."New value: +"The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path."Input schema / properties / targetId / descriptionPrevious value: -"Stable audit target id."New value: +"Exact stable id from an audit target in untestedCandidates, coveredButRisky, recommended, or skipped."Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://repo-test-architect.local/schemas/target-explanation-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "enum": [
+ "untestedCandidates",
+ "coveredButRisky",
+ "skipped"
+ ]
+ },
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "path": {
+ "type": "string"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommendation": {
+ "enum": [
+ "test",
+ "defer"
+ ]
+ },
+ "risk": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "schemaVersion": {
+ "const": "target-explanation/v1"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target": {
+ "type": "string"
+ },
+ "targetId": {
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ },
+ "testability": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "targetId",
+ "target",
+ "path",
+ "category",
+ "kind",
+ "recommendation",
+ "testLevel",
+ "risk",
+ "testability",
+ "riskReductionScore",
+ "maintenanceCost",
+ "signals",
+ "rationale",
+ "existingTestPaths"
+ ],
+ "title": "Repo Test Architect Target Explanation",
+ "type": "object"
+}generate_project_test_plan1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-test-plan-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "add-test",
+ "extend-test",
+ "defer"
+ ]
+ },
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "path": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectItemId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceSignals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "targetId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "adapterId",
+ "projectItemId",
+ "id",
+ "action",
+ "targetId",
+ "target",
+ "path",
+ "testLevel",
+ "priority",
+ "riskReductionScore",
+ "maintenanceCost",
+ "rationale",
+ "sourceSignals",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "projectPlans": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "plan": {
+ "additionalProperties": true,
+ "properties": {
+ "blockers": {
+ "type": "array"
+ },
+ "items": {
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "plan/v1"
+ },
+ "summary": {
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "summary",
+ "blockers",
+ "items"
+ ],
+ "type": "object"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "adapterId",
+ "plan"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-test-plan/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "addTestCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "deferredCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "extendTestCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "itemCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "plannedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedReasons": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array",
+ "uniqueItems": true
+ }
+ },
+ "required": [
+ "projectCount",
+ "plannedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage",
+ "unsupportedReasons",
+ "addTestCount",
+ "extendTestCount",
+ "deferredCount",
+ "itemCount"
+ ],
+ "type": "object"
+ },
+ "unsupportedProjects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterMatches": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "matchedEcosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matchedLanguages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ }
+ },
+ "required": [
+ "adapterId",
+ "maturity",
+ "matchedEcosystems",
+ "matchedLanguages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "reason",
+ "ecosystems",
+ "languages",
+ "adapterMatches",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "unsupportedProjects",
+ "projectPlans",
+ "items"
+ ],
+ "title": "Project Test Plan Artifact",
+ "type": "object"
+}generate_selected_test1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://repo-test-architect.local/schemas/generation-deferred-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "nextSteps": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "planItemId": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "generation-deferred/v1"
+ },
+ "status": {
+ "const": "deferred"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "planItemId",
+ "status",
+ "reason",
+ "nextSteps"
+ ],
+ "title": "Repo Test Architect Generation Deferred",
+ "type": "object"
+}generate_test_plan3 fields changedInput schema / properties / audit / descriptionPrevious value: -"An audit/v1 artifact."New value: +"The audit/v1 object returned by audit_repo or contained in projectAudits.audits[].audit; pass the artifact itself, not a file path."Input schema / properties / itemId / descriptionPrevious value: -"Optional stable plan item id to select."New value: +"Optional exact plan item id to return; omit it to return the complete deterministic plan."Output schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://repo-test-architect.local/schemas/plan-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "blockers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "add-test",
+ "extend-test",
+ "defer"
+ ]
+ },
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "path": {
+ "type": "string"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "sourceSignals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target": {
+ "type": "string"
+ },
+ "targetId": {
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "action",
+ "targetId",
+ "target",
+ "path",
+ "testLevel",
+ "priority",
+ "riskReductionScore",
+ "maintenanceCost",
+ "rationale",
+ "sourceSignals",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "plan/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "addTestCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "blockerCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "confidence": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "deferredCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "extendTestCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "verificationCommand": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "confidence",
+ "blockerCount",
+ "addTestCount",
+ "extendTestCount",
+ "deferredCount"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "summary",
+ "blockers",
+ "items"
+ ],
+ "title": "Repo Test Architect Test Plan",
+ "type": "object"
+}get_audit_graph1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$defs": {
+ "auditTarget": {
+ "additionalProperties": false,
+ "properties": {
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "enum": [
+ "filename-convention",
+ "direct-relative-import",
+ "referenced-relative-reexport",
+ "tsconfig-path-import",
+ "package-entry-import",
+ "bounded-dependency",
+ "browser-route-match",
+ "csharp-symbol-reference",
+ "csharp-test-helper",
+ "swift-symbol-reference",
+ "python-module-import",
+ "python-package-reexport",
+ "python-pytest-fixture",
+ "python-test-client-route",
+ "jvm-symbol-reference",
+ "go-symbol-reference",
+ "go-source-dependency",
+ "rust-symbol-reference",
+ "ruby-constant-reference",
+ "php-symbol-reference",
+ "elixir-module-reference"
+ ]
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "recommendedTestLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ },
+ "risk": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "testability": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "id",
+ "path",
+ "kind",
+ "signals",
+ "risk",
+ "testability",
+ "recommendedTestLevel",
+ "riskReductionScore",
+ "maintenanceCost",
+ "reasons",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "skippedTarget": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "name": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "preferredCoveragePath": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "name",
+ "id",
+ "path",
+ "kind",
+ "signals",
+ "riskReductionScore",
+ "maintenanceCost",
+ "reason"
+ ],
+ "type": "object"
+ }
+ },
+ "$id": "https://repo-test-architect.local/schemas/audit-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "coveredButRisky": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ },
+ "profile": {
+ "additionalProperties": false,
+ "properties": {
+ "architectures": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "blockers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "confidence": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "detectedConventions": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "existingTestLocations": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "packageManagers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "root": {
+ "type": "string"
+ },
+ "setupSignals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "testCommand": {
+ "type": "string"
+ },
+ "testFrameworks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "root",
+ "languages",
+ "packageManagers",
+ "testFrameworks",
+ "architectures",
+ "detectedConventions",
+ "existingTestLocations",
+ "setupSignals",
+ "confidence",
+ "blockers"
+ ],
+ "type": "object"
+ },
+ "recommended": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ },
+ "risks": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "audit/v1"
+ },
+ "skipped": {
+ "items": {
+ "$ref": "#/$defs/skippedTarget"
+ },
+ "type": "array"
+ },
+ "untestedCandidates": {
+ "items": {
+ "$ref": "#/$defs/auditTarget"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "profile",
+ "untestedCandidates",
+ "coveredButRisky",
+ "recommended",
+ "skipped",
+ "risks"
+ ],
+ "title": "Repo Test Architect Audit",
+ "type": "object"
+}get_plan_execution_hints1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://repo-test-architect.local/schemas/plan-execution-hints-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "action": {
+ "enum": [
+ "add-test",
+ "extend-test",
+ "defer"
+ ]
+ },
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "complexity": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "contextScope": {
+ "additionalProperties": false,
+ "properties": {
+ "includeBuildConfiguration": {
+ "type": "boolean"
+ },
+ "includeRepositoryInstructions": {
+ "const": true
+ },
+ "mode": {
+ "enum": [
+ "target-only",
+ "target-and-tests",
+ "project-boundary"
+ ]
+ },
+ "paths": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array",
+ "uniqueItems": true
+ }
+ },
+ "required": [
+ "mode",
+ "paths",
+ "includeBuildConfiguration",
+ "includeRepositoryInstructions"
+ ],
+ "type": "object"
+ },
+ "parallelizable": {
+ "type": "boolean"
+ },
+ "path": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "planItemId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reasons": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "recommendedAgentRole": {
+ "enum": [
+ "implementation",
+ "repository-reasoning",
+ "review"
+ ]
+ },
+ "requiresRepositoryReasoning": {
+ "type": "boolean"
+ },
+ "target": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "planItemId",
+ "action",
+ "target",
+ "path",
+ "complexity",
+ "contextScope",
+ "parallelizable",
+ "recommendedAgentRole",
+ "requiresRepositoryReasoning",
+ "reasons"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "plan-execution-hints/v1"
+ },
+ "source": {
+ "additionalProperties": false,
+ "properties": {
+ "itemCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "enum": [
+ "plan/v1",
+ "project-test-plan/v1"
+ ]
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "itemCount"
+ ],
+ "type": "object"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "highComplexityCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "itemCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "lowComplexityCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "mediumComplexityCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "parallelizableCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "repositoryReasoningCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "itemCount",
+ "lowComplexityCount",
+ "mediumComplexityCount",
+ "highComplexityCount",
+ "parallelizableCount",
+ "repositoryReasoningCount"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "source",
+ "summary",
+ "items"
+ ],
+ "title": "Repo Test Architect Plan Execution Hints",
+ "type": "object"
+}list_adapters1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "adapter-registry-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "adapters": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "emittedArtifacts": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "id": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ },
+ "supportedProjectTypes": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "supportedTestFrameworks": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "ecosystems",
+ "languages",
+ "maturity",
+ "supportedTestFrameworks",
+ "supportedProjectTypes",
+ "emittedArtifacts"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "adapter-registry/v1"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "adapters"
+ ],
+ "title": "Adapter Registry Artifact",
+ "type": "object"
+}list_project_detection_rules1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-detection-rules-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "fallbackRules": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "ignoredDirectories": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "markers": {
+ "items": {
+ "additionalProperties": false,
+ "oneOf": [
+ {
+ "required": [
+ "fileName"
+ ]
+ },
+ {
+ "required": [
+ "extension"
+ ]
+ },
+ {
+ "required": [
+ "directoryExtension"
+ ]
+ }
+ ],
+ "properties": {
+ "directoryExtension": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "ecosystem": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "extension": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "fileName": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "ecosystem",
+ "languages"
+ ],
+ "type": "object"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "project-detection-rules/v1"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "markers",
+ "ignoredDirectories"
+ ],
+ "title": "Project Detection Rules Artifact",
+ "type": "object"
+}rank_project_candidates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-candidate-ranking-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "candidates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "category": {
+ "enum": [
+ "untested",
+ "covered-but-risky"
+ ]
+ },
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "path": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectTargetId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "targetId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "adapterId",
+ "projectTargetId",
+ "targetId",
+ "target",
+ "path",
+ "category",
+ "kind",
+ "testLevel",
+ "priority",
+ "riskReductionScore",
+ "maintenanceCost",
+ "signals",
+ "rationale",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-candidate-ranking/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "candidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedReasons": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array",
+ "uniqueItems": true
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage",
+ "unsupportedReasons",
+ "candidateCount"
+ ],
+ "type": "object"
+ },
+ "unsupportedProjects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterMatches": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "matchedEcosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matchedLanguages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ }
+ },
+ "required": [
+ "adapterId",
+ "maturity",
+ "matchedEcosystems",
+ "matchedLanguages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "reason",
+ "ecosystems",
+ "languages",
+ "adapterMatches",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "unsupportedProjects",
+ "candidates"
+ ],
+ "title": "Project Candidate Ranking Artifact",
+ "type": "object"
+}rank_test_candidates1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "https://repo-test-architect.local/schemas/candidate-ranking-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "blockers": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "candidates": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "category": {
+ "enum": [
+ "untested",
+ "covered-but-risky"
+ ]
+ },
+ "existingTestEvidence": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "strength": {
+ "enum": [
+ "naming",
+ "direct",
+ "referenced",
+ "indirect"
+ ]
+ },
+ "testPath": {
+ "type": "string"
+ },
+ "usage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ },
+ "viaUsage": {
+ "enum": [
+ "called",
+ "asserted"
+ ]
+ }
+ },
+ "required": [
+ "testPath",
+ "kind",
+ "strength"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "existingTestPaths": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "maintenanceCost": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "path": {
+ "type": "string"
+ },
+ "priority": {
+ "type": "integer"
+ },
+ "rationale": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "riskReductionScore": {
+ "maximum": 10,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "signals": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "target": {
+ "type": "string"
+ },
+ "targetId": {
+ "type": "string"
+ },
+ "testLevel": {
+ "enum": [
+ "unit",
+ "integration",
+ "component",
+ "ui",
+ "none"
+ ]
+ }
+ },
+ "required": [
+ "targetId",
+ "target",
+ "path",
+ "category",
+ "kind",
+ "testLevel",
+ "priority",
+ "riskReductionScore",
+ "maintenanceCost",
+ "signals",
+ "rationale",
+ "existingTestPaths"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "schemaVersion": {
+ "const": "candidate-ranking/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "blockerCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "candidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "confidence": {
+ "enum": [
+ "low",
+ "medium",
+ "high"
+ ]
+ },
+ "verificationCommand": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "confidence",
+ "candidateCount",
+ "blockerCount"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "summary",
+ "blockers",
+ "candidates"
+ ],
+ "title": "Repo Test Architect Candidate Ranking",
+ "type": "object"
+}summarize_project_audits1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$id": "project-audit-summary-v1.schema.json",
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "projects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "confidence": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "coveredButRiskyCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "riskCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skippedTargetCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "testCommand": {
+ "type": "string"
+ },
+ "topCandidateIds": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "untestedCandidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "adapterId",
+ "confidence",
+ "untestedCandidateCount",
+ "coveredButRiskyCount",
+ "skippedTargetCount",
+ "riskCount",
+ "topCandidateIds"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "root": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "schemaVersion": {
+ "const": "project-audit-summary/v1"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "auditCoverage": {
+ "enum": [
+ "complete",
+ "partial",
+ "none"
+ ]
+ },
+ "auditedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "coveredButRiskyCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "projectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "riskCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "skippedTargetCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedProjectCount": {
+ "minimum": 0,
+ "type": "integer"
+ },
+ "unsupportedReasons": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array",
+ "uniqueItems": true
+ },
+ "untestedCandidateCount": {
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "projectCount",
+ "auditedProjectCount",
+ "unsupportedProjectCount",
+ "auditCoverage",
+ "unsupportedReasons",
+ "untestedCandidateCount",
+ "coveredButRiskyCount",
+ "skippedTargetCount",
+ "riskCount"
+ ],
+ "type": "object"
+ },
+ "unsupportedProjects": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterMatches": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "adapterId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "matchedEcosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "matchedLanguages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maturity": {
+ "enum": [
+ "supported",
+ "experimental",
+ "planned"
+ ]
+ }
+ },
+ "required": [
+ "adapterId",
+ "maturity",
+ "matchedEcosystems",
+ "matchedLanguages"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "ecosystems": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "projectId": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "projectRoot": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "reason": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "supportStatusReason": {
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "projectId",
+ "projectRoot",
+ "reason",
+ "ecosystems",
+ "languages",
+ "adapterMatches",
+ "supportStatusReason"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "schemaVersion",
+ "root",
+ "summary",
+ "projects",
+ "unsupportedProjects"
+ ],
+ "title": "Project Audit Summary Artifact",
+ "type": "object"
+}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_auditsScored across 19 tools
The set contains many overlapping artifact-consumption tools: analyze_repository subsumes several specialist outputs, and project-wide vs single-audit variants mirror each other. The long descriptions explicitly steer callers, but boundaries remain fuzzy enough that misselection is likely.
Almost all tools use snake_case verb_noun naming, making the surface predictable. Minor deviations exist, such as audit_repo vs analyze_repository and project-qualified vs unqualified variants.
19 tools is heavy for a repository test-architecture review server, and several tools only expose slices already included in analyze_repository. The specialized pipeline justifies some breadth, but the count is borderline excessive.
The analysis lifecycle is well covered: detection, auditing, ranking, planning, placement, stats, findings, and target explanation. However, actual test generation is explicitly deferred/non-functional and there is no write or execution surface, which is a notable gap for a test architect.
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Repository knowledge graph MCP server for codebase understanding and debugging.
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.
Detects database migration table locks, terraform cost leaks, and OWASP API flaws.
