tool-design

Name: tool-design
Author: muratcankoylan

60installs1.4kforks

How to install tool-design?

muratcankoylan/agent-skills-for-context-engineering/tool-design

$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill tool-design

Installs into the current project.

Summary

This skill should be used for the tool-interface layer of an agent system specifically: writing tool descriptions agents can route on, designing tool schemas and response formats, naming conventions, actionable error recovery messages, MCP server design, tool-set consolidation, a

Files · 1

View on GitHub

SKILL.md

1	# Tool Design for Agents
2
3	Design every tool as a contract between a deterministic system and a non-deterministic agent. Unlike human-facing APIs, agent-facing tools must make the contract unambiguous through the description alone: agents infer intent from descriptions and generate calls that must match expected formats. Every ambiguity becomes a potential failure mode that no amount of prompt engineering can fix.
4
5	The unit of work for this skill is a single tool or a tool catalog. Project-shape, pipeline architecture, task-model-fit, and cost-at-the-project-level decisions belong to `project-development`. Deciding whether to introduce sub-agents belongs to `multi-agent-patterns`. This skill owns the interface layer that connects deterministic code to the agent.
6
7	## When to Activate
8
9	Activate this skill when the unit of work is a tool:
10
11	- Writing a new tool description, schema, or response format.
12	- Debugging cases where the agent picked the wrong tool or generated malformed calls.
13	- Consolidating an overlapping tool catalog (the classic "we have 17 tools, the agent picks wrong half the time" case).
14	- Designing actionable error messages so the agent can self-correct.
15	- Naming tools and parameters consistently across a catalog (MCP namespacing, verb-noun naming).
16	- Evaluating a third-party tool against the consolidation principle before adding it.
17
18	Do not activate this skill for adjacent work owned by other skills:
19
20	- Deciding whether the project should use LLMs at all, or what the pipeline stages should be: `project-development`.
21	- Deciding whether to split work across sub-agents or run a single agent with more tools: `multi-agent-patterns`.
22	- Reducing the token weight of tool outputs at the trajectory level (observation masking, format-option choice at scale): `context-optimization`.
23
24	## Core Concepts
25
26	Design tools around the consolidation principle: if a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better. Reduce the tool set until each tool has one unambiguous purpose, because agents select tools by comparing descriptions and any overlap introduces selection errors.
27
28	Treat every tool description as prompt engineering that shapes agent behavior. The description is not documentation for humans -- it is injected into the agent's context and directly steers reasoning. Write descriptions that answer what the tool does, when to use it, and what it returns, because these three questions are exactly what agents evaluate during tool selection.
29
30	## Detailed Topics
31
32	### The Tool-Agent Interface
33
34	Tools as Contracts
35	Design each tool as a self-contained contract. When humans call APIs, they read docs, understand conventions, and make appropriate requests. Agents must infer the entire contract from a single description block. Make the contract unambiguous by including format examples, expected patterns, and explicit constraints. Omit nothing that a caller needs to know, because agents cannot ask clarifying questions before making a call.
36
37	Tool Description as Prompt
38	Write tool descriptions knowing they load directly into agent context and collectively steer behavior. A vague description like "Search the database" with cryptic parameter names forces the agent to guess -- and guessing produces incorrect calls. Instead, include usage context, parameter format examples, and sensible defaults. Every word in the description either helps or hurts tool selection accuracy.
39
40	Namespacing and Organization
41	Namespace tools under common prefixes as the collection grows, because agents benefit from hierarchical grouping. When an agent needs database operations, it routes to the `db_` namespace; when it needs web interactions, it routes to `web_`. Without namespacing, agents must evaluate every tool in a flat list, which degrades selection accuracy as the count grows.
42
43	### The Consolidation Principle
44
45	Single Comprehensive Tools
46	Build single comprehensive tools instead of multiple narrow tools that overlap. Rather than implementing `list_users`, `list_events`, and `create_event` separately, implement `schedule_event` that finds availability and schedules in one call. The comprehensive tool handles the full workflow internally, removing the agent's burden of chaining calls in the correct order.
47
48	Why Consolidation Works
49	Apply consolidation beca

People who liked this also viewed

6 picks

Type

tool-design

60installs1.4kforks

View on GitHub

How to install tool-design?

muratcankoylan/agent-skills-for-context-engineering/tool-design

$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill tool-design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Tool Design for Agents
2
3	Design every tool as a contract between a deterministic system and a non-deterministic agent. Unlike human-facing APIs, agent-facing tools must make the contract unambiguous through the description alone: agents infer intent from descriptions and generate calls that must match expected formats. Every ambiguity becomes a potential failure mode that no amount of prompt engineering can fix.
4
5	The unit of work for this skill is a single tool or a tool catalog. Project-shape, pipeline architecture, task-model-fit, and cost-at-the-project-level decisions belong to `project-development`. Deciding whether to introduce sub-agents belongs to `multi-agent-patterns`. This skill owns the interface layer that connects deterministic code to the agent.
6
7	## When to Activate
8
9	Activate this skill when the unit of work is a tool:
10
11	- Writing a new tool description, schema, or response format.
12	- Debugging cases where the agent picked the wrong tool or generated malformed calls.
13	- Consolidating an overlapping tool catalog (the classic "we have 17 tools, the agent picks wrong half the time" case).
14	- Designing actionable error messages so the agent can self-correct.
15	- Naming tools and parameters consistently across a catalog (MCP namespacing, verb-noun naming).
16	- Evaluating a third-party tool against the consolidation principle before adding it.
17
18	Do not activate this skill for adjacent work owned by other skills:
19
20	- Deciding whether the project should use LLMs at all, or what the pipeline stages should be: `project-development`.
21	- Deciding whether to split work across sub-agents or run a single agent with more tools: `multi-agent-patterns`.
22	- Reducing the token weight of tool outputs at the trajectory level (observation masking, format-option choice at scale): `context-optimization`.
23
24	## Core Concepts
25
26	Design tools around the consolidation principle: if a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better. Reduce the tool set until each tool has one unambiguous purpose, because agents select tools by comparing descriptions and any overlap introduces selection errors.
27
28	Treat every tool description as prompt engineering that shapes agent behavior. The description is not documentation for humans -- it is injected into the agent's context and directly steers reasoning. Write descriptions that answer what the tool does, when to use it, and what it returns, because these three questions are exactly what agents evaluate during tool selection.
29
30	## Detailed Topics
31
32	### The Tool-Agent Interface
33
34	Tools as Contracts
35	Design each tool as a self-contained contract. When humans call APIs, they read docs, understand conventions, and make appropriate requests. Agents must infer the entire contract from a single description block. Make the contract unambiguous by including format examples, expected patterns, and explicit constraints. Omit nothing that a caller needs to know, because agents cannot ask clarifying questions before making a call.
36
37	Tool Description as Prompt
38	Write tool descriptions knowing they load directly into agent context and collectively steer behavior. A vague description like "Search the database" with cryptic parameter names forces the agent to guess -- and guessing produces incorrect calls. Instead, include usage context, parameter format examples, and sensible defaults. Every word in the description either helps or hurts tool selection accuracy.
39
40	Namespacing and Organization
41	Namespace tools under common prefixes as the collection grows, because agents benefit from hierarchical grouping. When an agent needs database operations, it routes to the `db_` namespace; when it needs web interactions, it routes to `web_`. Without namespacing, agents must evaluate every tool in a flat list, which degrades selection accuracy as the count grows.
42
43	### The Consolidation Principle
44
45	Single Comprehensive Tools
46	Build single comprehensive tools instead of multiple narrow tools that overlap. Rather than implementing `list_users`, `list_events`, and `create_event` separately, implement `schedule_event` that finds availability and schedules in one call. The comprehensive tool handles the full workflow internally, removing the agent's burden of chaining calls in the correct order.
47
48	Why Consolidation Works
49	Apply consolidation beca

People who liked this also viewed

6 picks

Type