schema_validateExtract and validate JSON-LD structured data (schema.org) from a page. Checks JSON validity and flags missing recommended fields for common types (Article, Product, Organization, WebSite, BreadcrumbList, FAQPage, LocalBusiness).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full page URL to check for structured data. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description does not need to restate safety. The description adds behavioral detail beyond the annotations: it validates JSON syntax, flags missing recommended fields, and specifically targets JSON-LD rather than all structured data formats. This gives the agent a useful model of what the tool will and will not do.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The primary action is stated first, followed by the specific validation behavior and supported types. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only, no-output-schema tool, the description covers the input, the operation, the validation checks, and the relevant schema.org types. It does not describe the exact return format, but the description implies a validation result and flags, which is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, url, is fully described in the input schema ('Full page URL to check for structured data'). The description adds no additional parameter-level meaning, but with 100% schema description coverage, the schema carries the semantic burden adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: it extracts and validates JSON-LD structured data (schema.org) from a page. It also names concrete checks (JSON validity, missing recommended fields) and lists the supported schema.org types, making it clearly distinct from the broad SEO audit and link-analysis siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: use this when you need to check a specific page for JSON-LD structured data and validation issues. It does not explicitly name alternatives or state when not to use it, but the focused scope ('from a page', JSON-LD only) is enough to guide selection among the mostly unrelated sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools occupy adjacent backlink-analysis territory: backlinks_for_domain and top_linkers_for_domain both return ranked linking domains with authority and count data, and common_linkers vs find_link_prospects can be confused despite one being overlap and the other gap analysis. Descriptions help clarify intent, but the near-duplicate listing tools make misselection possible.
All names are snake_case and readable, but the pattern is mixed: some are resource-centric (domain_authority_score, core_web_vitals, top_linkers_for_domain) while others are action-centric (find_link_prospects, flag_toxic_links, verify_link_live). Indexnow_submit also inverts the usual action-object order. Still, the names are descriptive enough to navigate.
Thirteen tools is a reasonable scope for a backlink/SEO-focused server, covering link analysis, audits, and indexing without feeling bloated. The count is slightly high because several backlink tools overlap and could be consolidated, but each does have a recognizable use case.
The core backlink workflow is well covered: authority scores, backlink lists, overlap, gap analysis, toxic-link flags, and live verification are all present, and the additional SEO tools extend the surface usefully. Notable gaps are the lack of per-link URL/anchor data and single-page-only auditing, but these are workable limitations rather than dead ends.