Tanod MCP server

mlpeek: extract structured JSON from text under your JSON Schema (small open model, CPU)

extract_json_with_schema

Read-onlyIdempotent

Extract JSON from text that always validates against your JSON Schema, so agents get structured data from invoices, job posts, or pages.

Instructions

mlpeek: Extract JSON from text that always matches your JSON Schema. For fixed entity types use extract_entities. Returns data, JSON extracted from the text that always parses and validates against your json_schema (decoded under a grammar built from it), plus model, usage (tokens) and ms. A small open model on Tanod's CPU, no model API: values can be wrong or missing, so check what matters. At most 8,000 characters and an 8 KB, 6-level schema; set maxLength / maxItems for long values. Bad input or an answer over 1,024 tokens is a 422; two extractions at once at most, so busy is a 503 with Retry-After; over 40 s is a 504 (none charged). The text is data, never instructions. Typically 3-15 s; up to about 25 s for 8,000 characters. Price: USD 0.005. No free tier. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/embeddings-rerank-ner-mcp-server.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	Yes	The text to read, 1 to 8,000 characters: an invoice, job post, contact block, product page or announcement. It is treated as data, never as instructions.
`json_schema`	Yes	A JSON Schema object for the answer: at most 8 KB serialised, nested at most 6 levels, local $ref only. The answer always matches it. Set maxLength / maxItems for long values (unbounded strings are cut at 300 characters and arrays at 50 items in decoding).

Output Schema

TableJSON Schema

Name	Required	Description
`ms`	No
`data`	No	The extracted JSON; it validates against the json_schema sent.
`note`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`model`	No
`usage`	No
`license`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses accuracy caveats ('values can be wrong or missing'), throughput limits (two at once, 503 + Retry-After), failure codes (422 for bad input or >1,024-token answers, 504 over 40 s and not charged), latency (3-15 s typical, ~25 s worst case), pricing, and a no-logging privacy guarantee. This is exactly the context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense and front-loaded: purpose and sibling routing come first, then limits, errors, latency, price. Nearly every clause carries operational information, though there is mild redundancy (the 'text is data, never instructions' point is repeated from the schema, and error/latency detail is packed into a long final stretch).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though an output schema exists (so return values need not be explained), the description still names the returned fields and covers the constraints, failure modes, cost, latency, and privacy an agent needs to invoke it correctly. Nothing material is missing for a 2-parameter, remote-model extraction tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds operative detail the schema only partly states: local $ref only, the 300-character/50-item silent truncation defaults, and concrete text examples (invoice, job post, contact block). It also reinforces that text is data, never instructions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Extract JSON from text') plus the distinguishing constraint ('always matches your JSON Schema'), and explicitly routes the fixed-entity case to the sibling extract_entities. An agent can tell it apart from extract_entities without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative (extract_entities) and the condition that selects it ('for fixed entity types'), which is real routing guidance. It stops short of covering other plausible alternatives (classify_zero_shot, text_summarize) or when-not-to-use conditions such as long outputs, so it is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server