tools

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.

1. State what will change -- show the exact diff to .claude/settings.json or the exact install command. Nothing else.
2. Flag risks -- if the tool has write, deploy, or send-message capabilities, call this out explicitly before asking for approval.
3. Ask for approval -- one question: "Shall I apply this?" Stop and wait.
4. Apply only what was approved -- one tool, one config block, one install. Do not add "related" tools, do not modify other settings.
5. 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.