| name | tools |
| version | 2.0 |
| category | utilities |
| execution_speed | medium |
| token_efficiency | medium |
| triggers | ["what tools should I add?","find me an MCP server","set up tools","audit MCP config","discover tools"] |
| cache_key | tools-2.0 |
| dependencies | [] |
| disable-model-invocation | true |
| description | Scan the active project to discover relevant MCP servers, CLI tools, libraries, and repositories that would benefit it. Presents candidates to the user for approval before implementing anything. Helps configure approved tools in .claude/settings.json. Trigger on: "what tools should I add?", "find me an MCP server for X", "set up tools for this project", "audit my MCP config", "what's missing from my toolset", or any request to discover, add, or review Claude Code tooling for the current project. Backed by Karpathy principles: think first, simplicity, surgical changes only. NEVER auto-implements -- proposes then waits for explicit user approval.
|
Tools -- Project Tool Discovery and Configuration
Project-agnostic tool discovery, recommendation, and configuration for Claude Code.
Scans your codebase to understand what you are building, then finds tools that fit.
Binds to the active project at invocation time.
Initiation
Commands
| Command | What It Does |
|---|
/tools | Show help and project binding status |
/tools scan | Analyze project and surface tool candidates for approval |
/tools add <tool> | Configure or install a specific named tool |
/tools audit | Review tools already configured and flag gaps or risks |
Invariant -- Propose Before You Act
This skill never configures, installs, or modifies anything without explicit user
approval. Every command that could change state ends with a proposal and stops.
The user types approval (or rejection) before any action is taken.
If you are about to write to .claude/settings.json, install a package, or
modify any file: stop, show the full proposed change, and ask.
Project Binding
See .claude/skills/_shared/PROJECT-BINDING.md. Marker = manifest files in the working directory (see below); no CLAUDE.md/AGENTS.md field needed -- read them for tech stack hints instead. Default = working directory itself. State the project root and detected ecosystem once bound.
/tools scan -- Project Analysis and Candidate Discovery
Phase 1 -- Read the Project
Scan these files if present (read-only, no writes):
| File | What to Extract |
|---|
package.json | Runtime (Node/Bun/Deno), frameworks, scripts, devDependencies |
requirements.txt / pyproject.toml | Python version, packages, build system |
ADR-*.md | Project Architectural Design decisions |
Cargo.toml | Rust edition, crates, targets (bin/lib/wasm) |
go.mod | Go version, module path, major dependencies |
README.md | Project description, architecture notes, existing tooling mentioned |
CLAUDE.md | Declared tool preferences, existing MCP config references |
.claude/settings.json | Already-configured MCP servers and hooks |
Produce a one-paragraph ecosystem summary before suggesting anything:
Project: [name or directory]
Ecosystem: [language(s), runtime(s), primary framework(s)]
Existing Claude tooling: [MCP servers already configured, if any]
Key workflows detected: [e.g. "REST API, PostgreSQL, Docker CI"]
If none of the manifest files exist, say so and ask the user to describe the project
before proceeding. Do not guess.
Phase 2 -- Find Candidate Tools
For each tool category relevant to the detected ecosystem, surface 2-5 candidates.
Group by category. For each candidate:
Tool: [name]
Type: [MCP server | CLI | library | VS Code extension | GitHub repo]
What it adds: [One sentence. Be concrete. "Lets Claude query your database directly"
is better than "database integration".]
Install / config: [exact command or config snippet -- don't paraphrase]
Risk level: [LOW | MEDIUM | HIGH] -- HIGH if it can write, deploy, or send data
Source: [URL or package name]
Categories to consider (include only those relevant to the detected ecosystem):
- Database / data access -- MCP servers that give Claude read or write access to
your database. Flag MEDIUM or HIGH risk for write access.
- Version control --
@modelcontextprotocol/server-github, GitLab MCP, etc.
- Search and context -- Brave search MCP, Exa, Perplexity for web-grounded answers.
- Filesystem and editing -- filesystem MCP if not already present.
- Testing and CI -- tools that let Claude run tests, read CI output, or triage failures.
- Documentation -- tools that give Claude access to your docs, API specs, or
external documentation (e.g. Context7).
- Communication -- Slack, Linear, GitHub Issues MCP. Mark these HIGH risk --
they can send messages or create tickets without review.
- Infrastructure -- deployment, container, or cloud tooling. Always HIGH risk.
Phase 3 -- Present for Approval
After listing candidates, ask:
Which of these would you like to add? List by name or number, or say "none".
I will show the exact config change before touching anything.
Stop and wait. Do not proceed until the user responds.
/tools add <tool> -- Add a Specific Tool
Use this when the user already knows what they want.
- State what will change -- show the exact diff to
.claude/settings.json
or the exact install command. Nothing else.
- Flag risks -- if the tool has write, deploy, or send-message capabilities,
call this out explicitly before asking for approval.
- Ask for approval -- one question: "Shall I apply this?" Stop and wait.
- Apply only what was approved -- one tool, one config block, one install.
Do not add "related" tools, do not modify other settings.
- Verify -- after applying, confirm the tool appears in the expected location.
MCP Server Config Template
When configuring an MCP server in .claude/settings.json, the minimal addition is:
"mcpServers": {
"<server-name>": {
"command": "<command>",
"args": ["<arg1>", "<arg2>"],
"env": {
"<ENV_VAR>": "YOUR_VALUE_HERE"
}
}
}
Show the full resulting mcpServers block (not a fragment) so the user can see
exactly what the file will look like after the change.
If the tool requires an API key or secret, use a placeholder like "YOUR_API_KEY_HERE"
and tell the user where to get the real value. Never embed real credentials.
/tools audit -- Review Configured Tooling
Scans .claude/settings.json (and any referenced config files) to review the current
tool setup. Reports per configured tool:
Tool: <server-name>
Status: [ACTIVE | UNUSED | MISCONFIGURED | MISSING-KEY]
Risk: [LOW | MEDIUM | HIGH]
Finding: [One sentence on what was found]
Recommendation: [One sentence on what to do, or "No action needed"]
Then a summary section:
Gaps detected:
- [Tool category that would benefit this project but is not configured]
Risk flags:
- [Any HIGH-risk tool that lacks disable-model-invocation: true]
Suggested next step: [One sentence]
The tools audit never modifies anything. It only reports. If the user wants to act on a
finding, they should use /tools add <tool> or address it manually.
Suggest the user executes obsidian-vault skill next.
Karpathy Principles Applied
See /karpathy for guidelines. Applied here:
- G1: Read the project before suggesting anything. State assumptions from the scan.
- G2: Minimum tool set that solves real gaps. One used tool beats five unconfigured.
- G3: Touch only the config block for the approved tool. Don't reorder or clean up surrounding settings.
- G4 Done: Config applied ✅ · Tool visible in
claude mcp list ✅ · User confirmed response ✅
Integration with Other Skills
/adr -- If adding a tool represents a significant architectural decision
(e.g. choosing a primary MCP database integration), suggest creating an ADR
to document the rationale./audit -- /tools audit focuses on configured tools specifically.
/audit covers the broader skill set. They are complementary./karpathy (internal) -- Governs how this skill reasons. Think before
recommending. Simplest sufficient toolset. Don't touch what wasn't asked about.
