Store health analysis
Review a connected Shopify store for operational issues using the merchant's current store scope.
analyze_shopify_store_healthYEEDOOR's agent architecture is designed around a simple rule: an AI agent should first understand which merchant, store, provider and permission scope it is operating in, then discover what it may read, analyze or change. MCP-compatible clients can sit above this capability layer without receiving merchant passwords or internal infrastructure credentials.
Tool descriptions should tell an agent what business outcome the tool supports, what context it reads, and whether the action is read-only or may change merchant data.
Review a connected Shopify store for operational issues using the merchant's current store scope.
analyze_shopify_store_healthIdentify products or variants that deserve attention because of availability or inventory risk.
review_inventory_riskReview product and account issue context in an authorized Merchant Center account.
review_gmc_product_issuesAnalyze Google Ads performance in the advertising account mapped to the selected store.
analyze_google_ads_performanceInspect or manage the relationship between a store and its authorized GA4, Merchant Center and Google Ads assets.
map_store_google_assetsApply a supported product change only when the merchant scope and approval policy permit it, then verify the result.
update_shopify_productYEEDOOR now maintains a validated Agent Capability Registry across the current App Factory and Google commerce workflows. The registry separates business intent, merchant/store scope, provider capability, risk, approval and verification from the question of whether an external MCP client may invoke the tool today.
11 observe/analyze contracts and 6 action contracts are mapped to the same capability source of truth used by the merchant runtime.
App → Intent → Capability → Risk → VerifyAI Store Manager has 5 mapped contracts, Inventory Sync has 3 and Multi-channel Fulfillment has 4. Coming Soon apps remain non-invocable externally.
agent_discovery.external_agent_invocationR2 actions require merchant approval. The R3 Amazon MCF create path remains hard-gated and blocked from external agent invocation.
preview → validate → approve → execute → verifyThe public JSON contains sanitized contract metadata only. It does not expose provider tokens, internal routes or infrastructure credentials. It also records the separately verified read-only Pilot endpoint and which contracts are actually reachable.
/developers/mcp/agent-capabilities.jsonRemote MCP: restricted read-only Pilot live at https://merchant.yeedoor.com/mcp. Merchant authorization uses OAuth Authorization Code + PKCE (S256). The authorization server supports mcp:read and optional offline_access. Access tokens expire after 1 hour. A rotating 30-day refresh token is issued only when the client actually requests offline_access; the current ChatGPT development connection requested only mcp:read, so no refresh token was issued and reauthorization after access expiry is the correct fallback. The authenticated user selects a YEEDOOR merchant workspace from their actual membership, and that merchant scope is bound server-side to the access token. The Pilot exposes only five R0 tools: operating snapshot, Shopify catalog, Shopify inventory, Shopify business metrics and Store-to-Google asset inspection. Runtime acceptance is 5/5: operating snapshot and Google asset mapping return real merchant-scoped results; the three Shopify reads correctly return store_not_configured until a Shopify store is registered. Shopify order reads and every R1/R2/R3 action remain outside the Pilot. ChatGPT development custom MCP: connected; OAuth → initialize → tools/list → real yeedoor_get_operating_snapshot call has passed. It is not submitted for public listing.
YEEDOOR connects providers through their official authorization mechanisms. Provider access tokens and merchant credentials are not published to the model or placed in public documentation.
Every read or action must resolve the merchant workspace and, where applicable, the specific store or seller connection before provider data is accessed.
An agent should be able to determine whether a connector is available, whether it is read-only or action-capable, and whether the current merchant granted the required permission.
Material actions can remain merchant-approved. A recommendation is not automatically equivalent to permission to mutate a store, feed or advertising account.
Supported actions should be followed by a read-back or other verification step so the agent can distinguish a requested change from a successfully applied change.
Not every merchant will expose the same resources. Shopify protected customer data, Amazon seller permissions, Google account hierarchies, Merchant Center resources and advertising write access can all create different capability boundaries. YEEDOOR treats these differences as runtime facts rather than assuming every connected account has identical access.
The same capability graph that helps users understand YEEDOOR can help agents choose the right tool.