Skip to main content
Glama

HubVibe: Pay-per-Call Agent Tools: Web Search, Email Verify, KYC Screening, Stocks, Crypto, News

SEO and metadata audit

audit_seo
Read-onlyIdempotent

SEO audit of a web page (on-page SEO check) for any live URL or raw HTML: title tag, meta description, H1 heading structure, canonical link, OpenGraph and social tags, JSON-LD structured data, html lang attribute. Rule-by-rule findings with severity and what is missing or malformed. $0.05 per call. Returns: pass (bool), findings[] with id/severity/detail.

Input Schema

NameRequiredDescriptionDefault
urlNoLive, fetchable http(s) URL to audit.
htmlNoRaw HTML source to audit instead of fetching a URL.
languageNoOptional BCP-47 language tag (en, ja, ko, pt-BR): the human-readable text of the findings is returned in this language; rule ids, severities, URLs and numbers are untouched. Default: English.

Output Schema

NameRequiredDescriptionDefault
passYes
statusNo
findingsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / anyOf
      Removed value: -[
      -  {
      -    "required": [
      -      "url"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "html"
      -    ]
      -  }
      -]
    • addedInput schema / minProperties
      Added value: +1
  2. Changed6 schema fields changed
    • removedOutput schema / properties / findings / description
      Removed value: -"One entry per rule that did not pass. Empty when the check is clean."
    • removedOutput schema / properties / findings / items / properties
      Removed value: -{
      -  "detail": {
      -    "description": "What failed and where.",
      -    "type": "string"
      -  },
      -  "id": {
      -    "description": "Stable rule identifier.",
      -    "type": "string"
      -  },
      -  "severity": {
      -    "description": "Rule severity.",
      -    "type": "string"
      -  }
      -}
    • removedOutput schema / properties / findings / items / required
      Removed value: -[
      -  "id"
      -]
    • removedOutput schema / properties / findings / items / type
      Removed value: -"object"
    • removedOutput schema / properties / pass / description
      Removed value: -"Whether every rule in this dimension passed."
    • removedOutput schema / properties / status / description
      Removed value: -"Present only on a completed audit."
  3. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "Optional BCP-47 language tag (en, ja, ko, pt-BR): the human-readable text of the findings is returned in this language; rule ids, severities, URLs and numbers are untouched. Default: English.",
      +  "examples": [
      +    "ja"
      +  ],
      +  "maxLength": 35,
      +  "pattern": "^[A-Za-z]{2,3}(-[A-Za-z0-9]{2,8})*$",
      +  "type": "string"
      +}
  4. Changed8 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / anyOf
      Added value: +[
      +  {
      +    "required": [
      +      "url"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "html"
      +    ]
      +  }
      +]
    • changedInput schema / properties / html / description
      Previous value: -"Raw HTML to audit instead of a URL"New value: +"Raw HTML source to audit instead of fetching a URL."
    • changedInput schema / properties / url / description
      Previous value: -"Live URL to audit"New value: +"Live, fetchable http(s) URL to audit."
    • addedInput schema / properties / url / examples
      Added value: +[
      +  "https://example.com"
      +]
    • addedInput schema / properties / url / format
      Added value: +"uri"
    • addedInput schema / title
      Added value: +"Live URL or raw HTML to audit"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "properties": {
      +    "findings": {
      +      "description": "One entry per rule that did not pass. Empty when the check is clean.",
      +      "items": {
      +        "properties": {
      +          "detail": {
      +            "description": "What failed and where.",
      +            "type": "string"
      +          },
      +          "id": {
      +            "description": "Stable rule identifier.",
      +            "type": "string"
      +          },
      +          "severity": {
      +            "description": "Rule severity.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "id"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "pass": {
      +      "description": "Whether every rule in this dimension passed.",
      +      "type": "boolean"
      +    },
      +    "status": {
      +      "const": "ok",
      +      "description": "Present only on a completed audit.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "pass"
      +  ],
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world and non-destructive, so the description focuses on adding non-structured context: per-call cost ($0.05), rule-by-rule severity model, and that findings report what is missing or malformed. The 'Returns:' sentence duplicates the output schema slightly, which is the only real waste, but the cost disclosure is genuinely valuable pre-call information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the resource and scope, then the checked elements, then output and cost. Every clause carries information; no filler or restatement of the title.

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 a full output schema and annotations, the description supplies the remaining decisions an agent needs: input flexibility, cost, severity framing. The one gap is the absence of any note on url-vs-html precedence given the schema only enforces minProperties=1.

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

Parameters3/5

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

Schema description coverage is 100%, so the url/html/language parameters are already fully documented, including the BCP-47 language behavior and minProperties constraint. The description only echoes 'live URL or raw HTML' and says nothing about the language parameter or what happens if both url and html are supplied — baseline 3 is correct.

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?

Specific verb+resource ('SEO audit of a web page') followed by an explicit enumeration of what is checked: title tag, meta description, H1 structure, canonical, OpenGraph/social tags, JSON-LD, html lang. This clearly separates it from sibling audits (audit_performance, audit_security, audit_wcag) which cover different concern areas.

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?

States the input scope clearly ('for any live URL or raw HTML'), which tells the agent it does not need a pre-fetched page, and the 'on-page SEO check' framing implies where it applies. It stops short of naming alternatives or exclusions (e.g. when to prefer audit_bundle or audit_wcag instead), so implicit rather than explicit routing guidance.

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.