Skills: Tool Binding & Invocation
Last updated: 2026-08-31
Tools are a Skill's hands — which tools you bind determines what a Skill can and cannot do.
1. Tool System Overview
(1) Built-in Tool Categories
| Category | Tool | Capability | Risk Level |
|---|---|---|---|
| Read | Read | Read file contents | 🟢 Low |
| Search | Grep, Glob | Search code patterns | 🟢 Low |
| Write | Write | Create/overwrite files | 🟡 Medium |
| Edit | Edit | Precise file modification | 🟡 Medium |
| Execute | Bash | Run Shell commands | 🔴 High |
| Web | WebFetch | Fetch web content | 🟡 Medium |
(2) MCP Tools
Model Context Protocol (MCP) tools extend AI's capability boundaries:
JSON
// MCP server configuration example
{
"mcpServers": {
"database": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"DATABASE_URL": "postgresql://..."
}
},
"browser": {
"command": "npx",
"args": ["-y", "@anthropic/mcp-browser"]
}
}
}
2. Tool Selection Strategy
(1) Principle of Least Privilege
TEXT
📖 Display only
Task requirement analysis → Determine necessary tools → Only bind necessary tools
Example:
┌─────────────────┬──────────────────────┐
│ Task │ Bound Tools │
├─────────────────┼──────────────────────┤
│ Read-only review│ Read, Grep, Glob │
│ Code fix │ Read, Edit, Bash │
│ Project refactor│ Read, Write, Edit, Bash, Grep │
│ Full auto deploy│ All tools + MCP │
└─────────────────┴──────────────────────┘
(2) Edit vs Write
| Dimension | Edit | Write |
|---|---|---|
| Granularity | Line-precise | Entire file |
| Safety | Only changes specified parts | May overwrite other content |
| Use Case | Bug fix, small adjustments | Create new files, complete rewrites |
| Recommendation | ✅ Prefer | ⚠️ Use with caution |
(3) Safe Use of Bash
MARKDOWN
## Bash Usage Rules
Allowed commands:
- git status, git diff, git log
- npm test, pytest, go test
- ruff check, eslint, prettier
- docker ps, kubectl get
Prohibited commands:
- rm -rf / (dangerous deletion)
- curl | bash (remote script execution)
- Environment variable exports containing secrets
- Commands that modify system configuration
3. Tool Call Optimization
(1) Batch Reading
MARKDOWN
# Inefficient: Read one by one
1. Read src/main.py
2. Read src/utils.py
3. Read src/config.py
# Efficient: Use Glob to determine scope first, then targeted reads
1. Glob "src/**/*.py" → Get file list
2. Read key files (main entry, config, utility functions)
(2) Search First
MARKDOWN
# Inefficient: Blindly read all files
1. Read all .py files (50+ files)
# Efficient: Search to locate first
1. Grep "class.*View" → Find all view classes
2. Grep "TODO|FIXME|HACK" → Find tech debt
3. Only Read files that need deeper inspection from search results
(3) Tool Call Chain
graph TD
A[Glob: Determine file scope] --> B[Grep: Search key patterns]
B --> C[Read: Deep-read target files]
C --> D{Need modification?}
D -->|Yes| E[Edit: Precise modification]
D -->|No| F[Output analysis report]
E --> G[Bash: Verify modification result]
4. Tool Binding Practice
▶ Example 1: Read-Only Analysis Skill
YAML
---
name: tech-debt-scanner
description: "Tech debt scanner, detecting TODO/FIXME/HACK and code smells"
triggers:
- keyword: "tech-debt"
tools:
- Grep
- Glob
- Read
---
# Tech Debt Scanner Skill
## Execution Flow
1. Use Grep to search for TODO, FIXME, HACK comments
2. Use Grep to search for code smell patterns (overly long functions, deep nesting)
3. Use Read to inspect high-priority issues in detail
4. Output tech debt list sorted by priority
▶ Example 2: Auto-Fix Skill
YAML
---
name: lint-fix
description: "Auto-fix code style issues"
triggers:
- keyword: "lint-fix|fix style"
tools:
- Read
- Bash
- Edit
---
# Code Style Fix Skill
## Execution Flow
1. Use Bash to run linter (auto-select based on project type)
2. Analyze linter output
3. For auto-fixable issues, run linter --fix
4. For issues requiring manual fixes, use Edit to fix one by one
5. Use Bash to run linter again for verification
5. Tool Permission Management
(1) Project-Level Permissions
JSON
// .claude/settings.json
{
"permissions": {
"allow": [
"Read(*)",
"Grep(*)",
"Glob(*)",
"Edit(src/**)",
"Bash(npm test,pytest,git *)"
],
"deny": [
"Write(.env*)",
"Bash(rm *)",
"Bash(curl *)"
]
}
}
(2) Skill-Level Permissions
YAML
# Limit tool usage scope in Skill frontmatter
tools:
- Read
- Edit:
paths: ["src/**", "tests/**"]
- Bash:
commands: ["pytest", "ruff check"]
After Alice configured tool permissions for the team, there were never again issues with Skills accidentally deleting files. Bob said: "Permission management isn't about limiting capability — it's about defining safe boundaries so Skills can operate freely within the safety zone."
❓ FAQ
Q What if AI doesn't call a bound tool?
A Explicitly require tool usage in the prompt and provide invocation steps. If AI still doesn't call it, the prompt may not be specific enough or the tool description may not be clear.
Q How to prevent Skills from performing dangerous operations?
A Three layers of protection — least privilege (only bind necessary tools), path restrictions (Edit limited to directories), command allowlist (Bash only allows safe commands).
Q What's the difference between MCP tools and built-in tools?
A Built-in tools come with the AI platform; MCP tools are provided by external services. MCP tools are more capable but more complex to configure, suitable for scenarios requiring external capabilities like databases/browsers.
📖 Summary
- Six tool categories: Read, Search, Write, Edit, Execute, Web
- Least privilege principle: Only bind tools required by the task
- Prefer Edit over Write; prefer search-then-read over blind reading
- Three permission management levels: project-level, Skill-level, tool parameter-level
📝 Exercises
- Basic (⭐): Analyze your existing Skill's tool bindings for over-authorization or insufficient permissions.
- Intermediate (⭐⭐): Create a lint auto-fix Skill with appropriate tool selection and permission settings.
- Advanced (⭐⭐⭐): Design a tool call chain optimization plan and compare call counts and timing before and after optimization.
