AI Content Drop MCP Server

OAuth sign-in has been verified. Follow the connection steps below.

Two servers, one protocol. Both speak Streamable HTTP and need no SDK.

Compatibility discovery manifest: /.well-known/mcp.json. The JSON claims no experimental server-card schema. Human landing page with per-host install steps: /mcp.

Connecting

{
  "mcpServers": {
    "aicontentdrop": {
      "type": "http",
      "url": "https://aicontentdrop.com/mcp",
      "headers": { "Authorization": "Bearer acd_live_…" }
    }
  }
}

Drop the headers block and the public read tools still work; the account tools stay listed but answer with AUTH_REQUIRED and a pointer to the sign-in instead of running.

Hosts that support OAuth can manage the authorization header for you. The intended flow, subject to the readiness notice above, reads the protected-resource metadata at /.well-known/oauth-protected-resource/mcp, whose resource is https://aicontentdrop.com/mcp, and runs an OAuth sign-in against the issuer it names with the scopes openid email profile offline_access. The token grants the account tools permitted by that connection. An acd_live_ key in the Authorization header is the route for clients that cannot open a browser.

Tools

Studio tools

Where the studio surface is enabled, tools/list also carries the tools that make a finished ad, a UGC presenter video or an avatar. They follow the same contract: the reads answer anonymously, the three that render need a sign-in and a quote_id from estimate_ad_cost, and the marketing-studio-ad skill walks the whole flow.

Board and research tools

Where the board surface is enabled, tools/list also carries the Visual Canvas as tools, and competitor-ad research that lands on it. Every board and every saved ad is account data, so all of these need a sign-in. Adding cards costs nothing; run_generation_card renders a card only with a quote_id from estimate_credit_cost, and decode_ad takes one from estimate_ad_cost with kind decode. A model never tracks a board's revision: every mutating tool reads the current one when it is omitted. The canvas-board skill walks the flow.

Video agent and drama tools

Two more sets need a signed-in account, so a caller without one never sees them in tools/list; both are listed to every signed-in account. The drop tools hand a whole brief to Drop, the video agent, which researches, plans, renders and assembles on a board and stops before every step that charges credits (the video-agent skill). The drama tools write a short vertical drama from a premise, price and render its clips, and cut the episode (the drama-studio skill); the same dramas are open to everyone on the website at Drama Studio.

Every tool carries MCP annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — so a client knows which ones need confirmation before it calls them. The generate_* tools, run_generation_card, decode_ad, produce_drama_episode and approve_video_agent_spend are the ones that spend credits, each only with a quote_id, and writing a drama draft reserves a small writing charge; every tool that writes to the account (imports, board cards, saved ads) is marked non-read-only, so a host asks before running it.

Quotes and idempotency

Every generation starts with a quote. estimate_credit_cost normalises the model, duration, resolution and quantity, prices them at the current rate, and returns credits_required, expires_at and a signed quote_id. The quote is valid for 15 minutes and bound to those exact parameters.

generate_video and generate_image require a quote_id with a quantity of 1. Before anything is submitted the server re-verifies the signature, the expiry, the parameters against the ones in the call, and the current price. Any difference is a typed refusal and nothing runs. The quote_id is also the idempotency key: a retry with the same quote_id returns the original job rather than starting a second one, so a dropped connection cannot charge twice.

Host confirmation dialogs are a convenience, not the safety boundary. A client that auto-approves tool calls gets the same server-side checks.

Errors

A failing tool returns a normal result with isError: true and a typed code in the payload, so the model can branch on it and correct its own call:

Protocol-level problems (unknown method, malformed message) use JSON-RPC error codes as usual.

Inline UI (MCP Apps)

Tools that return a list or a job also return _meta.ui.resourceUri naming a ui:// resource the host can render inline:

A generation that is still rendering wears an animation (light drifting through a developing frame; film edges for a video, crop marks for an image) on the board's card and in the generation card, and the generation card reads get_generation itself until the result lands. The board can brief the video agent: Agent writes a brief from the board, or from the selected cards with their media as references, and starts a drop with start_video_agent and the board's canvas_id, so what the drop makes can go on that board. Each drop working on the board is drawn beside its cards, with its phases, its question or its price, and Place on board for its finished results. Its paid steps are still released only in the chat.

Every view can be shown inline or fullscreen; each resource says so in _meta["openai/ui"].availableDisplayModes as well as in its ui/initialize. The drop and drama views show a price with the sentence to answer in the chat and carry no button that spends: a paid step is released only by approve_video_agent_spend or produce_drama_episode, which the host confirms like any tool that spends.

Fetch them with resources/read. Each is one self-contained HTML document — no build step, no external script, no framework — and each carries its own policy twice over:

• _meta.ui.csp on the resource, which is what a host builds the iframe sandbox from. connectDomains and resourceDomains are per view, not shared: the model picker and the article list load nothing external, the generation card names the origins its finished video and image come from, the ad job card names the same origins for its storyboard sheet and video, and the avatar picker names image origins only.
• A <meta http-equiv="Content-Security-Policy"> inside the document, so a renderer that never read the _meta still gets a scoped policy. frame-ancestors names https://chatgpt.com and https://claude.ai — a view that inherited this site's frame-ancestors 'self' would refuse to render in the only places a view is ever framed.

The two are generated from one object, because a card that declares an empty resourceDomains while rendering <video src> asks the host to block the one thing the card exists to show, and does it silently.

Hosts that read _meta["openai/outputTemplate"] instead get the same URI under that name.

Resources and prompts

resources/list also serves llms.txt, the OpenAPI document, and the pricing document, so a client can pull our reference material over the same connection it acts on. prompts/list offers pick_a_model, write_video_prompt and estimate_a_campaign, plus make_an_ad where the studio tools are enabled and plan_a_board where the board tools are.

Protocol notes

• Streamable HTTP at /mcp: POST for JSON-RPC and a short-lived GET event stream. It is stateless, issues no session id, and answers DELETE with 405.
• Deprecated 2024-11-05 HTTP+SSE at /mcp/sse (or /mcp/docs/sse for the docs server): GET opens the held stream and supplies the same-path POST endpoint in its first event. Only this legacy socket-bound transport uses a session id.
• Single messages follow negotiated MCP 2025-06-18. JSON-RPC batch arrays are

also tolerated as a non-standard compatibility extension; accepting them does not negotiate an older MCP protocol revision.

• Generation never blocks inside a tools/call. It returns a job id and you poll — a render outlives any request timeout.

Where this server is published

Listed in the official MCP registry as com.aicontentdrop/ai-content-drop.

The namespace is not self-asserted. Publishing under com.aicontentdrop required an HTTP domain proof: the registry fetched that well-known path from this origin and checked the Ed25519 public key it serves against the signature on the publish request. The entry points at this domain and this page points back at the entry, so a client can verify the listing in both directions rather than trusting either half alone.

In the browser: WebMCP

The two servers above are for agents that speak HTTP. There is a third surface for an agent that is *already inside the page* — a browser-resident assistant, an extension, or an agentic browser driving a real tab.

The site registers its tools on document.modelContext, the entry point defined by the W3C Web Machine Learning Community Group's WebMCP draft. Same protocol vocabulary as above — named tools, JSON Schema inputs, structured results — with the transport removed. document.modelContext is the canonical surface; navigator.modelContext is a deprecated alias kept for the earliest builds.

// In a page-resident agent, on any page of this site:
const tools = await document.modelContext.getTools();
const picker = tools.find((t) => t.name === "list_models");
const raw = await document.modelContext.executeTool(picker, {
  type: "video",
  max_credits: 30,
});
const { structuredContent } = JSON.parse(raw);
// structuredContent.models → [{ id, name, credits }, …], cheapest first

executeTool resolves with a JSON string, not an object. Parse it, then read structuredContent for the payload or content[0].text for the same payload as text. Arguments are validated before the tool runs and unknown properties are rejected, so pass only the properties in a tool's inputSchema. Nothing throws: a rejected call resolves the same way with isError: true and an error.code to branch on.

What is registered

The in-page tool names are not the HTTP server's names, and the two surfaces do not carry the same set. Eleven tools register by default: four public ones on every page load, and seven more that appear only while a visitor is signed in.

Treat getTools() as the authoritative live list rather than this table: the session-scoped tools are registered on sign-in and removed on sign-out, and the toolchange event on document.modelContext fires whenever the list mutates. Unregistration is by AbortSignal passed at registration; the draft has no unregisterTool.

What costs something

Two registered tools spend credits: generate_video and generate_image. Both spend the signed-in user's credits, both are marked readOnlyHint: false, and credits are charged only when a generation succeeds.

start_credit_topup_checkout is the third readOnlyHint: false tool and the only one that touches money. It is off by default, behind the build-time flag VITE_WEBMCP_CHECKOUT_TOOL, and it is absent from getTools() unless a deployment turned it on. Even then it charges nothing on its own: it creates a checkout link for a one-time credit pack and hands the URL back. It never navigates the tab and never completes a purchase — the person does that themselves.

Every other tool is readOnlyHint: true. A host deciding what an agent may call unattended should gate on that annotation rather than on a tool name, because the set of names grows.

Both generation tools accept an optional confirm_credits. Supply the number estimate_credit_cost returned and it is enforced exactly — if the real cost differs, the call returns COST_MISMATCH and nothing is submitted. It is optional by default so an agent's first call is not guaranteed to fail, and a deployment can make it mandatory.

Tools also carry untrustedContentHint, true wherever a result can quote text this site did not write — article copy, a user's own prompt, a model's failure message — which a host should never read as instructions.

Credentials: there are none

This is the whole reason the surface exists. An in-page tool runs as the person already signed in to the tab. It runs on the session the browser already holds, so there is no API key to mint, paste, store, or rotate, and no key that can outlive the tab or leak into an agent's transcript. The tools that touch an account need the visitor signed in; the catalogue and the guides do not.

Nothing about this weakens the account boundary: every call lands on the same authenticated endpoints the UI itself calls, with the same credit accounting and the same permission checks. A tool that spends credits spends the signed-in user's credits, and only the three tools marked readOnlyHint: false change anything.

The HTTP server is not deprecated by any of this, and neither surface is a fallback for the other. It stays the credential-based surface for every agent that is not inside a browser tab, and an agent that cannot open a browser needs the key.

Browser support

document.modelContext is a draft, not a shipped web platform feature. Chrome exposes it behind an origin trial (Chrome 149–156); everywhere else the object is simply absent and this page behaves like any other page. A page-resident agent should feature-detect rather than assume:

if (document.modelContext) { /* tools are available here */ }

Because the trial is per origin, tools registered on this site are visible only on this site's pages, and only while its trial token is live.