Turn the Edgaze marketplace into an agent-ready tool catalog

MCP makes the marketplace legible to an AI client without flattening every workflow into a generic function call. Connect one remote server and the agent can discover an evolving catalog, read the exact contract for a selected product, show the user what it costs, run it, and follow durable execution to a useful result. The creator does not have to operate a separate MCP server, duplicate the graph, or rebuild authentication and billing for each client; the protocol surface points back to the same published workflow that people can inspect and run on Edgaze.

The server exposes five deliberately narrow tools. Catalog provides a category map when the request is vague; search looks for a workflow using the user's goal; inspect resolves one slug into real fields, examples, price, and demo availability; run creates the accepted execution; and watch follows that same run until terminal. This order is part of the safety model. The agent can stop when no product matches, avoid fabricated fields, keep payment visible, and distinguish waiting from starting over. Textual results can return in chat, while files and rich media remain available on the durable Edgaze run page.

MCP standardizes how a client discovers and invokes tools, but it does not make an underspecified tool useful. The value still comes from what sits behind the protocol: a clear job, an input contract, tested workflow logic, a versioned execution graph, an understandable price, and an output the user can act on. Edgaze treats those elements as the workflow product, while MCP is one interface through which that product can be selected and operated.

That distinction is important for creators. A creator builds and tests in Workflow Studio, defines what the buyer provides, chooses the result that should be published, and releases an immutable version. Edgaze can expose the eligible product through its hosted Edgaze MCP surface without asking the creator to implement remote transport, OAuth consent, catalog search, tool schemas, wallet checks, run monitoring, and media delivery as separate infrastructure.

It is also important for users because the product has a public identity outside the conversation. A person can review the marketplace listing and its examples, then let the agent execute the same version. The agent receives the product contract and run tools, not the creator's editable graph or intellectual property. This preserves a clean boundary between buying an outcome and acquiring the system that produces it.

Catalog and search are intentionally separate from execution. Catalog is useful when the person has a broad need and the agent needs to understand what kinds of products exist. Search uses the person's goal in their own words and returns candidates. If search returns no_match, the agent should stop searching Edgaze and use another capability; repeatedly changing the query until something vaguely related appears is not successful discovery.

Inspect is the decision point. It turns one workflow slug into the fields the product actually accepts, example values, the current displayed price, and whether a demo is available. The agent should show that information in ordinary language, reuse details already present in the conversation, and ask only for schema-required values that are missing. It should not manufacture a plausible slug, add an unrecognized parameter, or conceal the price inside a tool call.

Run and watch then operate one accepted execution. max_cost_usd is a ceiling at or above the inspected price, not permission to spend an unknown amount. Watch uses the returned run_id and cursor; after an empty read, the agent waits poll_after_ms and tries the same watch again. Starting a second run because the first is still working is both logically wrong and potentially billable. The sequence makes those boundaries clear enough for an agent to follow and for a person to audit.

Edgaze MCP uses browser OAuth so the person connects an Edgaze account and approves two understandable capabilities: finding workflows and running them. The client, not a copied consent link, initiates that flow. The configuration should contain the server URL and the transport syntax required by the client, but no Edgaze API key, bearer token, or homemade authorization header. Disconnecting the app later removes that connection without requiring a creator to change the workflow.

A free demo is a genuine run of the published workflow using the person's inputs. It is not a video or static sample, it does not debit the wallet or pay the creator, and it should only be requested when inspect reports that a demo is available. For normal paid execution, the agent quotes the price first. If the wallet cannot cover it, the useful response is a wallet link and a clear instruction to retry after funding—not a vague authentication error or a second MCP configuration.

The final handoff should match the output. When present is chat, the agent should render text or markdown as a readable answer and describe external actions such as a sent email or created ticket with any returned confirmation details. When present is edgaze_page, the result is better viewed outside chat; the agent provides the Edgaze run page for images, video, files, or downloads. Raw JSON, base64, and binary payloads are implementation details, not a user experience.

The public server is https://mcp.edgaze.ai and the transport is remote HTTP. The client starts OAuth and the user approves permission to find and run workflows. There is no local package to launch, and copying an API key or adding a custom Authorization header creates the wrong setup.

Choose the exact client below because configuration keys and file locations differ, add the server as edgaze, and finish the browser-based authorization flow that the client starts. Do not open a bare consent URL manually; it will not contain a sign-in request. See every client setup. Confirm that edgaze_catalog, edgaze_search, edgaze_inspect, edgaze_run, and edgaze_watch are visible. Then ask the client to list catalog categories or search for a concrete outcome before attempting execution; an empty wallet does not mean installation failed. Run the verification sequence.

Inspect one search result and confirm the workflow slug, required fields, examples, displayed price, and demo_available value. Fill accepted inputs from the conversation and ask for anything essential that remains missing instead of inventing a value the form does not accept. Review the inspect step. For a paid run, show the inspected price and set max_cost_usd to the amount the user accepted. If funding is insufficient, send the user to the Edgaze wallet, wait for the balance to update, and retry the intended run without deleting or recreating the server. Read wallet guidance.