Turn Your schema.org Markup Into WebMCP Tools

How common is schema.org markup, actually?

More than you'd guess. The 2024 Web Almanac (HTTP Archive) found JSON-LD on 41% of crawled pages. WebDataCommons' 2024 corpus put overall structured-data adoption (JSON-LD, Microdata, RDFa combined) at roughly 51% of pages, with JSON-LD as the dominant format at about 70% of sites that annotate anything at all.

Those numbers average across the entire crawled web, including millions of pages with zero SEO effort behind them. The average understates your actual odds: Shopify and WooCommerce inject Product markup automatically, WordPress SEO plugins like Yoast and RankMath add Article markup by default, recipe plugins near-universally emit Recipe schema, and Google Jobs simply won't list a posting without JobPosting markup. If you run an e-commerce store, a blog, a recipe site, or a job board, you likely have this markup whether you added it on purpose or not.

What's actually sitting in that script tag

A typical product page carries something like this, invisible to visitors, read by Google to build rich search snippets:

Existing Product JSON-LD, unchanged

<script type="application/ld+json">
{
  "@type": "Product",
  "name": "Trail Runner Sneaker",
  "sku": "TR-2026",
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Name, SKU, price, currency, availability, exactly what an agent asking "is this in stock and how much is it" needs. It's already there. It's already accurate, because if it drifted from reality your search rich snippets would show wrong prices too. Nobody had to write a new data source for WebMCP to use it.

The gap: search engines read it, agents mostly haven't

schema.org was built for a specific consumer: search engine crawlers building rich snippets, not AI agents deciding what to call. The data model is declarative ("here are this page's facts"), while WebMCP's registerTool()is imperative ("here's a function you can call"). Those are different shapes, but the underlying facts, a product's price, an article's author, a FAQ's answer, don't change depending on which shape reads them.

That means re-deriving those same facts through an LLM, asking it to read your JSON-LD alongside everything else on the page and guess at a tool definition, is solving a problem that's already solved. The LLM is genuinely useful for the harder cases: actions like addToCartthat involve real interaction logic, not just facts. For read-only lookups where the fact already exists in a structured, machine-readable form, a deterministic parser is faster, free, and can't hallucinate a field that isn't there.

How Aigentably bridges the two

Aigentably's generator now has a Detect from schema.org path that skips the LLM entirely for this case. It parses the JSON-LD already on your crawled pages and builds ready-made tools deterministically, no AI generation quota used, free on every plan including Free-tier accounts with none left:

schema.org type	Tool created
Product	getProductInfo
Article / BlogPosting / NewsArticle	getArticleInfo
FAQPage	getFAQAnswer
Recipe	getRecipeInfo
Event	getEventInfo
LocalBusiness	getBusinessInfo
JobPosting	getJobInfo

Those seven cover the same entity types Google's own Rich Results documentation prioritizes, which is a reasonable proxy for "the types site owners actually mark up." Each tool re-reads its page's JSON-LD live when called, so one getProductInfo tool works across every product page that carries the markup, not just the one page it was first detected on.

What this doesn't replace

Being direct about the limits: schema.org-derived tools are read-only lookups. They can tell an agent a product's price, they can't add it to a cart. They can surface a FAQ answer, they can't submit a support ticket. Anything that needs to change state on your site, checkout, coupons, account actions, still needs either AI-generated tools (which can read your page's interactive elements and propose real executeJs) or hand-written ones. This is a shortcut for the read-only slice of your tool surface, not a replacement for the rest of it.