Skip to main content
Glama
Sign In
FeedDoctor MCP

FeedDoctor MCP

by anthonymorey
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Generate Prioritized Feed Fix Plan & Supplemental Patch Preview

fix_plan
Read-onlyIdempotent

Generate a prioritized, step-by-step remediation plan across Google and Microsoft Merchant Center, including copy-ready supplemental feed patch rows and official documentation links.

Instructions

Generates a prioritized, step-by-step remediation plan across Google Merchant Center and Microsoft Merchant Center, complete with copy-ready supplemental feed patch rows and official documentation links.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "fix_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
platformNoPlatform scope: "google", "microsoft", or "both".both
credentialsNoOptional per-call credential overrides. If omitted, credentials are resolved from the HTTP Authorization Bearer token / headers or self-host environment variables.
googleAccountIdNo
checkLandingPagesNoWhen true, fetches public landing pages for disapproved SKUs to populate exact live prices/availabilities in the supplemental patch preview.
microsoftMerchantIdNo
maxLandingPageChecksNoMaximum number of public product URLs to fetch when checkLandingPages is true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful context beyond that: the tool produces copy-ready patch rows and doc links, and it implies outbound fetching of public landing pages (consistent with openWorldHint). It stops short of disclosing cost/latency of landing-page fetches or what happens when credentials are missing.

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?

A single front-loaded sentence with the key value proposition first and no filler. Mildly promotional phrasing ('copy-ready', 'official') but nothing structurally wasteful; a short second sentence on prerequisites or return shape would have improved it without bloat.

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

Completeness3/5

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

For a 6-parameter tool with a nested credentials object and no output schema, the description covers what is produced (plan, patch rows, doc links) but not the credential resolution fallback, the cost of landing-page checks, or how the generated patch rows are meant to be consumed. Adequate but leaves real gaps for an agent deciding whether to call it.

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 67%, so the schema already explains platform, checkLandingPages, maxLandingPageChecks and the credential overrides. The description adds no parameter-level meaning at all and says nothing about the two undocumented parameters (googleAccountId, microsoftMerchantId). Baseline 3 is appropriate given the schema does the heavy lifting.

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?

States a specific verb and resource: generates a prioritized, step-by-step remediation plan spanning Google and Microsoft Merchant Center, with supplemental feed patch rows and documentation links. That is clearly distinguishable from siblings like diagnose_product or feed_health_summary, though it never names or contrasts them explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the word 'remediation' suggests this is invoked after a diagnosis or health summary has surfaced problems, but the description never says so, nor does it state prerequisites (e.g., connecting accounts) or when a sibling like diagnose_product is the better first call. No exclusions or alternatives are offered.

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

Deploy Server

Other Tools