
Tool Design
- 54 installs
- 7 repo stars
- Updated January 15, 2026
- eyadsibai/ltk
Helps with design & ui/ux tasks.
About
tool-design is a Claude Code skill for design & ui/ux. It helps solo builders move faster with AI-assisted development.
- tool-design
- Design & UI/UX
- AI-coding skill
Tool Design by the numbers
- 54 all-time installs (skills.sh)
- Ranked #1,228 of 1,880 Design & UI/UX skills by installs in the Skillselion catalog
- Data as of Jul 30, 2026 (Skillselion catalog sync)
npx skills add https://github.com/eyadsibai/ltk --skill tool-designAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 54 |
|---|---|
| repo stars | ★ 7 |
| Last updated | January 15, 2026 |
| Repository | eyadsibai/ltk ↗ |
What it does
Helps with design & ui/ux tasks.
Files
Tool Design for Agents
Tools define the contract between deterministic systems and non-deterministic agents. Poor tool design creates failure modes that no amount of prompt engineering can fix.
The Consolidation Principle
If a human engineer cannot definitively say which tool should be used, an agent cannot do better.
Instead of: list_users, list_events, create_event Use: schedule_event (finds availability and schedules)
Tool Description Structure
Answer four questions:
1. What does the tool do? 2. When should it be used? 3. What inputs does it accept? 4. What does it return?
Well-Designed Tool Example
def get_customer(customer_id: str, format: str = "concise"):
"""
Retrieve customer information by ID.
Use when:
- User asks about specific customer details
- Need customer context for decision-making
- Verifying customer identity
Args:
customer_id: Format "CUST-######" (e.g., "CUST-000001")
format: "concise" for key fields, "detailed" for complete record
Returns:
Customer object with requested fields
Errors:
NOT_FOUND: Customer ID not found
INVALID_FORMAT: ID must match CUST-###### pattern
"""Poor Tool Design (Anti-pattern)
def search(query):
"""Search the database."""
passProblems: Vague name, missing parameters, no return description, no usage context, no error handling.
Architectural Reduction
Production evidence shows: fewer, primitive tools can outperform sophisticated multi-tool architectures.
File System Agent Pattern: Provide direct file system access instead of custom tools. Agent uses grep, cat, find to explore. Works because file systems are well-understood abstractions.
When reduction works:
- Data layer well-documented
- Model has sufficient reasoning
- Specialized tools were constraining
- Spending more time maintaining scaffolding than improving
MCP Tool Naming
Always use fully qualified names:
# Correct
"Use the BigQuery:bigquery_schema tool..."
# Incorrect (may fail)
"Use the bigquery_schema tool..."Response Format Optimization
format: str = "concise" # "concise" | "detailed"Let agents control verbosity. Concise for confirmations, detailed when full context needed.
Error Message Design
Design for agent recovery:
{
"error": "NOT_FOUND",
"message": "Customer CUST-000001 not found",
"suggestion": "Verify customer ID format (CUST-######)"
}Tool Collection Guidelines
- 10-20 tools for most applications
- Use namespacing for larger collections
- Ensure each tool has unambiguous purpose
- Test with actual agent interactions
Anti-Patterns
- Vague descriptions: "Search the database"
- Cryptic parameters:
x,val,param1 - Missing error handling: Generic errors
- Inconsistent naming:
idvsidentifiervscustomer_id
Best Practices
1. Write descriptions answering what, when, returns 2. Use consolidation to reduce ambiguity 3. Implement response format options 4. Design error messages for recovery 5. Establish consistent naming conventions 6. Test with actual agent interactions 7. Question if tools enable or constrain reasoning 8. Build minimal architectures for model improvements