Skip to main content
Glama

seo_generate_code_fix

Idempotent

Generates framework-aware code fixes (Laravel Blade, Next.js App/Pages Router, HTML, PHP, Astro, Svelte) for missing titles, meta descriptions, canonical URLs, JSON-LD schemas, and WebMCP discovery links with unified diff preview.

USAGE GUIDELINES:

  • Use after audit tools detect specific SEO, schema, or WebMCP issues in a source file.

  • Do NOT use for general code refactoring unrelated to metadata, schema, or SEO tags.

  • Always run 'seo_validate_code_fix' immediately after applying changes to verify syntax and prevent duplicate tags.

BEHAVIORAL TRANSPARENCY:

  • Non-destructive by default: Returns unified diff preview without modifying files.

  • Modifies disk ONLY when 'applyDirectly' is explicitly set to true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoNew or updated title tag text.
filePathYesPath to source code file to modify (e.g., "./pages/index.tsx" or "resources/views/welcome.blade.php").
canonicalUrlNoCanonical URL (e.g. "https://example.com/page").
jsonLdSchemaNoValid Schema.org JSON-LD object to inject into HTML head.
applyDirectlyNoWhether to apply changes directly to disk. Default: false (returns diff preview only for review).
webMcpEndpointNoWebMCP endpoint URL to inject into HTML head via <link rel="mcp-server" /> (e.g. "/mcp" or "/api/mcp").
metaDescriptionNoNew or updated meta description string.
addWebMcpDiscoveryNoWhether to inject standard <link rel="mcp-server" href="/mcp" /> tag. Default: false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / properties / addWebMcpDiscovery / description
      Previous value: -"Whether to inject standard <link rel=\"mcp-server\" href=\"/mcp\" /> tag."New value: +"Whether to inject standard <link rel=\"mcp-server\" href=\"/mcp\" /> tag. Default: false."
    • changedInput schema / properties / applyDirectly / description
      Previous value: -"Whether to write changes directly to disk (default: false)."New value: +"Whether to apply changes directly to disk. Default: false (returns diff preview only for review)."
    • changedInput schema / properties / canonicalUrl / description
      Previous value: -"Canonical URL."New value: +"Canonical URL (e.g. \"https://example.com/page\")."
    • changedInput schema / properties / filePath / description
      Previous value: -"Path to the source file to modify."New value: +"Path to source code file to modify (e.g., \"./pages/index.tsx\" or \"resources/views/welcome.blade.php\")."
    • changedInput schema / properties / jsonLdSchema / description
      Previous value: -"Schema.org JSON-LD object to inject."New value: +"Valid Schema.org JSON-LD object to inject into HTML head."
    • changedInput schema / properties / metaDescription / description
      Previous value: -"New or updated meta description."New value: +"New or updated meta description string."
    • changedInput schema / properties / title / description
      Previous value: -"New or updated title tag."New value: +"New or updated title tag text."
    • changedInput schema / properties / webMcpEndpoint / description
      Previous value: -"WebMCP endpoint URL to inject into HTML <head> via <link rel=\"mcp-server\" /> (e.g. /mcp or /api/mcp)."New value: +"WebMCP endpoint URL to inject into HTML head via <link rel=\"mcp-server\" /> (e.g. \"/mcp\" or \"/api/mcp\")."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Even though annotations already indicate non-destructive behavior, the description adds valuable precision: it returns a unified diff preview by default and only modifies disk contents when 'applyDirectly' is true. This clarifies the exact side-effect boundary beyond what annotations provide, and no contradiction exists.

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?

The description is structured into purpose, usage, and behavioral transparency sections, with every sentence earning its place. The core capability and framework list are front-loaded, and the safe-by-default behavior is stated in two concise sentences.

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

Completeness5/5

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

For a tool with 8 parameters, one nested object, and no output schema, the description sufficiently explains what is generated, for which frameworks, when to invoke it, and what the return format is (unified diff preview). The workflow guidance to validate after applying makes it functionally complete.

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 all 8 parameters already carry detailed descriptions. The tool description enumerates the fix categories that map to these parameters, but it does not add per-parameter semantics beyond the schema. Baseline 3 is the appropriate baseline when the schema does the heavy lifting.

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?

The description names a specific verb ('generates'), a specific resource ('code fixes') and enumerates exact fix categories (titles, meta descriptions, canonical URLs, JSON-LD, WebMCP discovery links) and target frameworks. It is clearly differentiated from its siblings: audit tools detect issues, this one fixes them, and seo_validate_code_fix validates them.

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

Usage Guidelines5/5

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

The USAGE GUIDELINES explicitly state when to use the tool ('Use after audit tools detect specific...issues') and when not to use it ('Do NOT use for general code refactoring'). It also names a required follow-up sibling, seo_validate_code_fix, giving the agent a complete workflow.

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