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 chars

Input Fields0 defined

stringnumberintegerbooleanarrayobject
{
  "inputSchema": {
    "type": "object",
    "properties": {},
    "additionalProperties": false
  }
}
Generated in your browser. Nothing is uploaded.

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?
A Model Context Protocol (MCP) tool definition is a JSON object that exposes a capability to an AI assistant. It contains a name (machine identifier), description (tells the model when and why to use it), and an inputSchema (a JSON Schema object describing what arguments the tool accepts). When an AI like Claude decides a tool is relevant, it reads the definition to know how to call it correctly.
How should I name my MCP tool?
Use snake_case (get_weather, create_ticket) or camelCase (getWeather, createTicket). Avoid spaces โ€” some MCP clients cannot parse names with spaces. Keep names under 64 characters. Make the name a verb-noun pair that describes the action: get_, create_, search_, update_, delete_. Avoid abbreviations unless they are universally understood.
What should the tool description contain?
The description is the single most important field for correct model behavior. Write it from the model's perspective. A good description answers: (1) What does this tool do? (2) What does it return? (3) When should I call it? (4) Are there any side effects or restrictions? Example: "Searches the company knowledge base for relevant articles. Returns up to 10 results with title, excerpt, and URL. Call when the user asks a question that may be answered by internal documentation."
What is inputSchema and why must type be "object"?
inputSchema is a JSON Schema that describes the arguments the tool accepts. The MCP specification requires its type to be "object" because all tool arguments are passed as a JSON object (key-value pairs). Even if your tool takes no arguments, you still need: { "type": "object", "properties": {} }.
When should I mark a field as required?
Mark a field required if the tool cannot function without it. Optional fields should have sensible defaults where possible โ€” specify the default in the "default value" field so the model knows what value will be used if the field is omitted. Having too many required fields frustrates models; having too few can lead to incomplete tool calls.
What are enum values and when should I use them?
Enum values constrain a field to a specific set of allowed values. Use them whenever a field has a fixed set of valid inputs โ€” status fields, category selectors, unit preferences. Adding enum values helps the model pick the right value rather than guessing, and prevents invalid inputs from reaching your tool handler.
What is the TypeScript type tab for?
The TypeScript Type tab generates an interface that matches the inputSchema. You can paste it directly into your MCP server implementation to get type-safe access to the tool's arguments. The interface uses optional properties (?) for non-required fields, string unions for enum fields, and appropriate TypeScript primitives for each JSON Schema type.
Why set additionalProperties to false?
The generator always sets additionalProperties: false in the output. This tells the model not to pass extra fields that aren't defined in properties. It makes tool calls predictable, simplifies server-side validation, and avoids confusion when the model hallucinates argument names.