Extend MCP

Create an extractor

create_extractor

Create a saved, reusable extractor (extract group). Three starting points, mutually exclusive: config (inline schema — call get_documentation with https://docs.extend.ai/extraction/schema.md BEFORE writing one by hand), cloneExtractorId (copy another extractor's draft config), or generate (Extend writes the schema from 1-5 sample documents plus optional instructions; no docs needed); name alone creates an empty draft. The draft is the only mutable surface — edit it with update_extractor, freeze it with publish_extractor_version, run it with extract_data.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Display name for the extractor.
`config`	No	Inline extraction config: { schema?, extractionRules?, baseProcessor?, advancedOptions?, parseConfig? }. Writing schema by hand? ALWAYS call get_documentation with https://docs.extend.ai/extraction/schema.md FIRST and follow the returned dialect — the rules below are only a summary (field-naming best practices: https://docs.extend.ai/extraction/best-practices/field-names-and-prompt-crafting.md). schema is a JSON Schema: root "type": "object"; primitives nullable via a type array (["string","null"]); objects/arrays keep a plain "type" (never a nullable array) and objects always need "properties"; max depth 5; enums include null; no anyOf/oneOf/allOf/patterns. Date/currency/signature fields add "extend:type" alongside a normal type. A currency field is exactly: { "type": "object", "extend:type": "currency", "properties": { "amount": { "type": ["number", "null"] }, "iso_4217_currency_code": { "type": ["string", "null"] } } } — never a bare number. Omit schema for schema-less mode (no docs needed): extractionRules then doubles as schema-generation instructions.
`generate`	No	Auto-generate the schema from sample documents.
`environment`	Yes	"TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment).
`workspaceId`	Yes	Target workspace (ws_...). Must be a granted workspace — get_me lists the accepted values.
`cloneExtractorId`	No	Existing extractor (ex_...) whose draft config to copy.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`createdAt`	No
`updatedAt`	No
`draftVersion`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 3, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses that the result is a draft, that the draft is the only mutable surface, and that it must be edited, published, and then run. It also warns about the schema dialect and the need to consult documentation, adding significant behavioral context.

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 four sentences that efficiently cover purpose, starting points, and lifecycle, with zero fluff. It front-loads the core purpose and packs all critical guidance into a compact, readable structure.

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?

Given the complexity (6 params, nested objects, output schema exists), the description covers all necessary guidance: starting points, mutual exclusivity, alternative tools, and the draft lifecycle. The output schema handles return values, so nothing an agent needs to call this correctly is missing.

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?

The description adds meaning beyond the schema by explaining that config, cloneExtractorId, and generate are mutually exclusive, and provides strategic guidance on choosing among them. It also clarifies the name-only case and references get_documentation for schema rules, which the schema alone does not convey.

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 clearly states the tool creates a saved, reusable extractor and distinguishes it from siblings like create_classifier and create_splitter by specifying 'extractor (extract group)'. The verb 'Create' plus the resource is specific and unambiguous.

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

Usage Guidelines5/5

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

It explicitly lists three mutually exclusive starting points (config, cloneExtractorId, generate) and explains when to use each, including the recommendation to call get_documentation for hand-written schemas. It also describes the name-only case and the subsequent lifecycle steps (update_extractor, publish_extractor_version, extract_data), giving full context for tool selection.

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

All Extend MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?