agentleFS
patonkikhpatonkikh/APES/skills/mcp/mcp-tool-generator/skill.md

mcp-tool-generator

Skill3 starsChanged 4 months agoMITView on GitHub

Design MCP tools: input/output schemas, handler logic outline, idempotency rules, and agent-facing descriptions for reliable tool invocation. Use when working on MCP servers, MCP tools, MCP clients, or Model Context Protocol integrations.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer read-only tools first.

    line 33
  2. Distinctive:

    Use enums for fixed option sets

    line 62
  3. Distinctive:

    Keep responses token-efficient.

    line 76

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
skill.md

MCP Tool Generator

Purpose

Design MCP tools: input/output schemas, handler logic outline, idempotency rules, and agent-facing descriptions for reliable tool invocation.

Input: Server scope, tool use cases, underlying API capabilities, safety constraints
Output: MCP Tool Design Document per tool with JSON Schema, description, examples, and edge case handling Examples: See examples.md for worked input/output.


Workflow

Step 1: Identify tool candidates

Map agent tasks to tool operations:

Agent taskTool candidateAPI operationRisk level
Search documentssearch_docsGET /searchLow
Delete recorddelete_recordDELETE /items/{id}High

Prefer read-only tools first; defer destructive operations until security review.

Step 2: Define tool contract

Per tool document:

FieldRequirement
namesnake_case, verb_noun pattern (create_issue, list_users)
descriptionWhat it does, when to use, when NOT to use
inputSchemaJSON Schema with required fields and enums
annotationsreadOnly, destructive, idempotent hints (if supported)

Step 3: Design input schema

{
  "type": "object",
  "properties": {
    "query": { "type": "string", "description": "Search query, max 500 chars" },
    "limit": { "type": "integer", "minimum": 1, "maximum": 50, "default": 10 }
  },
  "required": ["query"]
}

Rules:

  • Constrain string lengths and array sizes
  • Use enums for fixed option sets
  • Mark destructive tools explicitly in description

Step 4: Design output format

Return structured JSON text content:

FieldPurpose
successBoolean outcome
dataResult payload
errorStructured error when success=false
metadataPagination cursor, request ID

Keep responses token-efficient; paginate large results.

Step 5: Handle edge cases

CaseBehavior
Empty resultReturn success=true, data=[], message
Rate limitedReturn retryable error with backoff hint
Invalid argsReturn validation error before API call
Partial failure (batch)Return per-item status array
Ambiguous matchReturn candidates; do not auto-select destructive target

Step 6: Validate

Run Validation checklist.


Decision Rules

ConditionAction
Destructive operation (delete, overwrite)Require explicit confirm boolean arg; flag for security review
Tool duplicates existing toolMerge or differentiate with clear description
API returns unstructured textParse and return structured JSON wrapper
Operation is slow (>10s)Return job ID; add separate get_status tool
PII in responseAdd redaction layer; document fields excluded
LLM may hallucinate IDsRequire human-readable label + ID; validate ID format

Validation

  • Each tool has snake_case name following verb_noun pattern
  • Description states when to use and when not to use
  • Input JSON Schema with required fields and constraints
  • Output structure documented with success/error paths
  • Edge cases: empty, rate limit, invalid args covered
  • Destructive tools have confirmation mechanism
  • ≥2 example invocations per tool (happy path + edge case)
  • Token-efficient response design (pagination for lists)

Anti-patterns

  • Vague description — "helps with data" without specifying inputs/outputs.
  • God tool — single tool with 15 optional parameters covering unrelated actions.
  • Raw API passthrough — exposing entire REST API without agent-friendly shaping.
  • Unbounded results — returning thousands of records without pagination.
  • Silent destructive ops — delete without confirmation arg or annotation.

Best Practices

  • One tool = one clear action; compose complex flows in agent workflow.
  • Description written for LLM tool selection (include negative cases).
  • Validate inputs in handler before external API call.
  • Return consistent error schema across all tools.
  • Pair with mcp-security-review before enabling write tools.

Output Structure

# MCP Tool Design: [Server Name]

## Tool: `tool_name`

### Description
[Agent-facing description with use/when-not-use]

### Input Schema
```json
{ ... }

Output Schema

{ ... }

Examples

Happy path

Input: ... Output: ...

Edge case

Input: ... Output: ...

Edge Case Handling

CaseBehavior

Risk Level

[Low / Medium / High]


---

# Next Skills

| Outcome | Recommended Skill |
|---------|-------------------|
| Implement server scaffold | `mcp/mcp-server-generator` |
| Security review for write tools | `mcp/mcp-security-review` |
| Client invocation patterns | `mcp/mcp-client-generator` |
| Production hardening | `mcp/mcp-best-practices` |
| Workflow orchestration | `ai/ai-workflow-builder` |

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.