Developer ToolsFree generatorPDF, Excel, Word export

MCP Server Tool Definition JSON Generator

An MCP server exposes each capability as a tool: a name, a description the model reads, and a JSON Schema for its input. This generator builds that definition for an ERP lookup so you can paste it into your server and adjust.

Fill in

Tool name

Use snake_case. Model clients show this name to the LLM.

Display title

Description for the model

Main parameter name

Parameter description

Parameter regex pattern

Max line rows returned

Read only hint

Destructive hint

Generated code

Download:

MCP tool definition

{
  "name": "get_sales_order_status",
  "title": "Get sales order status",
  "description": "Returns header status, promise date and open line count for one sales order. Read-only. Use when the user asks where an order stands.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_number": {
        "type": "string",
        "description": "ERP sales order number, for example SO-100245.",
        "pattern": "^SO-[0-9]{4,8}$"
      },
      "max_lines": {
        "type": "integer",
        "minimum": 1,
        "maximum": 50,
        "default": 10,
        "description": "Maximum order lines to return."
      }
    },
    "required": ["order_number"],
    "additionalProperties": false
  },
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  }
}

Paste the object into the tools array returned by your server for tools/list. Annotations are hints for clients, not enforcement: always enforce permissions and row limits in the server code and in the ERP role the server connects with. Check the field names against the MCP specification revision your SDK implements.

Review my MCP tool definitions

Optional: send your tool list and we will comment on naming, schemas, permissions and token cost.

Optional. The tool and every export work without this. No spam.

How to use the generator

Pick a snake_case tool name that reads like an action, then write the description as if briefing a new analyst: what it returns, when to use it and what it will not do. Add the main parameter with a regex pattern so malformed ids are rejected before they reach the ERP. Set the read-only and destructive hints honestly, then copy the JSON into the tools list your server returns from tools/list. Export to PDF or Word if you need it in a design review.

One tool, one job: avoid a single run_query tool for everything
Cap list outputs with a maximum in the schema
Describe units, date formats and id formats in parameter text

The structure behind it

A tool definition has a unique name, an optional human title, a description, an inputSchema that must be a JSON Schema object, and optional annotations such as readOnlyHint, destructiveHint, idempotentHint and openWorldHint. The model sees the name, description and schema in its context, so every word costs tokens on each request. Keep descriptions short and concrete. Setting additionalProperties to false stops the model from inventing parameters your server then has to ignore or reject.

Worked example for an ERP

The defaults describe a sales order status tool for SyteLine, NetSuite or any ERP with an order table. The pattern limits input to ids like SO-100245, and max_lines is bounded at 50. A model that asks for order 'the big one from Tuesday' is forced to resolve an id first, perhaps through a separate search tool. That separation keeps each tool simple to test and simple to permission.

Common mistakes

The usual faults are vague descriptions, missing required lists, free text parameters that go straight into SQL, and annotations that claim read-only for tools that write. Another is returning entire tables: the model context fills up and answers degrade. Treat the schema as a contract, validate on the server anyway, and log each call with the user it was made for.

Frequently Asked Questions

Is the description really that important?

Yes. The model chooses tools almost entirely from the name and description. A precise description that states what the tool returns and when not to use it reduces wrong calls more than any other change you can make.

Do annotations enforce anything?

No. Annotations such as readOnlyHint are hints that clients may use to decide whether to ask for confirmation. Enforcement must live in your server and in the database or ERP role it uses.

Which JSON Schema features can I use?

Type, properties, required, enum, pattern, minimum, maximum, default and description are widely supported. Avoid exotic keywords like complex oneOf trees, since client support varies and they add token cost.

Should I generate one tool per ERP table?

Usually not. Tools shaped around user questions, such as order status or open purchase orders by supplier, work better than raw table access and are easier to secure and test.

If you want MCP tools wired to your ERP with roles, row limits and an audit log, Netray can review your definitions or build the server on your infrastructure.

Talk to an Expert Explore More Free Tools

Related Tools

Developer Tools

More Developer Tools tools

See all

Back to All Tools