Why we bet on MCP early — and what it says about where AEO is going

Questions this guide answers

• What is the Model Context Protocol (MCP) and why does it matter for AEO?
• Why should an AEO platform expose its data via MCP?
• How is MCP different from a REST API for marketing tools?
• Why is SolCrys open-sourcing its Skills extension?
• How does MCP relate to agent-readiness for brands?

Direct answer

We bet on MCP because the same shift that produced AEO — buyers and decision-makers asking AI systems instead of search engines — is now producing a second shift: AI agents acting on behalf of those buyers, and on behalf of marketing teams themselves. Those agents need a typed, discoverable, governed way to read a brand's visibility data and write back into the work queue. REST APIs were built for developers; MCP was built for agents. That distinction is small in the abstract and large in practice — large enough that we decided to build the MCP server first, with the dashboard catching up to it, rather than the other way around.

We also open-sourced the Skills layer (the four workflows that sit on top of the MCP server) under MIT license. That decision is not philosophical. It is an engineering bet that the productive part of an AEO platform — the part that turns visibility numbers into action — has to be inspectable, forkable, and auditable by the customer if AI is going to be trusted to draft the next quarter's content.

The trend, in one paragraph

Anthropic published the Model Context Protocol spec in November 2024 as an open standard for how AI applications connect to external tools and data. In the twelve months since, it has been adopted by every major AI coding interface (Claude Code, Cursor, Continue, Zed, JetBrains AI Assistant), by OpenAI's developer platform, and by the agent stacks of the major application vendors. That is a faster adoption curve than HTTP/2, GraphQL, or LangChain's tool calling. The reason is straightforward: every team building agentic workflows hit the same problem at the same time — how does a model running in client X find, understand, and call tools sitting in service Y without bespoke glue per pairing? MCP answers that question in a way that is small, typed, and self-describing.

What surprised us was not that MCP would win — that seemed likely once OpenAI added support. What surprised us was how quickly the agent-readable surface area started to matter for non-developer use cases. Marketing teams, comms teams, support teams — anyone whose data the LLM should be able to read and reason over — became consumers of MCP through the AI clients they were already using. That changed our roadmap.

Why an AEO platform must be agent-readable, not just dashboard-readable

Eason's Third Audience essay lays out the broader argument: your website now has a third audience after humans and search crawlers — AI agents — and that audience reads differently. The corollary for an AEO platform is symmetric. Your AEO data has a third audience too. Marketing leaders read it on a dashboard. Analysts pull it into spreadsheets. And increasingly, an AI agent — Claude inside a CMO's editor, an internal workflow scripted on top of OpenAI's API, an agency's content-ops automation — needs to read the same data, reason about it, and propose action.

If the only access path is a dashboard with a screen-reader-hostile chart library, none of that is possible. If the only access path is a REST API documented in PDF, none of that is fast. The agent needs to be able to discover what tools exist (`solcrys_list_workspaces` → `solcrys_get_prompts` → `solcrys_get_visibility_insights`), understand what each one returns (typed schemas in the protocol), chain calls based on the user's intent (no glue per pairing), and surface uncertainty when the data is thin (response fields explicitly model confidence). That is what MCP is designed to do, and what a REST API is not.

We are aware that this argument is partially self-serving — we sell an AEO platform with an MCP server in it. But the underlying observation predates our product decision. Every analytics platform whose primary consumer becomes an agent will face the same redesign pressure. We chose to do that work up front rather than retrofit it later.

Why MCP, not REST

Several SolCrys customers have asked, reasonably, why we don't just expose a REST API. The honest answer is that we do — internally — but exposing it to AI agents externally would be wrong fit for three reasons.

REST is right for many things. Programmatic access from a finance system, scheduled exports, server-to-server pipelines — these are all fine REST patterns and we will support them. But for agents reasoning over marketing data interactively, MCP is the right primitive.

• Discoverability. A REST API has documentation that lives outside the API. An MCP server declares its tools, parameters, and return types as part of the protocol. An agent connects, calls `tools/list`, and immediately knows what is available. That removes a class of integration error (agent calls a method that doesn't exist or passes the wrong shape) that consumes a meaningful share of every API integration's debugging time.
• Auth and scope. MCP servers can negotiate OAuth scopes per session, and the SolCrys MCP server is read-only by design. That maps cleanly onto how marketing teams want to share workspace access with agents: scoped to a workspace, time-limited, revokable, and auditable. Building the equivalent on top of a REST API would mean inventing our own scope/token system, which is exactly the work that an open standard is supposed to remove.
• Letting the LLM compose. The most useful thing an LLM does inside an analytics workflow is decide which questions to ask next. Give it tool descriptions and it will chain — pull workspace prompts, then pull visibility, then dig into citations for the worst-performing engine, then audit the page that's missing. Our typical narrative flow is seven tool calls deep; we never wrote glue code for that sequence. The model figured it out from the tool descriptions. A REST API would have required us to ship a SDK that pre-shapes those flows, which is brittle and which we'd be maintaining forever.

What the SolCrys MCP server actually exposes

Nine tools, all read-only, all scoped to a workspace the calling identity is authorized for:

There is no write tool. We deliberately did not ship the ability for an agent to push a content update back into the workspace, even though it would be a one-day feature. The reason is the action externalization argument: actions belong outside the platform, in the systems that actually publish — GitHub, CMS, Slack approval threads. The MCP server is the read surface; writes happen wherever the customer wants the side effect to live, with a human in the approval loop.

• `solcrys_list_workspaces` — workspace discovery, the entry point for any agent that doesn't yet know which tenant to scope to
• `solcrys_get_prompts` — the tracked prompt set for a workspace
• `solcrys_get_visibility_insights` — hero metrics (mention rate, SOV ranking, owned-media %, per-engine breakdown, trends)
• `solcrys_get_prompts_insights` — per-prompt presence %, citation %, sentiment, gainers, decliners
• `solcrys_get_citations_insights` — top-cited domains with source-type breakdown (Owned / Competitor / Editorial / UGC / Other)
• `solcrys_get_citations` — raw citation rows with rich filters
• `solcrys_get_deep_analysis` — per-response structured reasoning, recommendations, action items, brand-position analysis
• `solcrys_get_content_audit_reports` — page-level AEO audit scores (citation readiness, structure, credibility, quality)
• `solcrys_get_tasks` — the action queue: title, status, priority, source

Why we open-sourced the Skills, but not the server

On top of the MCP server we ship four Skills — Claude Skills, the format Anthropic shipped for packaging reusable workflows that auto-activate when relevant. They sit in the SolCrys-AEO-Skills repo on GitHub, MIT licensed.

Two design choices in those Skills matter more than which deliverables they produce. The first is that every Skill references a shared file called `soul.md` — three rules enforced across every Skill: claims must be data-grounded, recommendations must align with the workspace's declared AEO goal, and any writing must be fact-grounded with web search and customer-supplied source documents. That file is in the public repo. If a Skill drifts toward fabrication, the place to look is `soul.md`, and the place to file a PR is the repo. The Skills are inspectable governance, not opaque magic.

The second choice is that we open-sourced the Skills under MIT and kept the MCP server hosted. That asymmetry is intentional. The Skills are workflow templates — the most useful version of them is the one our customer forked, edited, and embedded in their own agent stack. Open-sourcing them removes the gatekeeping; the customer owns the workflow. The MCP server is a multi-tenant data layer — it has to evolve its tool schema, enforce auth, scale, and never leak across tenants. Hosting it lets us iterate without breaking customer agents, and lets the customer rely on a managed surface rather than self-hosting an evolving spec.

• solcrys-weekly-cmo-brief — one-page exec brief: headline KPIs, what's trending, where losing, recommended actions, forward note
• solcrys-domain-influence-report — citation landscape by source type, with strategy implications
• solcrys-brand-footprint-gap-analysis — URLs currently surfacing in AI answers and high-volume prompts where the brand is missing
• solcrys-action-driven-content — publication-ready first draft (blog post, landing page, FAQ) from the action queue

Soul.md as governance, not branding

The `soul.md` file in our Skills repo is the part we are proudest of, and the part most likely to be misread as a branding choice. It is not. It is a prompt-level governance mechanism. Every Skill in the repo references the same three rules:

These rules are short on purpose. They are inspectable on purpose. And they are the most reliable mechanism we know for preventing the failure mode that LLM-generated marketing content most consistently produces — hallucinated statistics, generic recommendations, and copy that reads confident about claims the model cannot verify.

• Data-grounded claims only. A Skill must not invent a metric, a percentage, or a competitor comparison. If the MCP data doesn't support it, the Skill must say so or omit it.
• AEO-goal-aligned recommendations. Recommendations must trace back to the workspace's stated AEO objective (e.g. 'win citation share on procurement prompts'), not to whatever the model's training distribution prefers.
• Fact-grounded writing. Any draft content the Skill produces must be backed by web search results, customer-supplied source documents, or the MCP data — not by the model's prior knowledge.

What this signals about the next eighteen months

We expect agent-readiness to move from a nice-to-have to a buyer evaluation criterion for AEO platforms by Q2 2027, on the same curve that mobile-readiness moved through 2010-2012 and API-first-readiness moved through 2014-2016. The buyer question will not be 'does your platform have an MCP server' — the buyer question will be 'when my team's AI agents call your platform, what do they get back, and how are you preventing them from hallucinating on top of it?' That question is governance-shaped, not feature-shaped, which is why we put as much engineering into `soul.md` as into the tool schemas.

The corollary for brands is harder. The same shift that produced AEO — your buyers asking AI engines first — will produce a buyer-side mirror: your buyers' AI agents asking your website first. We talked about the website side of that in Your Website Has a Third Audience Now. The marketing-tooling side of it is what this essay is about. Both have to be true at once for an AEO program to land — your content has to be readable by agents on the buyer side, and your measurement and action layer has to be operable by agents on the seller side. We built MCP into SolCrys because we want the second half of that to be easy.

How to try it

If you have a SolCrys workspace, the MCP server is already live at `https://mcp.solcrys.com/mcp`. Adding it to Claude Code is one command:

claude mcp add --transport http solcrys https://mcp.solcrys.com/mcp

OAuth handles the connect step the first time you call a tool. For CI or scripted use, a Personal Access Token from the dashboard plugs in via the standard `--header "Authorization: Bearer <TOKEN>"` flag.

The four Skills live at github.com/SolCrysAI/SolCrys-AEO-Skills. The repo README walks through installation into `~/.claude/skills/` and adaptation for other AI clients.

A longer how-to — every tool documented, the typical seven-step workflow, install patterns for different clients — lives in SolCrys MCP and Skills: tools, install, and the workflows that chain them.

FAQ

Related guides