The LangExtract MCP Server enables structured information extraction from text using Large Language Models through a Model Context Protocol interface.
Core Extraction Capabilities:
Extract from text: Process unstructured text with LLMs using extract_from_text based on user-defined instructions and examples
Extract from URLs: Download and extract information from web content using extract_from_url
Data Management & Visualization:
Save results: Export extraction results in JSONL format with save_extraction_results
Generate visualizations: Create interactive HTML visualizations of extracted data with generate_visualization
Model Support & Configuration:
Google Gemini models: Primarily supports models like gemini-2.5-flash and gemini-2.5-pro optimized for structured extraction
Flexible configuration: Customize extraction behavior with parameters like model_id, temperature, max_char_buffer, and extraction_passes
Performance optimization: Features intelligent caching, persistent connections, and connection pooling
Server Management:
List supported models: View all available language models and their characteristics
Get server information: Retrieve server version, capabilities, and configuration details
Use Cases: Applicable across healthcare, legal, research, academia, and business intelligence for extracting medical data, contract terms, research findings, and customer feedback.
Enables extraction of information directly from arXiv research papers via URL processing.
Provides access to Gemini models (gemini-2.5-flash, gemini-2.5-pro) for text extraction tasks with optimized performance.
Supports Ollama integration for private deployments of local language models.
Enables use of OpenAI models like gpt-4o as alternative providers for extraction tasks.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LangExtract MCP Server Extract medication details from this patient note: 'Take 500mg amoxicillin twice daily for infection'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A FastMCP server for Google's langextract library. This server enables AI assistants like Claude Code to extract structured information from unstructured text using Large Language Models through a MCP interface.
LangExtract is a Python library that uses LLMs to extract structured information from text documents while maintaining precise source grounding. This MCP server exposes langextract's capabilities through the Model Context Protocol. The server includes intelligent caching, persistent connections, and server-side credential management to provide optimal performance in long-running environments like Claude Code.
Related MCP server: Unstructured Document Processor MCP
Claude Code installed and configured
Google Gemini API key (Get one here)
Python 3.10 or higher
Install directly into Claude Code using the built-in MCP management:
claude mcp add langextract-mcp -e LANGEXTRACT_API_KEY=your-gemini-api-key -- uv run --with fastmcp fastmcp run src/langextract_mcp/server.pyThe server will automatically start and integrate with Claude Code. No additional configuration is required.
After installation, verify the integration entering in Claude Code:
/mcpYou should see output indicating the server is running and can enter the server to see its tool contents.
The server provides the following tools for text extraction workflows:
Core Extraction
extract_from_text - Extract structured information from provided text
extract_from_url - Extract information from web content
save_extraction_results - Save results to JSONL format
generate_visualization - Create interactive HTML visualizations
For more information, you can checkout out the resources available to the client under src/langextract_mcp/resources
I am currently adding the abilty for MCP clients to pass file paths to unstructured text.
Ask Claude Code to extract information using natural language:
Extract medication information from this text: "Patient prescribed 500mg amoxicillin twice daily for infection"
Use these examples to guide the extraction:
- Text: "Take 250mg ibuprofen every 4 hours"
- Expected: medication=ibuprofen, dosage=250mg, frequency=every 4 hoursFor complex extractions, specify configuration parameters:
Extract character emotions from Shakespeare using:
- Model: gemini-2.5-pro for better literary analysis
- Multiple passes: 3 for comprehensive extraction
- Temperature: 0.2 for consistent resultsExtract information directly from web content:
Extract key findings from this research paper: https://arxiv.org/abs/example
Focus on methodology, results, and conclusionsThis server currently supports Google Gemini models only, optimized for reliable structured extraction with advanced schema constraints:
gemini-2.5-flash - Recommended default - Optimal balance of speed, cost, and quality
gemini-2.5-pro - Best for complex reasoning and analysis tasks requiring highest accuracy
The server uses persistent connections, schema caching, and connection pooling for optimal performance with Gemini models. Support for additional providers may be added in future versions.
Set during installation or in server environment:
LANGEXTRACT_API_KEY=your-gemini-api-key # RequiredConfigure extraction behavior through tool parameters:
{
"model_id": "gemini-2.5-flash", # Language model selection
"max_char_buffer": 1000, # Text chunk size
"temperature": 0.5, # Sampling temperature (0.0-1.0)
"extraction_passes": 1, # Number of extraction attempts
"max_workers": 10 # Parallel processing threads
}All extractions return consistent structured data:
{
"document_id": "doc_123",
"total_extractions": 5,
"extractions": [
{
"extraction_class": "medication",
"extraction_text": "amoxicillin",
"attributes": {"type": "antibiotic"},
"start_char": 25,
"end_char": 35
}
],
"metadata": {
"model_id": "gemini-2.5-flash",
"extraction_passes": 1,
"temperature": 0.5
}
}LangExtract MCP Server supports a wide range of use cases across multiple domains. In healthcare and life sciences, it can extract medications, dosages, and treatment protocols from clinical notes, structure radiology and pathology reports, and process research papers or clinical trial data. For legal and compliance applications, it enables extraction of contract terms, parties, and obligations, as well as analysis of regulatory documents, compliance reports, and case law. In research and academia, the server is useful for extracting methodologies, findings, and citations from papers, analyzing survey responses and interview transcripts, and processing historical or archival materials. For business intelligence, it helps extract insights from customer feedback and reviews, analyze news articles and market reports, and process financial documents and earnings reports.
Primary Resources:
LangExtract Documentation - Core library reference
FastMCP Documentation - MCP server framework
Model Context Protocol - Protocol specification
Extract structured information from text using langextract.
Uses Large Language Models to extract structured information from unstructured text based on user-defined instructions and examples. Each extraction is mapped to its exact location in the source text for precise source grounding.
Args: text: The text to extract information from prompt_description: Clear instructions for what to extract examples: List of example extractions to guide the model model_id: LLM model to use (default: "gemini-2.5-flash") max_char_buffer: Max characters per chunk (default: 1000) temperature: Sampling temperature 0.0-1.0 (default: 0.5) extraction_passes: Number of extraction passes for better recall (default: 1) max_workers: Max parallel workers (default: 10)
Returns: Dictionary containing extracted entities with source locations and metadata
Raises: ToolError: If extraction fails due to invalid parameters or API issues
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| prompt_description | Yes | ||
| examples | Yes | ||
| model_id | No | gemini-2.5-flash | |
| max_char_buffer | No | ||
| temperature | No | ||
| extraction_passes | No | ||
| max_workers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context such as mapping extractions to source locations for grounding, default values for parameters, and error handling (Raises: ToolError). However, it does not cover aspects like rate limits, authentication needs, or performance characteristics, leaving some behavioral gaps.
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?
The description is well-structured with a clear purpose statement, parameter explanations, and return/error details. It is appropriately sized and front-loaded, with most critical information (purpose and key parameters) presented early. Some minor verbosity exists in parameter descriptions, but overall it earns its place efficiently.
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?
Given the complexity (8 parameters, no annotations, but has output schema), the description is largely complete. It covers purpose, parameters, returns, and errors. With an output schema present, it need not explain return values in detail, but it could improve by addressing sibling tool differentiation more explicitly. The gaps are minor relative to the tool's scope.
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 compensate. It provides detailed semantics for all 8 parameters, explaining their purposes (e.g., 'text: The text to extract information from'), default values, and ranges (e.g., 'temperature: Sampling temperature 0.0-1.0'). This adds significant meaning beyond the basic schema, though it could be more explicit about parameter interactions.
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?
The description clearly states the tool's purpose as extracting structured information from unstructured text using Large Language Models, specifying the method (langextract), and distinguishing it from sibling tools like extract_from_url by focusing on text input rather than URLs. It provides a specific verb ('extract') and resource ('structured information from text').
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 implies usage context by mentioning 'user-defined instructions and examples' and 'unstructured text,' but does not explicitly state when to use this tool versus alternatives like extract_from_url or generate_visualization. It provides clear context for extraction tasks but lacks explicit exclusions or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured information from text content at a URL.
Downloads text from the specified URL and extracts structured information using Large Language Models. Ideal for processing web articles, documents, or any text content accessible via HTTP/HTTPS.
Args: url: URL to download text from (must start with http:// or https://) prompt_description: Clear instructions for what to extract examples: List of example extractions to guide the model model_id: LLM model to use (default: "gemini-2.5-flash") max_char_buffer: Max characters per chunk (default: 1000) temperature: Sampling temperature 0.0-1.0 (default: 0.5) extraction_passes: Number of extraction passes for better recall (default: 1) max_workers: Max parallel workers (default: 10)
Returns: Dictionary containing extracted entities with source locations and metadata
Raises: ToolError: If URL is invalid, download fails, or extraction fails
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| prompt_description | Yes | ||
| examples | Yes | ||
| model_id | No | gemini-2.5-flash | |
| max_char_buffer | No | ||
| temperature | No | ||
| extraction_passes | No | ||
| max_workers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it downloads text from URLs, uses LLMs for extraction, mentions error conditions (invalid URL, download failure, extraction failure), describes the return format (dictionary with entities, source locations, metadata), and mentions parallel processing capability (max_workers). It doesn't cover rate limits or authentication requirements, but provides substantial 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, ideal use cases, Args, Returns, Raises) and front-loads the core functionality. While comprehensive, some sentences could be more concise (e.g., the second sentence could be merged with the first). Overall, it's appropriately sized for an 8-parameter tool with no annotations.
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?
Given the tool's complexity (8 parameters, no annotations, but has output schema), the description is remarkably complete. It covers purpose, usage context, all parameter semantics, return format, error conditions, and behavioral details. The presence of an output schema means the description doesn't need to exhaustively document return values, and it provides everything else needed for effective use.
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?
With 0% schema description coverage for 8 parameters, the description fully compensates by providing detailed semantic explanations for every parameter in the Args section. Each parameter gets clear meaning beyond just the schema's type information, explaining what 'prompt_description', 'examples', 'model_id', 'max_char_buffer', 'temperature', 'extraction_passes', and 'max_workers' actually do in the extraction context.
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?
The description clearly states the tool's purpose with specific verbs ('extract structured information from text content at a URL') and distinguishes it from sibling tools by specifying it works with URLs rather than raw text (vs extract_from_text). It identifies the resource (text content at a URL) and method (using LLMs).
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 provides clear context for when to use this tool ('ideal for processing web articles, documents, or any text content accessible via HTTP/HTTPS'), which implicitly distinguishes it from extract_from_text that works with raw text. However, it doesn't explicitly state when NOT to use it or name specific alternatives beyond the sibling tool names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate interactive HTML visualization from extraction results.
Creates an interactive HTML file that shows extracted entities highlighted in their original text context. The visualization is self-contained and can handle thousands of entities with color coding and hover details.
Args: jsonl_file_path: Path to the JSONL file containing extraction results output_html_path: Optional path for the HTML output (default: auto-generated)
Returns: Dictionary with HTML file path and generation details
Raises: ToolError: If visualization generation fails
| Name | Required | Description | Default |
|---|---|---|---|
| jsonl_file_path | Yes | ||
| output_html_path | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it creates a self-contained HTML file, handles thousands of entities, includes color coding and hover details, and mentions error handling via ToolError. It doesn't cover aspects like performance, file size limits, or specific visual features, but provides substantial operational context.
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?
The description is well-structured and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds value: capabilities, parameter details, return values, and error handling. There's no wasted text, and the bullet-like formatting for Args/Returns/Raises enhances readability without verbosity.
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?
Given the tool's moderate complexity (2 parameters, no annotations, but with output schema), the description is complete. It covers purpose, behavior, parameters, returns, and errors. The output schema existence means return values don't need detailed explanation in the description, and the description provides all necessary context for effective use.
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 compensate fully. It clearly explains both parameters: jsonl_file_path as 'Path to the JSONL file containing extraction results' and output_html_path as 'Optional path for the HTML output (default: auto-generated)'. This adds essential meaning beyond the bare schema, covering purpose, format, and default behavior.
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?
The description clearly states the specific action ('Generate interactive HTML visualization') and resource ('from extraction results'), distinguishing it from sibling tools like extract_from_text/url (which extract) and save_extraction_results (which saves). It specifies the visualization type, content, and capabilities like handling thousands of entities with color coding and hover details.
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 implies usage context by mentioning 'extraction results' and referencing JSONL files, suggesting it should be used after extraction tools. However, it doesn't explicitly state when to use this vs. alternatives or provide any exclusions. The connection to extraction is clear but not explicitly framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save extraction results to a JSONL file for later use or visualization.
Saves the extraction results in JSONL (JSON Lines) format, which is commonly used for structured data and can be loaded for visualization or further processing.
Args: extraction_results: Results from extract_from_text or extract_from_url output_name: Name for the output file (without .jsonl extension) output_dir: Directory to save the file (default: current directory)
Returns: Dictionary with file path and save confirmation
Raises: ToolError: If save operation fails
| Name | Required | Description | Default |
|---|---|---|---|
| extraction_results | Yes | ||
| output_name | Yes | ||
| output_dir | No | . |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool saves to a file, returns a dictionary with file path and confirmation, and raises ToolError on failure. However, it lacks details on permissions needed, file overwriting behavior, or rate limits. The description does not contradict annotations (none provided).
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?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by supporting details. The Args and Returns sections are structured but slightly verbose; every sentence adds value, though some redundancy exists (e.g., repeating JSONL format).
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?
Given 3 parameters with 0% schema coverage, no annotations, and an output schema (implied by Returns), the description is fairly complete. It explains parameters, return values, and errors, but could improve by detailing file naming conventions or visualization integration. The output schema reduces the need to fully explain returns.
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 compensate. It adds meaning beyond the schema by explaining extraction_results comes from specific sibling tools, output_name excludes the .jsonl extension, and output_dir defaults to current directory. This covers all 3 parameters, though it could provide more detail on format or constraints.
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?
The description clearly states the specific action ('Save extraction results') and resource ('to a JSONL file'), distinguishing it from sibling tools like extract_from_text, extract_from_url, and generate_visualization. It explicitly mentions the format (JSONL) and purpose (for later use or visualization), avoiding tautology with the tool name.
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 provides clear context on when to use this tool: after extraction from text or URL, for saving results to a file. It implies usage by referencing sibling tools (extract_from_text, extract_from_url) as sources for the extraction_results parameter. However, it does not explicitly state when not to use it or name alternatives (e.g., vs. generate_visualization).
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.
extract_from_textextract_from_urlgenerate_visualizationsave_extraction_resultsScored across 4 tools
Each tool has a clearly distinct purpose with no overlap. extract_from_text and extract_from_url handle different input sources, generate_visualization creates visual outputs, and save_extraction_results handles persistence. The boundaries are well-defined and unambiguous.
All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout (extract_from_text, extract_from_url, generate_visualization, save_extraction_results), making the tool set predictable and easy to understand.
Four tools is well-scoped for a structured information extraction server. The tools cover the complete workflow: extraction from different sources, visualization generation, and result persistence. Each tool earns its place without redundancy or gaps in the core functionality.
The tool set provides complete coverage for the structured information extraction domain. It supports extraction from both text and URLs, visualization of results, and saving for later use. There are no dead ends or missing operations for the intended purpose.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
A paid remote MCP for Pydantic AI structured output, built to return verdicts, receipts, usage logs,
