Turn a JSON file into an MCP server in one command, so Claude Desktop, Claude Code, Cursor or any stdio MCP client can browse and search your data.
Give it a catalogue, an FAQ, a price list or a docs index, and it creates three read-only tools:
Tool | What it does |
| List records, with |
| Keyword search; every word must match, case-insensitive |
| One record by its id field |
MIT licence. Node.js 20+. Two dependencies: the official @modelcontextprotocol/sdk and zod.
git clone https://github.com/scoretracker4321/json-mcp-lite
cd json-mcp-lite && npm install
npm start # serves examples/products.json on stdio
npm testRelated MCP server: Simple MCP Server
{
"mcpServers": {
"products": {
"command": "node",
"args": [
"/abs/path/json-mcp-lite/src/server.js",
"--file", "/abs/path/products.json",
"--name", "products",
"--id", "sku",
"--search", "title,description"
]
}
}
}Claude Code:
claude mcp add products -- node /abs/path/json-mcp-lite/src/server.js --file /abs/path/products.json --name products --id skuThen ask: "Which teas are under ₹400 and in stock?" or "Show me product MUG-001."
Flag | Default | Meaning |
| (required) | The JSON file |
| root | Dot path to the array inside the file, e.g. |
|
| Tool name prefix: |
|
| Field used by |
| all fields | Comma-separated fields that |
json-mcp-lite is the free, local, single-file part of MCP Server Kit ($29, one-time). The Kit adds:
Any REST API → MCP tools from its OpenAPI 3 spec: one typed tool per operation, auth injected from env, read-only filter, include/exclude lists
Remote hosting over Streamable HTTP (stateless, proxy-friendly), not only stdio
API-key auth and per-key rate limits, CORS, /health and /tools endpoints
Several sources in one server, set up in one YAML/JSON config file
Docker image, an Express router to mount inside your own app, and deploy guides
json-mcp-lite | MCP Server Kit | |
JSON file → list/search/get | ✅ | ✅ |
stdio (Claude Desktop, Cursor, Claude Code) | ✅ | ✅ |
OpenAPI / REST API → tools | ✅ | |
Remote HTTP server | ✅ | |
API keys + rate limits | ✅ | |
Multiple sources, config file | ✅ | |
Docker + deploy docs | ✅ | |
Email support | ✅ |
MIT. Built by Brain Grain (support@braingrain.in).
Fetch a single record from products (5 records; fields: sku, title, description, price, stock) by sku.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds scale (5 records) and the exact fields returned, but says nothing about behavior when a sku does not exist or any auth/lookup constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the parenthetical field list arguably earns its place by telling the agent the record shape. Slightly dense, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only lookup with no output schema, the description supplies the dataset size, the field set, and the key — enough to call it correctly. The only gap is the not-found/error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter meaning. It identifies sku as the lookup key, which is genuine added value, but gives no format, casing, or example, and does not clarify the required-only single-parameter contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch a single record from products') plus the lookup key ('by sku'), so the operation is unambiguous. Sibling differentiation is only implicit from 'single record' versus the names products_list/products_search; no sibling is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by sku' condition implies when this tool applies (known-key lookup) versus enumerating or searching, but no explicit when-to-use or when-not-to-use guidance and no sibling is referenced. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List records from products (5 records; fields: sku, title, description, price, stock). Paginate with limit/offset.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description goes further by disclosing the result shape (sku, title, description, price, stock) and that pagination is required to walk the collection. With no output schema, this field-level disclosure is genuinely useful context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and the returned fields. The '(5 records; ...)' parenthetical is dense and the '5 records' figure is slightly ambiguous clutter, but it is not wasteful overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description adequately covers scope, returned fields, and pagination. It is silent on ordering and total-count behavior, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry meaning for the two parameters, and it does label both as pagination controls. It omits the limits already encoded structurally in the schema (default 20, max 200), which is acceptable since those are machine-readable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List records from products') and enumerates the returned fields, so the agent knows exactly what it gets back. It does not explicitly distinguish itself from the sibling products_search, but the list-vs-search distinction is inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives operational guidance ('Paginate with limit/offset') but never says when to prefer this over products_search or products_get. Usage context is implied by the verb rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over title, description in products (5 records; fields: sku, title, description, price, stock). All words must match (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description usefully adds the matching semantics that annotations cannot express: all words must match and matching is case-insensitive. It also discloses the tiny dataset size (5 records) and the stored fields. It stops short of explaining how limit behaves against a 5-record corpus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the operation, then the scope, then the matching rule. Every clause carries information; only the parenthetical field list is mildly redundant with the output shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the field list (sku, title, description, price, stock) usefully tells the agent what records look like. The only real gap is the undocumented limit parameter and its interplay with the 5-record dataset, which is minor for a read-only two-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It explains query semantics well (all-words match, case-insensitive) but says nothing about the limit parameter or that the default of 10 already exceeds the entire 5-record dataset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (keyword search over products) and narrows the searched fields to title and description. It does not name the siblings products_list or products_get, but the search/list/get distinction is self-evident, so an agent can route without opening another schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'keyword search' but there is no explicit when-to-use or when-not-to-use guidance, and no pointer to products_list for enumerating the full catalog or products_get for retrieval by key. The agent must infer the boundary from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0products_getproducts_listproducts_searchScored across 3 tools
products_list retrieves all records, products_search performs keyword matching, and products_get fetches by primary key. Each tool has a clearly distinct action and return shape, leaving no ambiguity about which to call for a given need.
All three tools follow the same noun_verb pattern: products_list, products_search, products_get. The convention is applied uniformly with no deviations in casing or verb style.
Three tools is a tight, well-scoped surface for a lite JSON data server exposing a single products collection. Each tool earns its place, covering the fundamental read patterns without redundancy.
The read surface is complete for retrieving data: full listing with pagination, keyword search, and single-record lookup by sku. Write operations are absent, but the 'lite' designation implies a read-only toolset, so this is a minor rather than critical gap.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
