Skip to main content
Glama

Apply Seonix fixes

apply_fix
Destructive

Have Seonix apply fixes on the live site through the WordPress plugin (write scope — tell the user exactly which issue codes and get a yes first). Works for get_fix_plan items with fix_tier auto or ai_assist (wp_plugin_fixable); the site must have a connected WordPress channel. Starts a run (preview → Seonix suggestions → apply) and returns its id; poll get_fix_run until status is completed, partial or failed. Undo with rollback_fix.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "issue_codes": "<issue_codes>"
    },
    "name": "apply_fix"
  }
}

Input Schema

NameRequiredDescriptionDefault
issue_idsNoOptional comma-separated scan issue ids (from list_issues evidence) to restrict the run to specific pages.
project_idNoProject id or slug.
issue_codesYesComma-separated issue codes from get_fix_plan whose fix_tier is auto or ai_assist (wp_plugin_fixable). Seonix fixes them on the live WordPress site through its plugin.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare write/destructive/non-idempotent, and the description adds real context beyond them: it is a live-site write requiring user confirmation of specific issue codes, it starts an asynchronous run rather than completing synchronously, and it enumerates terminal statuses (completed, partial, failed) the agent must poll for.

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?

Dense but front-loaded: the write-scope warning and confirmation requirement come first, then eligibility, then the run lifecycle. Every clause carries information, though the parenthetical and the run-sequence clause make it a long read for a single paragraph.

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?

Covers everything an agent needs for a destructive async tool with no output schema: prerequisites (connected WordPress channel), the fact that it returns only a run id, how to poll for completion and which statuses are terminal, and the recovery path via rollback_fix.

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 baseline is 3. The description's mention of which issue codes qualify largely restates the issue_codes schema text and adds no syntax, format, or batching detail for issue_ids beyond the schema's 'restrict the run to specific pages'.

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?

States a specific verb and resource (apply fixes on the live site via the WordPress plugin) and names the upstream source (get_fix_plan items) and the sibling for reversal (rollback_fix). An agent can distinguish this from get_fix_plan, get_fix_run, and rollback_fix without opening any schema.

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?

Gives explicit eligibility conditions (fix_tier auto or ai_assist / wp_plugin_fixable, site must have a connected WordPress channel) and an explicit exclusion-by-implication via the tier gate. It also routes the agent to get_fix_run for polling and rollback_fix for undo, so both the when and the what-next are covered.

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.