Skip to main content
Glama
MWIE MCP Server

MWIE MCP Server

by tmolavi

extract_structured_data

Extract Schema.org JSON-LD structured data and detected schemas from any webpage URL to audit markup and verify search engine visibility.

Instructions

Extract all Schema.org JSON-LD structured data and detected schemas from a webpage.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "extract_structured_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about whether a live network fetch occurs, permission or rate-limit constraints, or what happens when a page contains no structured data (empty result vs error). It also leaves "detected schemas" undefined, so the agent cannot predict what metadata is inferred versus parsed.

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?

One sentence, front-loaded with the action and the target, with no filler. The only mild cost is the ambiguous "detected schemas," which adds a second, unexplained capability to an otherwise tight statement.

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

Completeness3/5

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

This is a simple one-parameter tool with an output schema available, so the return format need not be explained. Still, for an extraction tool with zero annotations, the definition omits fetch behavior, empty-result handling, and the scope signal that would let an agent choose it over extract_page_content or extract_entities.

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

Parameters2/5

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

The single parameter has 0% schema description coverage, so the description must compensate. "From a webpage" weakly implies url is a page address rather than a domain or sitemap, but it says nothing about accepted formats (scheme required?), redirects, or whether domain roots are valid — all of which matter given the sibling list includes crawl_domain and analyze_sitemap.

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?

"Extract ... Schema.org JSON-LD structured data and detected schemas from a webpage" gives a specific verb (extract) and a specific resource (Schema.org JSON-LD / detected schemas), which is clearly narrower than siblings like extract_page_content or extract_entities. It stops short of explicitly naming which sibling to use instead when the goal is entities or raw page text.

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 when-to-use vs when-not guidance and no mention of the alternatives in the sibling set (extract_entities, extract_page_content, analyze_seo). Critically, it never says whether the tool fetches the URL itself or expects a page already retrieved via crawl_url — a decision point an agent must resolve before calling.

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