RightsOps — Rights-aware Campaign Operations

WebMCP authority that disappears when the evidence behind human approval becomes stale.

Comment

Short description

RightsOps is a WebMCP-enabled creative-operations workspace for preparing a three-asset social campaign against structured usage-authorization metadata. An agent can inspect evidence and prepare an exact manifest, but only a human can approve it. Approval causes the page to expose one parameterless WebMCP publish tool bound to that manifest. If a selected asset's evidence changes, the manifest becomes stale and the capability disappears. The agent must repair the campaign and regain exact human approval before it can perform a one-shot simulated publication.

Inspiration

Creative operations teams coordinate asset selection, territory, channels, commercial-use constraints, approvals, and publication across interfaces that were designed only for people. Giving an agent generic UI control makes the task faster, but it does not make delegated authority specific, current, or visible. RightsOps explores a stronger model: the website itself tells the agent which structured actions are valid now, and can withdraw a consequential action when its evidence is no longer current.

What it does

The seeded demo asks for three commercial assets for Japan across Instagram and TikTok for six months. The agent uses WebMCP reads to inspect eight candidate assets and prepares an exact manifest with versioned rights proofs. The human reviews and approves that manifest in the UI. Only then does an exact publish_approved_campaign_manifest-<id> capability appear.

A deterministic external rights update increments one selected asset's evidence from v1 to v2. The interface visibly changes from 3/3 current to 2/3 current, marks the proof stale, and removes publish authority. The agent diagnoses the stale proof, finds a replacement, and prepares a new manifest. After human re-approval, a new one-shot publish capability appears. Executing it creates a server-generated append-only demo receipt and audit trail, then consumes the capability.

Why this is a strong fit for WebMCP

WebMCP is not a convenience wrapper in RightsOps; its changing tool surface is the agent-facing expression of current application authority. Structured tools let the agent inspect campaign and rights data without scraping the visual UI. Dynamic registration lets the site expose publication only after a human has approved one exact manifest, remove it when evidence becomes stale, and expose a new manifest-bound operation only after repair and re-approval.

This would be difficult to express safely through ordinary browser actuation. A click-capable agent can see a button, but the page cannot give it the same explicit, typed contract that an operation is read-only, decision-free, manifest-specific, and temporary.

How it creates a better user experience

The human stays focused on the consequential judgment: reviewing and approving the exact campaign. The agent handles structured investigation, candidate selection, manifest preparation, stale diagnosis, repair, and execution. The Capability Surface makes that delegation legible without developer tools by showing the server state, authorization count, observed WebMCP tools, and the causal reason publish authority appeared or disappeared.

The site remains fully usable when WebMCP is unavailable, with a clear compatibility notice. WebMCP is a progressive enhancement that improves agent accuracy and collaboration without becoming the only way to operate the demo.

What humans and agents can do together now

Before this pattern, a human either performed the entire multi-step workflow or gave an automation broad access and manually checked whether its assumptions were still valid. In RightsOps, the agent can do the investigative and mechanical work while the human grants narrow authority for one reviewed artifact. The website automatically withdraws that authority if the supporting evidence changes, and the agent can repair the plan instead of acting on stale approval.

How WebMCP was implemented

The client feature-detects document.modelContext and registers imperative tools with document.modelContext.registerTool(...). Read tools carry readOnlyHint: true. Every registration is scoped to an AbortController; the state coordinator unregisters tools whose operations are no longer valid and then reconciles the judge-visible list through document.modelContext.getTools().

Server workflow state is the source of truth. toolchange events are retained only as telemetry. Draft and Stale expose manifest preparation; Review Ready deliberately exposes no approval tool; Approved exposes exactly one parameterless publish tool containing the approved manifest ID in its name; Published exposes receipt and audit reads. The publish callback awaits the server result before state synchronization removes the consumed registration.

The server independently verifies that the exact manifest was approved, every rights-proof version is current, the manifest hash is unchanged, and the approval has not already been consumed. This preserves fail-closed behavior even if a client has not refreshed its visible tools yet.

How we built it

  • Next.js 16 and React 19 for the application and route handlers
  • TypeScript and Zod for contracts and validation
  • direct WebMCP Imperative API for browser tool registration
  • Drizzle ORM and managed Postgres for server-authoritative workflow state
  • Vitest for domain, server, UI, and WebMCP tests
  • Vercel for the public deployment
  • Codex for implementation, test iteration and verification.

Challenges

The hardest boundary was ensuring that dynamic client capabilities never became the security authority. Tool removal improves what an agent can discover and call, but server freshness and replay checks must independently reject stale or consumed operations. A second subtlety was avoiding cancellation of an in-flight publish call: the tool stays registered until execution completes, then Published-state synchronization withdraws it.

Accomplishments

  • A native WebMCP target-client run discovered and invoked every tool contract.
  • The same session proved exact authority appearance, stale withdrawal, repaired re-approval, one-shot consumption, and refresh reconstruction.
  • The human workflow remains complete when WebMCP is unavailable.
  • Automated coverage proves stale-server rejection, replay rejection, reset from partial state, network diagnostics, and Approved/Stale/Published reloads.
  • Judges can see the causal capability story directly in the product and in paused evidence frames.

What we learned

Dynamic tools are most valuable when their presence carries product meaning, not merely when they duplicate buttons. WebMCP gives a site a structured way to represent temporary delegation, but robust systems still need server-owned truth, exact binding, freshness checks, and replay protection. Observability also matters: a capability lifecycle is far easier to trust when the user can see why authority changed.

What's next

This hackathon build intentionally stays within a synthetic, deterministic scenario. A production version would require authenticated organizations, verified rights-data integrations, policy and legal review, durable audit retention, and authorized publishing-platform integrations. Those are not implemented or claimed here.

Simulation and legal scope

Rights metadata is deterministic structured demo input, not legal analysis or advice. The rights update and social publication are simulated. The WebMCP tool lifecycle, exact human approval, state transitions, database checks, stale/replay rejection, receipt generation, and one-shot consumption shown in the demo are implemented behavior.

Built With

Share this project:

Updates

Submission history