MCP Tool Definition Generator
Build MCP tool definitions using a form. Fill in the tool name, description, and input fields โ get MCP JSON, raw inputSchema, and a TypeScript interface instantly.
Tool Metadata
Use snake_case or camelCase. No spaces. Examples: get_weather, createFile
Human-readable display name shown in MCP client UIs.
Good descriptions explain: what it does, what it returns, when to call it, and any side effects.
0 charsInput Fields0 defined
{
"inputSchema": {
"type": "object",
"properties": {},
"additionalProperties": false
}
}MCP Tool Design Guide
Tool Names
- โบ Use verb-noun pairs: get_user, create_file, search_docs
- โบ Use snake_case or camelCase โ no spaces
- โบ Keep under 64 characters
- โบ Be specific: send_email beats communicate
- โบ Avoid abbreviations unless universal
Descriptions
- โบ Answer: what does it do, what does it return?
- โบ State when the model should and should not call it
- โบ Mention side effects (writes data, sends email)
- โบ Include an example call scenario
- โบ Keep it under ~200 words โ models read every token
Input Schemas
- โบ Describe every property โ models use descriptions to pick values
- โบ Use enum for fixed option sets
- โบ Set defaults for optional fields
- โบ Mark only truly required fields as required
- โบ Always set additionalProperties: false
Output shape reference
{
"name": "search_documents", // machine identifier
"title": "Search Documents", // optional display name
"description": "...", // critical โ tells model when/why to call
"inputSchema": {
"type": "object", // always "object" per MCP spec
"properties": {
"query": {
"type": "string",
"description": "Search query.",
"enum": ["option_a", "option_b"] // optional
}
},
"required": ["query"], // only truly required fields
"additionalProperties": false // always include this
}
} Common mistakes to avoid
Generic description
Writing "a useful tool" or "manages data". The model uses this text to decide when to call your tool โ vague descriptions cause wrong calls or missed calls.
Spaces in tool name
Tool names like "search documents" break some MCP clients. Use search_documents or searchDocuments instead.
Properties without descriptions
Fields without descriptions leave the model guessing what value to pass. Always add a concise description with an example value where possible.
Too many required fields
Only mark a field required if the tool genuinely cannot work without it. Requiring optional fields causes the model to fail unnecessarily.
No additionalProperties: false
Without this, the model can pass arbitrary extra fields. Your handler receives unexpected keys, which complicates validation and causes subtle bugs.
No enum for fixed options
If a field only accepts "low", "medium", or "high", define that as an enum. Without it, the model may pass invalid values like "Low" or "HIGH".
Privacy: This tool runs entirely in your browser. Your tool definitions are not uploaded, stored, or transmitted to any server.
Frequently Asked Questions
What is an MCP tool definition?
How should I name my MCP tool?
What should the tool description contain?
What is inputSchema and why must type be "object"?
When should I mark a field as required?
What are enum values and when should I use them?
What is the TypeScript type tab for?
Why set additionalProperties to false?
Related Tools
MCP Tool Schema Validator
Validate MCP tool definitions โ names, descriptions, inputSchema, required fields, and common mistakes.
OpenAPI to MCP Generator
Convert OpenAPI JSON or YAML specs into MCP tool definitions, input schemas, and TypeScript skeletons.
MCP Server Config Generator
Generate MCP server configuration snippets for Claude Desktop, Cursor, and other clients.