The SDLC Command Center MCP Server is a comprehensive local-first tool for project analysis, security auditing, and controlled file modifications, accessible as an API for AI coding assistants and a web dashboard. It provides a suite of MCP tools for safe inspection and gated, audit-logged write operations.
Read & Understand: Repository snapshot, directory tree, file reading (single and batch up to 20 files) with automatic secret redaction, language statistics, and dependency inventory.
Release & Risk: Release readiness checks, composite risk score (0–100 with letter grade), and plugin manifest validation.
Search & Security: Secret scanning (pattern-based detection of API keys, passwords, tokens), regex code search with context lines, all findings redacted.
Git Insights: Local git history showing recent commits, distinct authors, and file churn hotspots.
Safe Modifications: Create, overwrite, or append files; exact text replacement; all with dry-run preview, automatic backup, and tamper-evident audit logging; explicit confirmation required.
Change Management: List recorded changes, verify audit log integrity, and rollback any change by ID.
Shadow Workspaces: Create, promote, and destroy isolated project copies (Git worktrees) for safe experimentation.
Server & Environment: Streamable HTTP transport, OAuth 2.0 Bearer authentication (rotatable via CLI), configuration engine, environment diagnostics (doctor), and a zero-dependency web dashboard for visualizing risk, audit chain, language stats, and tool registry.
Safety Guarantees: All read tools are non-destructive and idempotent; write tools default to dry-run mode; secrets are always redacted; every mutation is backed up and logged in a hash-chained audit trail.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SDLC Command Center MCP Server run a release readiness check on the project repo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your project's autopilot for quality, security, and delivery readiness.
The SDLC Command Center is a local-first tool that inspects your software project and tells you, in plain language, what's going on — what shape the code is in, whether there are secrets leaked, if you're ready to release, and how risky the current state is. It can also make safe, approved changes to files with full rollback and audit tracking.
Think of it as a project health dashboard that lives in your terminal or connects to your AI coding assistant.
If you are... | You can use it to... |
A project manager | Check if a release is ready, see code health scores, understand risk without reading code |
A team lead | Get a quick snapshot of repository structure, dependencies, and delivery signals |
A developer | Search code, read files safely, find secrets, understand language breakdown |
A security reviewer | Scan for leaked secrets, check entropy of tokens, audit file changes |
An AI coding agent | Use 26 built-in tools to inspect, analyze, and safely modify codebases |
Related MCP server: SnapBack MCP Server
The tool answers these questions about any software project:
"What's in this repo?" — File counts, directory structure, language breakdown
"Is it ready to ship?" — Release readiness checks, risk scoring, dependency inventory
"Are there secrets in the code?" — Pattern-based and entropy-based secret detection
"What's the code quality?" — TODO counts, complexity hints, health scoring
"Can I safely change a file?" — Gated writes with backup, rollback, and audit trail
"What changed recently?" — Git history, churn hotspots, author activity
Streamable HTTP Transport — 2026 MCP-compliant HTTP server with session management, CORS, and DELETE /mcp for session termination
Bearer Token Authentication — OAuth 2.0 Bearer token auth for remote HTTP deployments. Token auto-generated on first run, rotatable via CLI
Configuration Engine — sdlc.config.json for tunable security, mutation, auth, and HTTP settings with schema-validated defaults
CLI auth and config commands — sdlc auth rotate/status/token and sdlc config show/init/validate
Web Dashboard — sdlc dashboard launches a zero-dependency, read-only web UI at http://127.0.0.1:8420 with risk score, release readiness, audit chain, shadow worktrees, language stats, and the full tool registry. Works offline, no CDN
npm wrapper — npx sdlc-mcp runs the server straight from the Node ecosystem (bundles the Python sources; only needs Python 3.9+ on PATH)
Open a terminal and run:
python3 --versionYou need Python 3.9 or newer. If you don't have it, download from python.org.
git clone https://github.com/Senpai-Sama7/autonomous-sdlc-command-center.git
cd autonomous-sdlc-command-centerOption A: Using the CLI directly
# Check your environment
python3 mcp/sdlc_cli.py doctor
# Scan a project for issues
python3 mcp/sdlc_cli.py snapshot --path /path/to/your/project
# Check if a release is ready
python3 mcp/sdlc_cli.py release-readiness --path /path/to/your/project
# Scan for leaked secrets
python3 mcp/sdlc_cli.py secret-scan --path /path/to/your/project
# Get a risk score (0-100)
python3 mcp/sdlc_cli.py risk --path /path/to/your/projectOption B: Connect to an AI coding assistant
The tool works as a Model Context Protocol (MCP) server, which means AI assistants like Claude Desktop, Cursor, Windsurf, and others can use its tools automatically.
# Start the server (it waits for your AI assistant to connect)
python3 mcp/sdlc_mcp_server.py
# Or run it as a local web service
python3 mcp/sdlc_mcp_server.py --http 8765See UNIVERSAL_INSTALL.md for setup instructions for each AI assistant.
Option C: PowerShell (Windows)
.\scripts\commands\repo_snapshot.ps1 -Path C:\your\project
.\scripts\commands\release_readiness.ps1 -Path C:\your\projectThese tools look at your project and report back. They never change anything.
Tool | What it does in plain English |
repo_snapshot | Gives you a complete inventory: how many files, what types, directory tree, symlinks, non-UTF-8 files, and optional git status |
release_readiness | Answers "can we ship this?" by checking for README, license, tests, git state, and whitespace issues |
plugin_preflight | Validates that plugin manifests and skill contracts are correctly formatted |
read_file | Safely reads a single file with automatic secret redaction and binary detection |
read_files | Reads up to 20 files at once (same safety as read_file) |
directory_tree | Shows the folder structure up to a configurable depth |
search_code | Searches across all text files using regex patterns, with context lines |
language_stats | Breaks down the project by programming language (file count and line count) |
dependency_inventory | Lists all dependencies from package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml |
git_history | Shows recent commits, distinct authors, and which files change most often |
risk_score | Gives the project a risk grade from A (low risk) to F (high risk) based on multiple signals |
doctor | Checks that the tool itself is working correctly on your system |
list_changes | Shows all file changes that have been made through the write engine (for rollback) |
audit_log | Reads the tamper-evident audit trail and verifies its integrity |
Tool | What it does in plain English |
secret_scan | Looks for patterns that look like API keys, passwords, tokens, and credentials. Always redacts the actual values — it reports where secrets are, not what they are |
entropy_scan (new) | Finds secrets that pattern-based scanning misses. Uses math (Shannon entropy) to detect randomly-generated strings like API keys, JWTs, and tokens that don't match any known pattern. Handles deduplication and shows safe previews |
Tool | What it does in plain English |
code_metrics | Counts TODOs, FIXMEs, large files, long lines, empty files, and flags files with high branch density. Gives an overall health score from A to F |
sbom | Creates a Software Bill of Materials (SBOM) — a list of every dependency your project uses, in a standard format |
These tools can modify files, but only when you explicitly approve. Every change is backed up first.
Tool | What it does in plain English |
write_file | Creates or overwrites a file. Shows a preview of what will change before you confirm |
replace_in_file | Finds exact text in a file and replaces it. Verifies the number of matches before applying |
replace_in_file_ast | Same as replace_in_file, but smarter for Python files. It understands code structure, so it only replaces text inside string literals — it won't accidentally change variable names or code logic. Original formatting and comments are preserved exactly (the file is spliced in place, never regenerated). Same safety gate as every other write tool: dry-run by default, backup, audit entry, rollback |
rollback | Undoes a previous change by its ID. Restores the original content or deletes files that were created |
These tools let you make changes in an isolated copy of your project, test them, and only merge back if everything works.
Tool | What it does in plain English |
shadow_create | Creates a temporary copy of your project (a Git worktree) where you can make changes without affecting the real project |
shadow_promote | Checks if your changes conflict with anything in the real project, then merges them back if it's safe. Promotion goes through the same gated write engine as every other mutation — each promoted file is backed up, recorded in the audit log, and the whole promotion is reversible by its single |
shadow_destroy | Cleans up a temporary workspace when you're done with it |
shadow_list | Shows all active temporary workspaces |
The write engine is designed so that mistakes are recoverable. Here's how:
Preview first — Every change starts as a dry-run. You see exactly what will change (a diff preview) before anything happens.
Confirm to apply — Nothing changes unless you explicitly say "yes, do it" (pass confirm: true).
Backup before change — The original content is saved in .sdlc/backups/ before any file is modified.
Atomic writes — Changes are written to a temporary file first, then swapped in place. If something fails mid-write, the original is preserved.
Audit trail — Every change is recorded in .sdlc/audit.jsonl with a cryptographic hash chain. If anyone tampers with the log, it's detectable.
Rollback — Any change can be undone by its unique ID. The tool restores the exact original content.
Interrupted writes are detectable — A write-ahead intent file is created before the mutation and cleared after the audit entry lands. If the process dies in between, audit_log reports the change under incompleteChanges and returns status: "fail", so a mutation can never end up on disk with no record of it.
These guarantees are uniform. Every tool that can modify a file — write_file, replace_in_file, replace_in_file_ast, rollback, and shadow_promote — routes through the same transaction primitives. There is no "fast path" that skips the jail, the sensitive-file gate, the backup, or the audit entry.
In particular, shadow_promote cannot write into .git/ or .sdlc/. This matters: without that gate, a shadow session could promote its own copy of .sdlc/audit.jsonl over the real one and silently replace the tamper-evident log the whole system relies on. Refused paths are returned in refused[] rather than dropped silently.
You run a write tool
│
▼
┌─────────┐
│ Dry-run │ ──► Shows you the diff preview
└────┬────┘
│ confirm: true
▼
┌─────────┐
│ Backup │ ──► Saves original to .sdlc/backups/
└────┬────┘
│
▼
┌─────────┐
│ Write │ ──► Atomic temp file + rename
└────┬────┘
│
▼
┌─────────┐
│ Audit │ ──► Appends to hash-chained log
└─────────┘The SDLC Command Center works as an MCP server, which means AI assistants can use its tools automatically. Here's how to connect it:
# Install the CLI and MCP server globally
pip install --user -e .
# The binaries are now at:
# ~/.local/bin/sdlc (CLI)
# ~/.local/bin/sdlc-mcp (MCP server)If you live in the Node world, the sdlc-mcp npm package bundles the entire
Python implementation — no pip install needed, just Python 3.9+ on PATH:
# Run the MCP server directly
npx sdlc-mcp
# Or use the CLI
npx -p sdlc-mcp sdlc doctorMCP client config for npx:
{
"mcpServers": {
"sdlc": { "command": "npx", "args": ["-y", "sdlc-mcp"] }
}
}For a visual, read-only overview of any repository:
sdlc dashboard --path /path/to/project --open
# Serves http://127.0.0.1:8420 — risk grade, release readiness checks,
# audit chain status, shadow worktrees, language breakdown, tool registry.
# Read-only: the dashboard can never modify your code.Assistant | Config location | What to add |
OpenCode |
| Add |
Claude Desktop |
| Add the server command to |
Claude Code |
| Add to |
Cursor |
| Add to |
Windsurf |
| Add to |
VSCode |
| Add to |
Gemini |
| Add to |
See UNIVERSAL_INSTALL.md for exact configuration examples for each assistant.
sdlc.config.json)Create a config file to tune all settings:
sdlc config init # Creates sdlc.config.json with defaults
sdlc config show # Display active configuration
sdlc config validate # Check config file is validKey settings:
Section | Setting | Default | What it controls |
|
|
| Minimum Shannon entropy to flag a token |
|
|
|
|
|
|
| Streamable HTTP session expiry |
|
|
| Maximum write size (1 MiB) |
|
|
| Per-tool rate limit |
Variable | Default | What it controls |
|
| Maximum calls per tool per time window |
|
| Time window for rate limiting (seconds) |
| (unset) | Set to |
The server generates a Bearer token on first startup (stored in .sdlc/server.token).
sdlc auth status # Show auth config and token preview
sdlc auth rotate # Generate new token, archive old one
sdlc auth token # Print the raw token (for CI/CD)For local-only use (no auth required):
sdlc serve --http 8765 --auth none# Run on stdio (default, for AI assistants)
python3 mcp/sdlc_mcp_server.py
# Run as HTTP server (basic)
python3 mcp/sdlc_mcp_server.py --http 8765
# Run as Streamable HTTP (2026 MCP standard, with sessions + auth)
python3 mcp/sdlc_mcp_server.py --http-streamable 8765
# Run without auth (local-only)
python3 mcp/sdlc_mcp_server.py --http-streamable 8765 --auth none
python3 mcp/sdlc_mcp_server.py --http 8765 --host 0.0.0.0Component | Description | Works on |
MCP Server | 26 tools over stdio or localhost HTTP | Windows, Linux, macOS (Python 3.9+) |
CLI | Full tool surface for any shell or CI runner | Windows, Linux, macOS (Python 3.9+) |
Skills | 7 workflow skills with machine-readable contracts | Any harness that loads Markdown |
PowerShell | Snapshot, readiness, preflight scripts | Windows PowerShell / pwsh |
Tests | 48 cross-platform smoke tests | Python 3.9+ |
Install scripts | Universal bash and PowerShell installers | Bash, PowerShell |
No third-party packages. No network calls against targets. No telemetry.
# Run the full test suite
python3 scripts/tests/smoke.py
# Expected: 48 passed, 0 failed, 1 skipped (UNC test is Windows-only)autonomous-sdlc-command-center/
├── mcp/ # Core Python modules
│ ├── sdlc_core.py # Shared utilities, file walking, git helpers
│ ├── sdlc_analyze.py # Read-only analysis tools
│ ├── sdlc_write.py # Safety-gated write engine
│ ├── sdlc_extensions.py # Extended tools (metrics, SBOM, entropy, AST)
│ ├── sdlc_shadow.py # Shadow worktree engine
│ ├── sdlc_mcp_server.py # MCP server (stdio + HTTP)
│ └── sdlc_cli.py # Command-line interface
├── scripts/
│ ├── commands/ # PowerShell automation
│ ├── tests/ # Smoke tests
│ ├── completions/ # Shell tab-completions (bash, zsh)
│ ├── install.sh # Universal bash installer
│ └── install.ps1 # PowerShell installer
├── skills/ # 7 workflow skills
├── hooks/ # Lifecycle hooks
├── docs/ # Operating model documentation
├── ANALYSIS_REPORT.md # Deep analysis and evaluation
├── UNIVERSAL_INSTALL.md # AI assistant setup guide
├── SECURITY.md # Security notes
├── PORTABILITY.md # Cross-platform compatibility
└── README.md # This fileOperating Model — How the tool fits into your development workflow
Security Notes — Detailed security guarantees and safety invariants
Portability — Cross-platform compatibility details
Universal Install — Step-by-step AI assistant setup
Analysis Report — Deep code analysis and quality evaluation
See LICENSE for details.
Read the mutation audit log and verify its tamper-evident hash chain.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxEntries | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| chainValid | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing it as a safe read operation. The description adds the verification aspect of the hash chain, which hints at its internal behavior (e.g., integrity check), but does not detail failure modes or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. Every word is necessary; there is no wasted text. It is perfectly concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value details are covered. The description addresses the core purpose and verification aspect. However, it lacks usage context (e.g., when to use this vs. other read tools) and does not mention what happens with invalid paths or broken hash chains, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 50% (path has a description, maxEntries does not). The tool description does not add any information about the parameters beyond what the schema provides. It fails to compensate for the missing schema description of maxEntries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the specific resource ('mutation audit log') with the additional purpose of verifying its tamper-evident hash chain. This distinguishes it from sibling tools like sdlc_read_file or sdlc_repo_snapshot, which serve different read purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading and verifying the audit log, but it does not explicitly state when to use it versus alternatives, what prerequisites are needed (e.g., permissions), or when not to use it. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best-effort offline dependency extraction from package.json, requirements.txt, pyproject.toml, go.mod, and Cargo.toml.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No | ||
| maxDependenciesPerManifest | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| totalDependencies | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints; the description adds the 'best-effort offline' qualifier clarifying performance and dependency on local files, which is useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant words, front-loading the purpose and specific file types, earning its place efficiently.
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 safety, the description adequately conveys the tool's core function and scope, though it could briefly mention output structure or edge cases (e.g., root paths) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage (only 'path' has documentation), the description does not compensate by explaining what 'maxFiles' or 'maxDependenciesPerManifest' control, leaving parameter semantics under-specified.
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 specific verb 'extract' and resource 'dependencies' from defined manifest files, clearly distinguishing it from sibling tools like sdlc_repo_snapshot which capture broader file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dependency extraction from local manifest files but does not explicitly state when to prefer this tool over other sdlc tools or when to avoid it, missing guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded recursive directory listing with depth and entry caps. Returns a flat array of {path, type, depth} entries.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxDepth | No | ||
| maxEntries | No | ||
| includeDirs | No | ||
| includeFiles | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| entryCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it specifies bounded recursion, depth and entry caps, and the flat array output format. Annotations already indicate readOnly, idempotent, and non-destructive, so the description complements these well.
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?
Extremely concise: two sentences with no redundancy. The first sentence immediately states the action and constraints; the second specifies the return structure. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description covers the essential aspects: bounded listing, return format. It could mention the filtering by includeDirs/includeFiles, but those are in the schema. Overall, it is sufficiently complete for a listing tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on individual parameters beyond mentioning depth and entry caps. The input schema already provides detailed descriptions for each parameter (e.g., path restrictions, defaults), so the description adds little value. With schema coverage at 20%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: bounded recursive directory listing with depth and entry caps, returning a flat array. It uses specific verbs and resources ('listing', 'directory tree'), and the output format is specified. It is distinct from sibling tools such as sdlc_read_file or sdlc_repo_snapshot.
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 explicit guidelines on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or suggest alternative tools. Sibling tools are listed but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe runtime, platform, executables, capabilities, and plugin preflight status. Useful for harness-agnostic setup verification.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | No | |
| coreVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds 'harness-agnostic setup verification' but does not contradict annotations. No additional behavioral disclosure needed beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action verb 'Probe', and every word adds value. No redundancy or wasted phrases.
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 zero parameters, strong annotations, and an output schema (not shown but present), the description fully covers the tool's purpose and usage context. No gaps in information for an agent to use 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?
The input schema has no parameters, so there is nothing to explain. Schema description coverage is 100%, and the description does not need to add parameter details. Baseline of 4 is appropriate as there are no missing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool probes multiple environment aspects (runtime, platform, executables, etc.) and specifies its use case (harness-agnostic setup verification). It distinguishes from siblings by focusing on general environment probing vs. specific repo/plugin/file tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('harness-agnostic setup verification') but does not explicitly state when not to use it or mention alternatives. The sibling list implies differentiation, but explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent local commits, distinct authors, and churn hotspots. Never contacts remotes.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxCommits | No | ||
| includeChurn | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| commitCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only nature is covered. The description adds valuable context: 'Never contacts remotes', which clarifies network behavior and local-only scope, 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?
Two sentences: one for purpose, one for a key constraint. No fluff, every word earns its place. Front-loaded with the core function.
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 output schema exists, return values are documented. The description covers the main behavior (local commits, authors, churn) and the critical constraint (no remote contact). It could mention the maxCommits limit, but that is in the schema. Completeness is good but not perfect.
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 only 33% (only path has a description). The description does not explain the parameters (maxCommits, includeChurn) or their effect, leaving the agent to infer from the schema. This does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'recent local commits, distinct authors, and churn hotspots', which is specific about the resource and scope. However, it lacks an explicit verb like 'list' or 'get', making it slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for local git history by stating 'Never contacts remotes', but does not explicitly guide when to use this tool over siblings like sdlc_audit_log or sdlc_list_changes. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Language breakdown by file count and bounded line counting, with primary-language detection.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No | ||
| maxFileBytes | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| primaryLanguage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already denote readOnly and idempotent behavior. The description adds 'bounded line counting' and 'primary-language detection,' which are useful behavioral details beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that conveys the core functionality with no redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It covers the main outputs (file count, line count, primary language). However, it omits context about the path parameter's restrictions (from schema) and the numeric bounds, which are relevant for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%; only 'path' is described. The description adds no parameter-level information. For the three parameters, the description does not compensate, leaving interpretation heavily reliant on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides language breakdown by file count and line counting, plus primary-language detection. This is specific and distinguishes it from sibling tools that perform different analyses like repository snapshot or code search.
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. It simply states what it does, leaving the agent to infer from context. Lacks explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recorded, rollback-capable change sets created by the write engine.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| changeCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful context: change sets are 'recorded, rollback-capable' and created by the write engine, giving agents a clearer behavioral model beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and resource. No redundant words; it's optimally brief and 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?
While annotations and output schema provide richness, the description lacks context about how change sets relate to rollback and that the path parameter is used to scope the list. Adequate but could be more explicit.
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 for the single parameter is 100% with a detailed description. The tool description itself does not add parameter semantics, but baseline 3 is appropriate since the schema already explains the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recorded change sets created by the write engine, specifying that they are rollback-capable. This differentiates it from siblings like sdlc_rollback (applies changes) and sdlc_git_history (git-based history). However, it does not explicitly contrast with alternative tools.
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 its siblings. For example, it does not say 'use this to see pending changes before rolling back' or mention that it's not for live file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a plugin manifest, skill metadata, machine-readable skill contracts, and bundled command safety signatures.
| Name | Required | Description | Default |
|---|---|---|---|
| pluginPath | No | Optional plugin root. Defaults to this plugin's root. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| summary | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds specific validation items (manifest, metadata, contracts, signatures), providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no unnecessary words. All 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?
Description sufficiently explains the tool's function. Output schema exists, so return values are handled. However, missing error scenarios or validation outcomes could be added.
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 a description for the single optional parameter. Description adds no extra semantics beyond what the schema provides.
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?
Clearly states the tool validates plugin manifest, metadata, contracts, and signatures. However, it doesn't differentiate from sibling tools like sdlc_doctor or sdlc_read_file, which might have overlapping validation aspects.
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. Missing context on prerequisites (e.g., plugin must be installed) or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded, symlink-safe UTF-8 file read with binary detection, truncation flags, and secret redaction (on by default).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| filePath | Yes | File to act on, relative to the target directory (absolute paths contained by it are accepted). | |
| maxBytes | No | ||
| maxLines | No | ||
| redactSecrets | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safety (readOnly, idempotent, non-destructive). The description adds valuable behavioral details: bounded, symlink-safe, UTF-8, binary detection, truncation flags, secret redaction. No contradiction.
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?
Single sentence, no filler. Every word ('bounded', 'symlink-safe', etc.) adds value. Perfectly concise and 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?
Given complexity (5 params, output schema exists), the description covers key behaviors (safety, truncation, redaction). It does not detail binary detection behavior but that is minor. Output schema covers return info, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (low). The description does not directly explain parameters but indirectly adds meaning via 'bounded' (maxBytes/maxLines) and 'secret redaction' (redactSecrets). It could do more to clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a file with safety features (symlink-safe, binary detection, secret redaction). It is specific and distinguishes from siblings like sdlc_read_files (multiple files) or sdlc_search_code (search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for safe, bounded reads but does not explicitly guide when to use this tool versus alternatives. Sibling tools exist but no comparison or when-not advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded batch read of up to 20 files. Each file gets the same safety treatment as sdlc_read_file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxBytes | No | ||
| maxLines | No | ||
| filePaths | Yes | Files to read, relative to the target directory. | |
| redactSecrets | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| fileCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=true, so the safety profile is clear. The description adds the batch limit (20 files) and notes the same safety treatment as 'sdlc_read_file'. This expands beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no filler. Every word contributes meaning. Well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a 5-parameter tool with defaults and an output schema, the description is minimal but covers the key constraint (batch of 20). It omits details on how 'path' relates to 'filePaths', caps on bytes/lines, and error handling. The existence of an output schema reduces the need to explain return values, but the description still feels incomplete for a batch operation.
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 40% of parameters have schema descriptions, and the tool description adds no individual parameter details. It merely mentions the batch limit, which aligns with the 'filePaths' maxItems. The agent lacks guidance on 'path', 'maxBytes', 'maxLines', and 'redactSecrets' beyond defaults and constraints in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bounded batch read of up to 20 files', which specifies the verb (read), resource (files), and key constraint (batch of up to 20). It also references the sibling 'sdlc_read_file' for safety treatment, distinguishing this batch variant from the single-file tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch reading but does not explicitly state when to use this tool versus alternatives like 'sdlc_read_file' or when not to use it. The reference to 'sdlc_read_file' provides a hint, but lacks clear direction on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only local evidence for release readiness: inventory, documentation, Git state, and whitespace checks. Does not run tests or deploy.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No |
| Name | Required | Description |
|---|---|---|
| checks | No | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond annotations (specific checks performed, read-only nature, no tests/deploy). Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and description aligns fully with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear front-loading: first sentence delivers core purpose and scope, second sentence clarifies exclusions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, read-only, output schema exists), the description fully covers purpose, scope, exclusions, and behavior. No missing information for selecting or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no parameter-specific details. Schema description coverage is 50% (path has a description, maxFiles has default/min/max but no behavioral info). Description does not compensate for this gap.
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?
Explicitly states it provides 'Read-only local evidence for release readiness' listing specific areas (inventory, documentation, Git state, whitespace checks) and explicitly denies running tests or deploying. This clearly distinguishes it from sibling tools like sdlc_risk_score or sdlc_git_history.
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?
Indicates when to use (release readiness checks) and when not (testing/deployment). While it doesn't name specific sibling alternatives, the purpose and exclusions imply appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact-string replacement with occurrence verification. Dry-run unless confirm=true; backs up and audits on apply.
| Name | Required | Description | Default |
|---|---|---|---|
| find | Yes | ||
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| dryRun | No | Explicit dry-run switch. Mutation only occurs when dryRun is false AND confirm is true. | |
| confirm | No | Approval gate. Without confirm=true the call is a dry-run and changes nothing. | |
| replace | No | ||
| filePath | Yes | File to act on, relative to the target directory (absolute paths contained by it are accepted). | |
| allowSensitive | No | ||
| expectedOccurrences | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| changeId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destruction; the description adds critical safety context: dry-run unless confirm=true, backup, audit, and occurrence verification, which fully informs the agent of the tool's guarded behavior.
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 contain all essential information with no redundancy; front-loaded with action and gating.
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 8 parameters and destructive nature, the description covers purpose, gating, and safety, though it could explicitly link 'occurrence verification' to expectedOccurrences parameter.
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 50%; the description does not detail individual parameters but adds meaning by explaining the interaction between dryRun and confirm gates, and mentions occurrence verification, exceeding 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?
The description clearly states the tool performs exact-string replacement with occurrence verification, and distinguishes it from siblings like sdlc_write_file by emphasizing the gated dry-run behavior and backup/audit on apply.
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 when to use (when exact-string replacement with safety and verification is needed) and explains dry-run/confirm gating, but does not explicitly list when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded, read-only inventory of repository structure, delivery signals, symlink/non-UTF-8 counts, and optional Git metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No | ||
| includeGit | No |
| Name | Required | Description |
|---|---|---|
| scanRoot | No | |
| fileCountSampled | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds 'bounded' (max files limit), 'read-only' (matches readOnlyHint), and specific contents (delivery signals, symlink/UTF-8 counts, optional Git metadata) beyond annotations. No contradictions. Could mention that path is restricted (filesystem roots rejected) which is in schema but adds behavioral context.
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?
Single sentence of 15 words, front-loaded with key qualifiers ('Bounded, read-only inventory'). No redundant or filler content. Every word adds value.
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, description does not need to detail return values. It covers main aspects: structure, counts, optional Git metadata. However, it omits mention of the 'path' restriction (rejects filesystem roots, UNC paths require override) which is in schema but not in description.
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 low (33% only for 'path'). Description mentions 'bounded' hinting at maxFiles but does not explain any parameter meaning or provide examples. For a tool with 3 params and low schema coverage, description should compensate but does not.
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?
Description clearly states it's a bounded, read-only inventory of repository structure, delivery signals, symlink/non-UTF-8 counts, and optional Git metadata. It distinguishes from sibling tools like sdlc_directory_tree and sdlc_read_file by specifying the scope and contents. However, 'delivery signals' is vague and not explained.
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 explicit guidance on when to use this tool vs alternatives like sdlc_directory_tree or sdlc_list_changes. The description implies use for comprehensive repo snapshot, but does not state exclusions or when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heuristic 0-100 delivery-risk score with letter grade and weighted evidence factors from read-only signals.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No |
| Name | Required | Description |
|---|---|---|
| grade | No | |
| score | No | |
| riskLevel | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by specifying the output format (0-100 score with letter grade) and methodology (weighted evidence factors). However, it could mention potential performance impact or caching behavior for completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, output, and methodology. Every word earns its place, and it is front-loaded with key 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?
Given the tool's read-only nature, annotations, and existence of an output schema, the description is mostly complete. However, it could better explain the relationship between input parameters and the computed score, and whether the score is real-time or cached.
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?
Input schema has 2 parameters with 50% description coverage: 'path' is described, but 'maxFiles' has no description. The tool description does not elaborate on either parameter, failing to compensate for the missing schema coverage. It provides no additional semantic meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: compute a heuristic 0-100 delivery-risk score with letter grade and weighted evidence factors. It distinguishes from siblings by specifying 'read-only signals', indicating it's a non-destructive analysis tool.
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 explicit guidance on when to use this tool versus alternatives like sdlc_release_readiness or sdlc_repo_snapshot. Usage is only implied by the description of read-only signals, but no when-not or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore files from a recorded change set (or delete files it created). Dry-run unless confirm=true; the rollback itself is audited.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| dryRun | No | Explicit dry-run switch. Mutation only occurs when dryRun is false AND confirm is true. | |
| confirm | No | Approval gate. Without confirm=true the call is a dry-run and changes nothing. | |
| changeId | Yes | Identifier returned by a write operation. |
| Name | Required | Description |
|---|---|---|
| plan | No | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds beyond by specifying the dry-run gate ('Dry-run unless confirm=true') and that the rollback is audited. This provides valuable behavioral context beyond the annotation alone.
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 that efficiently conveys purpose, behavior, and key constraint. Every word earns its place; 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?
With an output schema present, return details are covered elsewhere. The description adequately explains the core action, the dry-run gating, and the audit trail. Minor gaps (e.g., behavior when changeId is invalid) but overall complete for the tool's complexity.
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 parameter descriptions. The description adds overall context about dry-run and confirm interaction, but does not detail each parameter further. Baseline 3 is appropriate as the schema already 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?
The phrase 'Restore files from a recorded change set (or delete files it created)' clearly states the action and resource. It distinguishes from write/read siblings by focusing on reverting changes. The dry-run and audit details add specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rolling back changes with a dry-run by default, but does not explicitly say when to avoid or compare to alternatives like sdlc_write_file. The condition for mutation (confirm=true) is stated but not contextualized against other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded regex search across repository text files with context lines and secret redaction.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| pattern | Yes | ||
| maxFiles | No | ||
| maxResults | No | ||
| filePattern | No | Optional regex to filter relative file paths. | |
| contextLines | No | ||
| maxFileBytes | No | ||
| redactSecrets | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| matchCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: it is a regex search that is bounded, returns context lines, and redacts secrets. This extends beyond annotations without contradicting them. Missing are details on performance or path restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with key action and features. Every word serves a purpose, 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?
While the description covers core functionality, it lacks details on parameter interplay, performance implications of bounds, or how path resolution works. With 8 parameters and an output schema, more context would improve completeness, but existing input schema and annotations provide some scaffolding.
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 25% (only path and filePattern have descriptions). The description does not explain the primary parameter 'pattern' or other critical ones like 'redactSecrets', 'maxFiles', 'maxResults'. Given low coverage, the description fails to compensate by clarifying parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'bounded regex search across repository text files' with 'context lines and secret redaction'. This specifies the verb (search), resource (text files), and unique features, distinguishing it from siblings like sdlc_secret_scan which focuses on secret detection only.
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 explicit guidance on when to use this tool vs alternatives such as sdlc_secret_scan or sdlc_read_file. While the description mentions 'bounded' and 'secret redaction', it does not clarify when a simpler search would suffice or when to prefer other tools for secret scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan text files for secret signatures (tokens, keys, assignments). Findings are always redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| maxFiles | No | ||
| maxFindings | No | ||
| maxFileBytes | No |
| Name | Required | Description |
|---|---|---|
| status | No | |
| findingCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds beyond annotations by stating findings are redacted and implying safe analysis. It also hints at network path restrictions from the schema, providing useful behavioral context.
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, focused sentence that wastes no words. It front-loads the core purpose. A small trade-off is that some usage context is missing, but overall it is appropriately concise.
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 complexity (4 parameters with low schema coverage) and the presence of an output schema, the description could more fully explain the function of parameters and return values. The key behavioral info is present, but completeness for agent decision-making is marginal.
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 only 25% (only 'path' has a description). The description does not elaborate on the purpose or effect of parameters like maxFiles, maxFindings, or maxFileBytes. The baseline is low, and the description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans text files for secret signatures (tokens, keys, assignments). It specifies the resource (text files) and the verb (scan) distinctly, and the mention of 'findings are always redacted' adds clarity. This differentiates it from sibling tools like sdlc_read_file or sdlc_search_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security scanning but provides no explicit guidance on when to use this tool versus alternatives (e.g., sdlc_search_code for general text search). There are no conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create/overwrite/append a UTF-8 text file. Dry-run unless confirm=true; backs up existing content; appends to the audit log; rollback via the returned changeId.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | overwrite | |
| path | No | Target directory. Filesystem roots are rejected; UNC/network paths require an explicit environment override. | |
| dryRun | No | Explicit dry-run switch. Mutation only occurs when dryRun is false AND confirm is true. | |
| confirm | No | Approval gate. Without confirm=true the call is a dry-run and changes nothing. | |
| content | Yes | UTF-8 content (max 1 MiB). | |
| filePath | Yes | File to act on, relative to the target directory (absolute paths contained by it are accepted). | |
| allowSensitive | No | Required to touch .env/key/credential-style paths. | |
| expectedSha256 | No | Optional optimistic-concurrency guard: current file SHA-256. |
| Name | Required | Description |
|---|---|---|
| status | No | |
| changeId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds crucial behavioral details: backup creation, audit log append, and rollback via changeId. These go beyond annotations and fully disclose the tool's side effects and safety mechanisms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences capture the entire tool behavior without fluff. The information is front-loaded, mentioning modes, dry-run, backup, audit, and rollback in order of importance. 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?
Given the tool's complexity (8 parameters, 2 required, output schema exists, 17 siblings), the description covers all critical behavioral aspects: gating, backup, audit, and rollback. It does not need to repeat schema info or explain output structure. The description is self-sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), so the description adds little extra meaning. It reinforces the dry-run logic but does not enhance understanding of individual parameters beyond what the schema already provides. The description does not compensate for the missing mode description or other minor gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates/overwrites/appends UTF-8 text files, distinguishing it from read-only and replace siblings. It specifies the dry-run behavior, backup, audit logging, and rollback capability, leaving no ambiguity about its core function.
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 explains the gated nature (confirm=true required for mutation) and the dry-run default. While it does not explicitly compare with siblings like sdlc_replace_in_file, the context of file creation vs. targeted replacement is implicit. A brief when-not-to-use statement would elevate it to 5.
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.1.0sdlc_audit_logsdlc_dependency_inventorysdlc_directory_treesdlc_doctorsdlc_git_historysdlc_language_statssdlc_list_changessdlc_plugin_preflightsdlc_read_filesdlc_read_filessdlc_release_readinesssdlc_replace_in_filesdlc_repo_snapshotsdlc_risk_scoresdlc_rollbacksdlc_search_codesdlc_secret_scansdlc_write_fileScored across 18 tools
Each tool has a clearly distinct purpose covering different aspects of SDLC: repository inspection, file reading, searching, secret scanning, git history, risk scoring, change management, and rollback. No two tools appear to do the same thing.
All tools share the 'sdlc_' prefix, but the naming conventions vary between verb_noun (e.g., sdlc_read_file) and noun_phrases (e.g., sdlc_repo_snapshot). The pattern is predictable but not perfectly uniform.
18 tools is well-scoped for an SDLC command center, covering read-only analysis, file operations, search, secret detection, git, audit, and rollback. The count feels appropriate for the domain's complexity.
The tool set covers a comprehensive range of operations from inspection to mutation and rollback. A minor gap is the lack of an explicit file deletion tool, though rollback can delete files it created.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
