Skip to main content
Glama

local_structured

Generate JSON-schema-compliant outputs from local models, with automatic validation and retries on invalid results.

Instructions

Has a local model return a result that conforms to a JSON schema.

Uses the respective backend's schema enforcement (Ollama's 'format' field,
vLLM's 'response_format' with 'json_schema') and then additionally validates
the answer against the schema itself. If the output does not satisfy the
schema, it retries up to twice, passing the model the concrete violations.
Only then an error, but then with the invalid raw output, so it is visible
what went wrong.

Args:
    model: Model name, for example 'llama3.2:3b'.
    prompt: Instruction on what should be extracted from which text.
    schema: JSON schema of the desired result (object with 'type', 'properties', ...).
    system: Optional role/behavior instruction.
    think: Enables the model's reasoning trace. Off by default, because the
        reasoning trace otherwise consumes the answer's token budget. Only
        for models with the 'thinking' capability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYes
thinkNo
promptYes
schemaYes
systemNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.2

TDQS

A4.5/5.0
Behavior5/5

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

No annotations are provided, so the description carries full behavioral disclosure. It explains validation against the schema, a retry mechanism up to twice with concrete violations, the final error containing the raw invalid output, and the token-budget tradeoff of setting think=true. This is unusually transparent and goes far beyond a minimal description.

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

Conciseness5/5

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

The description is well-structured and dense: a one-sentence purpose, a concise mechanics paragraph, and a labeled Args section. Every sentence adds operational value, and the most important information is front-loaded.

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

Completeness4/5

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

Given the tool's complexity—multi-backend enforcement, retries, error behavior, and optional reasoning trace—the description covers nearly everything needed for correct invocation. Minor gaps: it doesn't state what happens when think=true is used on a model without the thinking capability, and it offers no explicit sibling routing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It defines every argument: model with an example, prompt's purpose, schema's expected structure, system as optional, and think with default, rationale, and model-capability constraint. This fully compensates for the lack of schema descriptions.

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?

The description opens with a clear, specific statement: it makes a local model return a result conforming to a JSON schema. It further details the backend mechanisms (Ollama 'format', vLLM 'response_format'), which clarifies what the tool does and distinguishes it from the sibling tools local_ask and local_embed.

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

Usage Guidelines3/5

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

Intended usage is strongly implied—you use this tool when you need schema-enforced JSON output from a local model—but there is no explicit guidance about when not to use it or which sibling to prefer (e.g., local_ask for free-form text). The agent must infer tool selection from context rather than being told.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/setheerwagen/local-ai-mcp-servers'

If you have feedback or need assistance with the MCP directory API, please join our Discord server