Skip to main content
Glama

extract_entities

Read-only

Extract emails, phone numbers, URLs, dates, IPs, prices, or custom/LLM-defined entities from web pages, with optional JSON output to disk.

Instructions

Extract entities (emails, phones, etc.) from web pages. Use output_path to persist the full entity extraction output to disk as JSON and receive a slim response.

Input Schema

NameRequiredDescriptionDefault
urlYesTarget URL
use_llmNoUse LLM for NER
llm_modelNoLLM model
overwriteNoOverwrite an existing output file at output_path. Defaults to False.
deduplicateNoRemove duplicates
output_pathNoAbsolute file path (auto .json extension) to persist the full entity extraction as JSON. When set, the response is slimmed (content, markdown, extracted_data.raw_content removed).
entity_typesYesRegex types: emails, phones, urls, dates, ips, prices, credit_cards, coordinates (singular forms like email/phone are accepted), plus any custom_patterns keys. Without use_llm, other types are listed under unsupported_entity_types with a warning. With use_llm=True any type name works (e.g. people, organizations, locations, products, events).
llm_providerNoLLM provider
custom_patternsNoCustom regex patterns as {type_name: regex}; list the type_name in entity_types to use it (regex mode only)
include_contextNoInclude context
include_content_in_responseNoWhen True (with output_path set), also keep the entity data in the response. Defaults to False.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.2
    • changedInput schema / properties / custom_patterns / description
      Previous value: -"Custom regex patterns"New value: +"Custom regex patterns as {type_name: regex}; list the type_name in entity_types to use it (regex mode only)"
    • changedInput schema / properties / entity_types / description
      Previous value: -"Types: email, phone, url, date, ip, price"New value: +"Regex types: emails, phones, urls, dates, ips, prices, credit_cards, coordinates (singular forms like email/phone are accepted), plus any custom_patterns keys. Without use_llm, other types are listed under unsupported_entity_types with a warning. With use_llm=True any type name works (e.g. people, organizations, locations, products, events)."
  2. Addedv0.3.2

TDQS

B3.2/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=true, and the description adds real behavioral context: with output_path set, the full extraction is written to disk as JSON and the response is slimmed. However, this creates an unaddressed tension with readOnlyHint (a file is written) and the description says nothing about regex-vs-LLM mode consequences, which drive most of the tool's actual behavior.

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?

Two sentences, front-loaded with the core action and followed by the highest-value operational hint. No filler or repetition, though the second sentence could be tighter.

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?

For an 11-parameter tool, the description leans heavily on a fully documented schema and an existing output schema, so return values and per-parameter semantics are covered elsewhere. The remaining gap is the absence of any routing guidance among the many extraction siblings.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter including entity_types, custom_patterns, and overwrite is already documented in detail. The description's note about output_path duplicates what the schema already states, adding no syntax or default information beyond it.

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

Purpose4/5

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

Names a specific verb and resource ("Extract entities") and scopes it to web pages, with examples of the entity kinds (emails, phones). It does not explicitly differentiate itself from close siblings like extract_structured_data or intelligent_extract, which an agent could plausibly confuse it with.

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

Usage Guidelines2/5

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

There is no statement of when to choose this over extract_structured_data, intelligent_extract, or crawl_url, and no exclusions or prerequisites. The only guidance is operational (use output_path to get a slim response), not selection guidance.

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