Skip to main content
Glama

Export listings and structured data from the site

export_site_data
Read-onlyIdempotent

Generate ready-to-paste data from the site's own content (no AI, nothing saved): "gmb" — Google Business Profile fields (description, categories, hours, services); "whatsapp" — a WhatsApp Business catalog (set format: "csv" for the tab-separated bulk-upload file, returned as tsv); "ai-agent" — a knowledge pack to power a chatbot; "schema-org" — Schema.org JSON-LD for search engines; "all" — every JSON export. Contains no contacts or visitor data.

Input Schema

NameRequiredDescriptionDefault
typeYesWhich export
formatNo"csv" applies to "whatsapp" only; default json
site_idYesThe site, from list_sites
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description focuses elsewhere and adds meaningful context: 'no AI, nothing saved', the privacy boundary ('no contacts or visitor data'), and the quirk that csv output for WhatsApp is returned under a `tsv` key. This is useful behavior an agent can't get from the annotations.

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 dense, front-loaded sentence with the purpose first and the type enumeration after; the negative clause at the end is well placed. The semicolon-chained quoting is readable but heavy for a single run-on, keeping it from a 5.

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?

With no output schema, the description does enough: it characterizes each payload and hints at return shape (JSON exports, tsv for WhatsApp bulk file). It leaves the exact response envelope unspecified, which keeps it one notch below complete.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema's terse 'Which export' by explaining what each enum value produces and surfacing the non-obvious `tsv` return key for the csv/whatsapp combination. It does not add anything for site_id or user_goal.

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?

Opens with a specific verb+resource ('Generate ready-to-paste data from the site's own content') and enumerates every export type with what each contains. The closing 'Contains no contacts or visitor data' distinguishes it from export_contacts_csv and export_submissions at a glance.

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

Usage Guidelines4/5

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

The per-type parentheticals act as use-case routing ('a knowledge pack to power a chatbot', 'Schema.org JSON-LD for search engines'), and the no-contacts clause steers away from the contact export siblings. There is no explicit 'when not to use' or naming of alternatives, so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources