Give Claude Skills and Tools: MCP, APIs, Databases and Git
In the previous article, Build Your First Agentic Workflow with Claude and VS Code, we created the foundation of our agentic development environment.
We created:
PRODUCT.md → WORKFLOW.md → CLAUDE.md
and used Claude Code as our development agent.
Now we will improve that system by giving Claude more specialized capabilities through Skills and Tools.
The goal is to move from:
Claude can understand our instructions
to:
Claude can understand
↓
choose a skill
↓
select a tool
↓
perform an action
↓
inspect the result
↓
decide what to do next
This is the T — Tools part of our WAT architecture, but Skills are also important because they help Claude know how to perform specialized work.
1. Where We Are in Our WAT Project
Our current architecture looks like this:
StyleFlow Goal
↓
PRODUCT.md
↓
WORKFLOW.md
↓
CLAUDE.md
↓
Claude Code
↓
Basic VS Code Tools
Claude already has project instructions.
But our future StyleFlow application will require different types of expertise:
UI design
Frontend development
Backend development
Database design
Testing
Security
Git
APIs
Deployment
Instead of putting every instruction into one huge prompt, we can organize these responsibilities.
Our improved architecture will become:
WORKFLOW
↓
CLAUDE AGENT
↓
Selects appropriate skill
↓
Selects appropriate tool
↓
ACTION
↓
RESULT
↓
EVALUATE
2. What Is an AI Agent Skill?
A Skill is reusable specialist guidance that helps an agent perform a particular type of task.
For example, suppose Claude needs to design our StyleFlow database.
We could put all database instructions directly inside every prompt:
Use primary keys.
Use foreign keys.
Consider indexes.
Preserve order prices.
Validate relationships.
...
But this quickly becomes repetitive.
Instead, we create a reusable:
Database Design Skill
Then when Claude performs database work, it can use those instructions.
Conceptually:
Claude
↓
Task:
Design product and order database
↓
Database Design Skill
↓
Apply database rules
↓
Create implementation
Agent Skills are designed to package reusable instructions and supporting resources that an agent can use for specialized tasks.
3. Skills Are Different from Tools
This distinction is very important.
A Skill tells the agent how to perform a task.
A Tool allows the agent to perform an action.
For example:
SKILL
Database Design
Teaches Claude:
- how to design tables
- how to create relationships
- how to preserve data integrity
But:
TOOL
Database connection
Allows Claude to:
- query database
- create tables
- inspect schema
- test data
Another example:
SKILL
Testing
Teaches:
How to design useful tests
How to investigate failures
while:
TOOL
pytest
Allows:
Actually running those tests
We can summarize this as:
Skill = Knowledge + Instructions
Tool = Action + Capability
4. Create the Skills Folder
Inside our StyleFlow project, create:
skills/
Our project can now look like:
styleflow-wat/
│
├── PRODUCT.md
├── WORKFLOW.md
├── CLAUDE.md
├── README.md
│
├── skills/
│ ├── ui-design/
│ ├── frontend-development/
│ ├── backend-development/
│ ├── database-design/
│ ├── testing/
│ ├── security-review/
│ └── deployment/
│
├── docs/
└── tests/
Each skill can contain a SKILL.md.
For example:
skills/
└── database-design/
└── SKILL.md
5. Create the Database Design Skill
Create:
skills/database-design/SKILL.md
Add:
# Database Design Skill
Use this skill when creating or modifying
persistent application data.
## Responsibilities
When designing a database:
- identify entities
- identify relationships
- define primary keys
- define foreign keys
- choose appropriate data types
- add useful constraints
- preserve data integrity
- consider indexes for common queries
## E-Commerce Rules
For StyleFlow consider entities such as:
- Category
- Product
- Customer
- Order
- OrderItem
Historical order information must not change
when a product changes later.
OrderItem should therefore preserve important
purchase-time information such as:
- product name
- unit price
- selected size
- quantity
## Safety
Do not delete existing persistent data unless
the task explicitly requires it and human approval
has been provided when appropriate.
## Output
Document important schema decisions in:
docs/decisions.md
This gives Claude specialized database instructions.
6. Why Preserve the Order Price?
Suppose StyleFlow sells a jacket today for:
999 SEK
A customer buys it.
Three months later, the store changes its price to:
1,299 SEK
The historical customer order must still show:
999 SEK
Therefore, our OrderItem should store the price that applied when the purchase occurred.
The database might conceptually contain:
Product
-------
id
name
current_price
stock
OrderItem
---------
order_id
product_id
product_name
unit_price
size
quantity
This is an example of why a specialist database Skill is useful.
7. Create a Testing Skill
Next create:
skills/testing/SKILL.md
Add:
# Testing Skill
Use this skill when creating or reviewing tests.
## Goals
Test important application behaviour rather
than only implementation details.
For StyleFlow test:
- product listing
- product search
- product details
- add to cart
- update cart
- remove from cart
- checkout validation
- order creation
- invalid product IDs
- important database behaviour
## When Tests Fail
1. Read the complete failure.
2. Identify the probable root cause.
3. Inspect the relevant implementation.
4. Correct the implementation when appropriate.
5. Run the failed test again.
6. Run related tests.
7. Run the full suite before completion.
Do not change a valid test only to make it pass.
Now Claude has specialist instructions for dealing with tests.
8. Create a Security Review Skill
Create:
skills/security-review/SKILL.md
Add:
# Security Review Skill
Use this skill when reviewing application security.
## Review Areas
Check:
- external input validation
- authentication
- authorization
- secrets
- environment variables
- database queries
- session handling
- admin routes
- error messages
- file uploads
- API input
- payment-related code
## Rules
Never expose:
- passwords
- API keys
- access tokens
- private credentials
Never commit secrets to Git.
Important production security decisions should
remain under human review.
Now the agent can use a different specialist perspective when reviewing security.
9. Claude Selects Skills According to the Task
Imagine our workflow reaches:
Design database
Claude can apply:
database-design
Later:
Create product page
it can use:
ui-design
+
frontend-development
Then:
Run application tests
it uses:
testing
Finally:
Review security
it uses:
security-review
Conceptually:
CLAUDE
│
What task am I doing?
│
┌─────────────┼──────────────┐
▼ ▼ ▼
Database UI Testing
│ │ │
DB Skill UI Skill Test Skill
│ │ │
└─────────────┼──────────────┘
↓
Perform work
This makes our agent easier to extend.
10. Tools Let Claude Take Action
Skills are useful, but the agent also needs Tools.
Our development environment can provide:
Claude
│
├── Files
├── Terminal
├── Git
├── Test runner
├── Database
├── APIs
├── GitHub
└── MCP tools
Each one gives Claude a different capability.
11. Files as a Tool
One of the most important tools is file access.
Claude can work with:
PRODUCT.md
WORKFLOW.md
CLAUDE.md
Python files
HTML templates
CSS
Tests
Configuration
Documentation
For example, Claude may:
Read models.py
↓
Read test_orders.py
↓
Find inconsistency
↓
Modify models.py
↓
Run tests
This creates a feedback loop based on the actual project rather than only on information copied into a chat.
12. Terminal as a Tool
The terminal allows the agent to execute development commands.
Examples include:
python app.py
or:
pytest
or:
pip install -r requirements.txt
The terminal turns Claude from something that merely suggests commands into an agent that can use commands within the permissions of its environment.
For example:
Claude modifies code
↓
Runs pytest
↓
Receives:
2 failed, 17 passed
↓
Reads errors
↓
Changes code
↓
Runs pytest again
The terminal therefore provides important feedback.
13. Git as a Tool
Git is especially valuable when working with an AI development agent.
Before Claude changes many files, Git gives us a known checkpoint.
For example:
git status
shows the current state.
After Claude changes the project:
git diff
shows exactly what changed.
If the work is correct:
git add .
git commit -m "Add product catalogue foundation"
Now we have another checkpoint.
The pattern becomes:
Working version
↓
Git checkpoint
↓
Claude changes code
↓
Tests
↓
Human review
↓
Commit
This gives us much more control than allowing large AI-generated changes without version history.
14. Git and GitHub Are Not the Same Thing
Git and GitHub are related, but they are different.
Git is the version-control system used on the local computer.
For example:
git status
git diff
git add
git commit
GitHub is an online service where Git repositories can be stored and shared.
The workflow might be:
VS Code
↓
Local Git repository
↓
Commit
↓
Push
↓
GitHub repository
Later, Claude can also work with GitHub-related tooling, for example to inspect repository information or participate in development workflows, depending on which integrations and permissions we configure.
15. Databases as Tools
Our StyleFlow application needs persistent information.
For example:
Products
Categories
Orders
Order items
Customers
Inventory
At first, we may use SQLite for local development.
Later, a commercial version may use PostgreSQL.
Conceptually:
Claude Agent
↓
Database Skill
↓
Database Tool
↓
Inspect schema
↓
Create or modify model
↓
Run application
↓
Query result
The database gives the agent real data feedback.
For example:
Expected:
Product stock = 12
Actual:
Product stock = -1
The agent can inspect the relevant business logic and identify a possible inventory problem.
16. APIs as Tools
An API lets one software system communicate with another.
Our future StyleFlow store may need APIs for:
Payments
Shipping
Email
SMS
Product import
Currency
Analytics
For example:
StyleFlow
↓
Payment API
↓
Payment provider
or:
StyleFlow
↓
Email API
↓
Send order confirmation
A future agent could use these services through carefully defined tools.
For example:
send_order_confirmation(order_id)
check_shipping_status(order_id)
get_product_inventory(product_id)
The important idea is that the AI should not need unrestricted access to an entire external system.
It should receive appropriately scoped tools for the actions it needs.
17. What Is MCP?
As the number of external tools grows, integrations can become complicated.
MCP stands for Model Context Protocol.
MCP provides a standardized way for AI applications and agents to connect to external tools, data sources and services.
Instead of creating a completely different integration pattern for every service, MCP provides a common protocol.
Conceptually:
CLAUDE
↓
MCP
↓
┌──────────┼───────────┐
▼ ▼ ▼
GitHub Database External
Service
Anthropic’s Claude platform supports connecting Claude to MCP servers and exposing their tools to the model. Current API support also allows individual MCP tools to be controlled through allowlists or denylists, which is useful for limiting what an agent can access.
18. Why MCP Is Useful
Imagine we want our agent to work with:
GitHub
PostgreSQL
Customer database
Email system
Deployment system
Without a common integration approach:
Claude → custom GitHub integration
Claude → custom database integration
Claude → custom email integration
Claude → custom deployment integration
With MCP, the architecture can become:
Claude
↓
MCP
↓
┌────────────┼────────────┐
▼ ▼ ▼
GitHub Database Email
MCP does not make every external service automatically safe or trustworthy.
We still need to decide:
- which MCP server to use,
- what tools it exposes,
- what credentials it receives,
- and what actions Claude is allowed to perform.
19. MCP Server and MCP Client
Two terms are useful to understand.
MCP Server
The server exposes capabilities.
For example:
PostgreSQL MCP Server
Tools:
query_database()
inspect_schema()
list_tables()
or:
GitHub MCP Server
Tools:
read_repository()
list_issues()
create_issue()
MCP Client
The client is the application connecting to the server.
Conceptually:
Claude Code
│
│ MCP Client
↓
MCP Server
↓
External Service
This allows the agent to discover and call the tools made available through that server.
20. Tool Permissions Are Important
Suppose we connect Claude to our database.
We could theoretically provide:
read_products()
create_product()
update_product()
delete_everything()
That would not be a good first design.
Instead, apply the principle of least privilege.
For development, perhaps Claude receives:
✓ inspect_schema
✓ read_test_data
✓ create_development_tables
✓ update_development_data
but not:
✗ delete_production_database
Similarly, for Git:
✓ git status
✓ git diff
✓ local commit
may be acceptable in our development workflow.
But:
production deployment
should remain behind human approval.
21. Create a Tool Policy for StyleFlow
We can add a section to CLAUDE.md.
For example:
## Tool Policy
You may use development tools to:
- read project files
- modify project files
- run local development commands
- run automated tests
- inspect Git status
- inspect Git diffs
- work with the local development database
Request human approval before:
- pushing destructive changes
- deleting persistent production data
- changing production infrastructure
- performing real payments
- using production credentials
- deploying publicly
This makes our expectations explicit.
Current Claude prompting guidance also recommends explicit boundaries for agentic systems rather than assuming the model will infer how much autonomy it should exercise.
22. Improve Our Workflow with Skills and Tools
We can now improve our original development workflow.
Previously:
Read requirements
↓
Plan
↓
Implement
↓
Test
Now:
Read requirements
↓
Determine task
↓
Select Skill
↓
Select Tool
↓
Perform action
↓
Observe result
↓
Evaluate
↓
Continue?
For example:
TASK:
Create StyleFlow order database
↓
Select:
Database Design Skill
↓
Use:
Project files
Database
Terminal
↓
Create models
↓
Run migrations/setup
↓
Run tests
↓
Tests fail?
YES
↓
Testing Skill
↓
Inspect failure
↓
Fix
↓
Test again
This is becoming a real agentic workflow.
23. Example: Claude Builds a Product Feature
Imagine we give Claude:
Add product search to StyleFlow.
Follow PRODUCT.md, WORKFLOW.md and CLAUDE.md.
Use relevant project skills.
Implement the feature, test it, and report the result.
Claude may internally approach the task like this:
Understand requirement
↓
Inspect existing product routes
↓
Use backend-development guidance
↓
Inspect product model
↓
Implement search
↓
Use testing guidance
↓
Create tests
↓
Run pytest
↓
Failure?
/ \
Yes No
↓ ↓
Fix Review
↓
Test again
The exact implementation path may differ depending on the current project.
That is what makes it agentic.
24. Skills Should Not Become Hundreds of Tiny Files
It is possible to overcomplicate Skills.
For StyleFlow, we do not need:
button-color-skill
heading-skill
product-name-skill
footer-skill
That would create unnecessary complexity.
Instead, use meaningful areas of expertise:
ui-design
frontend-development
backend-development
database-design
testing
security-review
deployment
A Skill should represent a useful reusable capability.
25. Tools Should Also Be Purposeful
The same rule applies to tools.
More tools do not automatically create a better agent.
An agent with:
100 poorly described tools
can be harder to control than an agent with:
10 well-designed tools
A good tool should have a clear purpose.
For example:
get_product(product_id)
is clear.
Something generic such as:
do_database_thing(data)
is much less useful.
Tools should make it obvious:
- what action they perform,
- what input they require,
- and what result they return.
26. Our Improved StyleFlow Architecture
We now have:
PRODUCT.md
↓
WORKFLOW.md
↓
CLAUDE.md
↓
CLAUDE AGENT
│
Selects Skills
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
Database Skill Testing Skill Security Skill
│ │ │
└───────────────────┼───────────────────┘
↓
TOOLS
│
┌─────────┬─────────┼─────────┬───────────┐
▼ ▼ ▼ ▼ ▼
Files Terminal Git Database MCP
│
┌────────┼────────┐
▼ ▼ ▼
APIs GitHub Services
This is much closer to a complete WAT-based development system.
27. What We Have Learned
In this article, we added two important layers to our Claude development agent.
First, we added Skills.
Skills provide reusable specialist instructions such as:
Database design
Testing
Security
UI design
Backend development
Second, we added Tools.
Tools allow Claude to perform actions through:
Files
Terminal
Git
Database
APIs
MCP
The relationship is:
Workflow
↓
Agent
↓
Skill
↓
Tool
↓
Action
↓
Result
↓
Agent evaluates result
This is the foundation we need before asking Claude to build a larger real-world application.
28. What Comes Next?
We now have almost everything needed to begin our main practical project.
In the next article, we will build:
StyleFlow — an Online Clothing Store with an Agentic Workflow
Instead of discussing only theory, we will use our WAT architecture to create the actual application.
Claude will work from our product requirements and workflow to create features such as:
Products
Categories
Search
Product details
Shopping cart
Checkout
Orders
Database
Admin area
Automated tests
We will examine what Claude creates, how it makes implementation decisions, how tests provide feedback, and how we remain in control of the final result.
Conclusion
An intelligent agent becomes much more useful when it has both specialized guidance and controlled capabilities.
We can now think of our complete system as:
GOAL
↓
WORKFLOW
↓
CLAUDE AGENT
↓
SKILLS
↓
TOOLS
↓
ACTION
↓
FEEDBACK
↓
NEXT DECISION
This is the heart of practical agentic automation.
Claude provides reasoning and decision-making.
Skills provide specialist instructions.
Tools provide access to real actions and systems.
The workflow connects everything together and defines how the work should progress.
Our next step is to use this architecture to build a complete practical application.
→ Next Article: Build StyleFlow: An Online Clothing Store with an Agentic Workflow