Skip to main content
Glama

schema_generate

Generate Schema.org JSON-LD blocks for reservation, order action, discussion, or profile types. Use to add structured data to web pages for better search visibility.

Instructions

Generate a Schema.org JSON-LD block for one of four high-leverage types.

Adapted from scripts/schema_generate.py in claude-seo (agricidaniel, MIT). Supports: reservation, order_action, discussion, profile. No authentication required. No Google API calls made.

schema_type: one of "reservation", "order_action", "discussion", "profile". Returns the generated JSON-LD block. Verdicts: generated | error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNo
nameNo
textNo
imageNo
authorNo
same_asNo
end_timeNo
headlineNo
merchantNo
providerNo
job_titleNo
order_urlNo
works_forNo
order_nameNoOrder online
party_sizeNo
start_timeNo
descriptionNo
knows_aboutNo
profile_urlNo
schema_typeYes
comment_countNo
customer_nameNo
date_modifiedNo
customer_emailNo
date_publishedNo
reservation_idNo
delivery_methodNo
reservation_kindNoFoodEstablishmentReservation
reservation_for_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does add useful facts: no authentication required, no Google API calls made, and the two verdict outcomes (generated | error). However, it never explains which of the 29 parameters matter for which of the four schema types, which is the key behavioral detail for a tool with this fan-out.

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?

The purpose is front-loaded in the first sentence and the whole thing is short. The provenance line ('Adapted from scripts/schema_generate.py in claude-seo...') is agent-irrelevant overhead but minor.

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

Completeness2/5

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

An output schema exists so return values need not be explained, but for a tool exposing 29 parameters that map to four different schema types, the description omits the one thing an agent most needs: which parameters apply to which type. The parameter-to-type mapping gap makes it incomplete for correct invocation.

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?

Schema description coverage is 0% across 29 parameters, so the schema documents nothing. The description compensates only for schema_type by listing its four allowed values, leaving the remaining 28 optional parameters completely undocumented in both places. This is far below the compensation required at 0% coverage.

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?

The description states a specific verb and resource ('Generate a Schema.org JSON-LD block') and enumerates the four supported types, so an agent knows exactly what it produces. It does not explicitly differentiate itself from the sibling schema_validate, leaving the generate-vs-validate distinction to inference.

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?

It lists the supported schema types but gives no when-to-use guidance, no prerequisites, and no routing to the obvious alternative (schema_validate). The agent must guess the context in which generation is appropriate.

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