MCP-compatible agents drive GENYS as a system of record: read state, propose decisions, execute under Policy. The contract surface is /developers; this page is the narrative.
What you are reading
GENYS is MCP-addressable. Any MCP client — Claude Desktop, Claude Code, custom agents — can drive the decision runtime through the same tools that gate in-app actions. AdResonance is the first vertical product built on GENYS; its ad-operations tools below are one worked surface.
Why agent-addressable
A Claude or GPT agent on top of a dashboard can describe what to do next. It cannot persist a Decision, evaluate it against Policy, pause for approval, execute across channel APIs, and write an audit log against the decision id that caused it. That is the difference between an advisor and an operating surface.
The MCP endpoint makes GENYS operable by agents under the same Policy engine that gates in-app actions — no separate trust surface, no second governance model. Every vertical built on GENYS inherits the same addressability by construction.
How MCP changes the model
From chat transcripts to queryable records.
An agent's reasoning in a chat is not an audit trail. A Decision persisted with its inputs, confidence, and policy version is.
From dashboard clicks to typed tool calls.
Mutation tools take typed parameters, not screenshot-driven UI paths. Execution is reproducible and loggable.
From assumed authorization to explicit approval.
Every mutation tool evaluates Policy. Approval is a contract, not an organizational habit.
Auth boundary
Agents act as an authenticated identity — today either a dashboard user (via Clerk session) or a partner identity (via API keys configured per engagement). The full contract lives on /developers. Short version: every MCP call is attributable, every mutation is logged against the acting identity, and every action passes through Policy.
Approval boundary
Two different tools do two different things. get_recommendations returns candidate Decisions — typed, confidence-scored, and annotated with the policy_version they would be evaluated against. Calling that tool does not change platform state.
execute_decision is the mutation path. It triggers a fresh Policy evaluation under current rules. The result is allow, require_approval, or deny. Only allow proceeds straight through to channel execution; require_approval pauses until a human acts; deny halts and records a refusal.
No agent, however trusted, bypasses Policy in v1. That is a contract choice, not a limitation — it is what makes the audit trail load-bearing.
One realistic agent flow
This is the path an MCP agent takes to raise a Meta campaign's budget by $120/day when qualified-quote signal rises 18% week-over-week. Six steps, four primitives, one decision_id threading through all of them.
get_campaign_performanceAgent reads current state.
A read tool. No state change. The agent observes current spend, impression volume, and qualified-lead signal for a campaign. This step establishes the input half of a Decision — what the system is reasoning over before any action is proposed.
No primitive touched yet.
get_recommendationsAgent retrieves a candidate Decision.
A proposal tool. Returns one or more Decision objects, typed and confidence-scored, with the policy_version they would be evaluated against. Recommendation is not authorization: the Decision is a candidate, not an executed action. The agent can discard it, forward it to a human, or attempt execution in the next step.
Decision created (candidate).
execute_decisionAgent requests execution.
A mutation tool. The Policy engine re-evaluates the candidate Decision against the current rule set and returns allow, require_approval, or deny. On allow, a Workflow run starts and proceeds to step 5. On require_approval, the Workflow pauses and step 4 becomes required. On deny, execution halts and a refusal event is written.
Policy evaluation written. Workflow run enqueued.
Human approval in dashboardHuman advances a paused Workflow.
If Policy returned require_approval, the Workflow run is in paused_for_approval state. A person with the authz scope to approve this action reviews it in the dashboard and approves or rejects. An override reason can be recorded. Approval does not bypass Policy — it resolves the approval gate Policy produced.
Workflow advances from paused_for_approval to running.
Platform mutation executesChannel API is called.
The Workflow's execution step calls the relevant platform adapter (Google, Meta, Amazon, Pinterest, or X) under the campaign's configured credentials. Failures compensate earlier steps where applicable. Idempotency_key prevents double-execution on retries.
Mutation Log entry written with status=pending, then success or failed.
Mutation Log persistedTrace closes.
The Mutation Log entry references the originating decision_id. That id is now the single join key across the full trace: Decision, Policy evaluation, Workflow run, Mutation Log. Any future query — 'why did this budget change on Tuesday?' — starts here.
Trace complete. Decision, Policy, Workflow, Mutation Log all share decision_id.
What this flow proves.
Decision persistence: step 2 writes a typed, confidence-scored candidate. Policy enforcement: step 3 re-evaluates and may pause. Durable execution: step 5 runs under an idempotency_key inside a pausable, compensatable Workflow. Cross-channel mutation lineage: step 6 writes a Mutation Log entry keyed to the originating decision_id. The four properties of an operating record, in one path.
Tool surface
Read tools observe. Proposal tools produce artifacts without changing platform state. Mutation tools change state and pass through Policy. Group membership is part of the contract.
Observe current state. No side effects, no policy evaluation required.
list_campaignsEnumerate campaigns across connected channels.
get_campaign_performanceSpend, impressions, and qualified-signal metrics for a campaign.
get_recommendationsCandidate Decisions for a campaign or account. Not authorization.
get_brand_contextBrand voice, keywords, approved-claim library references.
get_platform_connectionsWhich channels are connected for the active org.
get_blockersOutstanding issues blocking decisions or executions.
Produce artifacts — candidate Decisions, ad copy, analyses. No platform state changes.
evaluate_decisionsRun the decision evaluator and return candidate Decisions with policy context.
generate_ad_copyProduce ad copy variants against brand context. Returns artifacts, does not publish.
analyze_websiteExtract brand and product context from a URL. Returns analysis, does not mutate state.
Change state. Policy-gated. May return require_approval. Mutation Log is written.
create_campaignCreate a campaign on a connected channel. Policy-gated; may require approval.
execute_decisionExecute a Decision by id. Policy-gated; may require approval.
dismiss_decisionDismiss a candidate Decision. Writes a refusal event, no channel-side mutation.
If you are wiring a Claude, Claude Code, or custom MCP client against GENYS — start with the contract on /developers. For partner-issued API key access or non-standard tool surfaces, engage through enterprise intake.
Pay on what the system governs. Scale without upgrading.