tool-design skillA
tool-design is agent-read markdown (skill) from nahid-sparktales/agent-dispatcher: Design the tools a model calls — names, parameter shapes, what a result returns, and error text written as an instruction the model can act on. Use when adding or reshaping a tool or function an LLM invokes, when an agent keeps calling the wrong tool or passing malformed arguments, or when reviewing a tool surface someone else defined. Not for building the MCP server that hosts the tools (mcp-design), not for forcing a model's final answer into a schema (structured-output), and not for prompt wo.
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Tool design A tool definition is a prompt. The model never sees your implementation — it sees the name, the description, the parameter schema, and whatever came back last time. Most "the model is bad at using tools" is a tool that told the model the wrong thing. ## When this fires Adding a tool to an agent, changing an existing tool's parameters or return value, or diagnosing an agent that picks the wrong tool, passes bad arguments, loops, or stalls after a call. It does not fire for an internal function no model ever invokes. ## Procedure 1. **Start from the task, not the API.** List the things the agent must accomplish, then define one tool per accomplishment. A thin one-to-one wrapper over an existing HTTP API pushes the orchestration into the model, which pays for it in extra turns and wrong guesses. Prefer one `schedule_meeting` over `list_calendars` + `get_availability` + `create_event` unless the agent genuinely needs the intermediate steps. 2. **Count the tools.** A large, overlapping surface is the main cause of wrong-tool selection. If two tools could plausibly answer the same request, either merge them or make each description …
Read the whole file at its exact version.
How to install
mdr add nahid-sparktales/agent-dispatcher/tool-design@git:20260919.a0d4f55mdr add nahid-sparktales/agent-dispatcher/tool-design@sha256:3000f57464a3166ePin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_uknmmb54misisyii)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (7156 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
nahid-sparktales/agent-dispatcher · 49 stars · license MIT · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_uknmmb54misisyii GET https://markdownregistry.com/api/v1/resolve?ref=nahid-sparktales/agent-dispatcher/tool-design GET https://markdownregistry.com/api/v1/blob/3000f57464a3166ea797b412aae380da386e5d4b9eea01c38845a86affc504b2
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
More from nahid-sparktales/agent-dispatcher
Every file in nahid-sparktales/agent-dispatcher