What data is available in Conductor's MCP?

​

Data

Data tools reference your Conductor platform data. Each call to one of these tools consumes a call against your organization’s allotment of MCP calls.

​

AI Search

The Conductor MCP includes AI search data through the following tools:

• ai_brand_insights
• ai_citation_insights
• ai_query_fan_out_insights

These tools provide insights across the following dimensions and topics.

​

Brands

This data reflects which brands (yours and competitors’) get mentioned in AI search answers across Conductor’s supported AI search engines. For an LLM, this is the “awareness” layer: it lets you answer “who’s showing up and how often?” with market share, share-of-voice, and breakdowns by topic, persona, intent, and search engine. It’s essential for competitive positioning and identifying where your brand is invisible. ai_brand_insights supports a prompts_groups filter, so you can scope any query to one or more prompt groups (e.g. “B2B topics,” a campaign, a product line) and match on any or all of the groups selected.

​

Citations

This data reflects which URLs and domains AI engines cite as sources when answering prompts. Where brand data answers “am I being talked about?”, Citations answers “am I being trusted as a source?” For an LLM, this is the “authority” layer. It’s critical for diagnosing why a brand might be mentioned frequently but not driving traffic, and for URL-level drill-down to see which specific pages earn citations for which prompts. This is where content strategy recommendations actually get actionable. ai_citation_insights supports two group-based filters:

• prompts_groups: scope citation data to one or more prompt groups, matching on any or all of the groups selected.
• pages_groups: scope citation data to named URL groupings (e.g. “Blog Posts,” “Product Pages”).

​

Sentiment

This data captures the quality of brand mentions: positive, neutral, negative, plus category-level breakdowns (quality, price, ethics, experience, etc.) and source attribution (which domains are driving which sentiment). Sentiment queries also support drill-down to the source and specific snippets, so you can break sentiment data down to the full URL rather than just domain or subdomain. This lets you see exactly which pages are driving which positive vs. negative AI mentions. For an LLM, this turns raw mention counts into narrative. You can surface actual quotes, identify reputation risks, and explain why a brand’s perception is shifting. Indispensable for PR and reputation analysis, not just visibility counting.

​

Fan out queries

This data reflects the fan out queries behind each AI response—the individual research queries an AI engine generates for a single prompt. AI engines rarely answer a prompt with one search; they break it into multiple queries and gather information from across the web before composing an answer. Where Brands and Citations describe the final answer, this data exposes the research path that produced it. For an LLM, this is the “interpretation” layer: it answers “how does AI research this before answering?” You can see the exact fan out queries behind any response, which topics and keywords engines treat as relevant, and where content gaps leave a site out of the research path. It also tracks brand appearances inside the fan out queries—not just the final answer—an intermediate signal most AI visibility analysis misses. ai_query_fan_out_insights supports several analysis modes beyond retrieving the raw queries, including fan out depth metrics and outlier detection (responses with unusually deep fan out surfaced automatically), per-brand fan out query appearance rates, and side-by-side comparison of how different engines decompose the same prompts. Results can be filtered by engine, prompt type (branded or unbranded), persona, intent, specific prompt, brand, cited domain, and date range, and broken down by dimensions including topic and fan out depth. Fan out query data is available for Gemini, Claude, ChatGPT, and Grok.

​

Traditional Search

The Conductor MCP includes traditional search data through the keyword_insights tool. This tool provides insights across the following dimensions and topics.

​

Rankings

This data reflects how your website ranks in traditional search results for your tracked keywords over time. It includes keyword group data to aggregate visibility reporting. keyword_insights also supports a pages_groups filter, so ranking-page data can be scoped to named URL groupings (e.g. “Blog Posts,” “Product Pages”). For an LLM, this is the “position” layer: it answers “where do I rank, and is it improving?” across the whole keyword set or any slice of it (by group or location). It’s the foundation for diagnosing visibility wins and losses and for prioritizing which keywords or markets need attention.

​

Seasonality

This data captures monthly search volume trends for your tracked keywords, typically spanning the last 24 months. For an LLM, this is the “demand” layer. It lets the model explain why visibility or traffic shifts—separating ranking changes from changes in underlying search interest—and time content and campaign recommendations to seasonal peaks.

​

Result type

This data reflects which SERP features each keyword’s results are made up of: Standard Links, People Also Ask, Local Pack, and other result types. For an LLM, this is the “opportunity” layer. It explains why ranking well doesn’t always drive clicks and surfaces where features like PAA or Local Pack are reshaping the page—turning rank data into concrete content-format and optimization recommendations.

​

Competitive rankings

This data compares your rankings head-to-head against up to three competitor domains for your tracked keywords. For an LLM, this is the “benchmark” layer. It answers “who’s beating me, and where?” so the model can frame visibility in competitive terms, identify keywords where rivals are pulling ahead, and ground gap analysis in real position data.

​

Keyword details

This data provides single-keyword deep dives: a rank snapshot, week-by-week rank history, monthly search volume trend, and the full SERP results for one keyword. For an LLM, this is the “drill-down” layer. When a user asks about one specific keyword, it lets the model move from account-wide summaries to the exact rank trajectory, seasonality, and live SERP for that term—where granular, actionable answers actually come from.

​

Content

Content tools run the Writing Assistant workflow inside your AI assistant, so you can plan, write, and score a piece of content without leaving the conversation. Unlike the Data and Account Configuration tools on this page, some Content tools write to your account. They create and change briefs, drafts, Content Profiles, and Knowledge Sources, and they can use up your organization’s allotted drafts. Conductor has configured the MCP to always ask for your confirmation before it makes a change that would use a draft. The tools cover two workflows—content brief and scoring, then writing assistance—plus the Content Profiles and Knowledge Sources that shape what gets written.

​

Content brief and scoring

Every content workflow starts here. A brief sets the standard for the piece: it describes what a well-optimized version looks like, based on content that already performs well for the topic. Writing and scoring both measure against that standard.

​

Briefs

A brief is where you decide what the content needs to cover before anything is written. You can start one for new content, for a live page you want to improve, or from unpublished HTML. For an LLM, this is the “plan” layer: it lets the model agree the shape of the content with you before a single sentence is written. create_content_brief is the way in for all three starting points. It creates the draft, researches the topic, and returns the brief. get_content_brief_insights reads that brief back—a short summary by default, or the full detail when you ask for it—and update_content_brief_insights applies your changes. These are the same insights you would edit under Customize Your Insights in the platform.

​

Scoring

Scoring tells you how well content meets the brief, and what to fix first. You can run it as often as you like: score what you have, revise it, then score again to see whether the change helped. For an LLM, this is the “evaluation” layer: it closes the loop between what was planned and what was produced. get_content_score scores content against the brief. It returns an overall score, a prioritized list of improvements, and a breakdown of each dimension with a summary and the reasoning behind it. Intent and topical coverage scores are included. A brief built from an existing URL or HTML arrives with its score already attached, while a new brief has no content to score yet.

​

Writing assistance

Once a brief exists, these tools write and revise the content against it, then finish the piece with a title, meta description, and internal links.

​

Drafts

A draft holds the content itself—the title, title tag, meta description, and body—along with the source URL you are optimizing. For an LLM, this is the “production” layer: where a plan becomes reviewable content. list_drafts finds your drafts as short summaries, and get_draft reads one, returning just the fields you ask for so that checking a single detail doesn’t pull an entire draft body. generate_draft_content does the writing across three modes:

• Outline produces a structured outline.
• Draft writes your content from scratch or regenerates it completely.
• Revise edits the content already on the draft. Use it for any targeted change, like rewriting one section, shortening, or retargeting the audience—and say what should stay unchanged. Ask for a revision rather than a new draft when you want to keep existing work.

update_draft_content saves your copy edits to the title, title tag, meta description, and body. Each save includes the version your assistant last read, and Conductor rejects it if the draft changed in the meantime. So if you have been editing the same draft in Writing Assistant in another tab, expect that rejection—have your assistant re-read the draft before it saves again.

​

Editorial suggestions

These tools propose options for the finishing touches on a piece. Nothing is applied until you pick what you want. For an LLM, this is the “refinement” layer: bounded, reviewable options rather than silent edits. suggest_title_and_meta_descriptions returns up to five title tag and meta description options. suggest_internal_links returns up to twenty link candidates, each with its anchor text, the surrounding sentence, the target URL and title, and why it was suggested. Once you choose the ones you want, update_draft_internal_links inserts them into the draft. Suggestions are created fresh each time and aren’t saved, so asking twice can return different results. Internal links are deliberately review-first, because the same anchor text often appears in several places and inserting links blindly would be unsafe.

​

Workflow status

Writing a brief and generating content both take time to run, so your assistant needs a way to check whether the work has finished. That check spans both workflows rather than belonging to either one. get_draft_progress reports on a run using the draft’s ID, and your assistant keeps checking until the run succeeds, fails, or is cancelled. When a brief finishes, the result includes the brief itself, its score summary, and a link to open the draft in Conductor. After content generation, your assistant calls get_draft to provide information about the draft, including title, meta descriptions, and more.

​

Content Profiles and Knowledge Sources

These are the reusable context you set up once and apply to many pieces of content: a Content Profile carries your voice, and Knowledge Sources carry your source material. You attach either one while creating a brief or generating content, and both shape the writing rather than the brief’s research. You cannot delete a Content Profile or a Knowledge Source through the MCP.

​

Content Profiles

A Content Profile holds the brand voice, writing style, target audience, and usage rules that shape what gets generated. Exactly one profile applies to a draft. For an LLM, this is the “voice” layer: consistent style across everything generated, without restating it each time. create_content_profile, list_content_profiles, get_content_profile, and update_content_profile manage these profiles. An update replaces the whole profile rather than merging into it, so anything left out is cleared instead of kept—have your assistant read the full profile before it changes one part of it.

​

Knowledge Sources

Knowledge Sources ground generated content in your own material rather than the model’s general knowledge. You can attach up to five of them to a brief. For an LLM, this is the “grounding” layer: your research and source material, not the model’s assumptions. add_knowledge_source creates a source from content you supply. list_knowledge_sources finds the sources you already have and returns only their details, never their text, while get_knowledge_source reads one and returns its text only when you ask for it. When you generate content, the sources you name replace whatever is already attached to the draft instead of adding to them. To keep the current set of sources attached to your draft, don’t ask to add additional sources at all.

​

Account Configuration

The Conductor MCP includes account configuration data through the tracked_configs tool. Each call to one of these tools consumes a call against your organization’s allotment of MCP calls. This is the metadata layer in your data: what topics, prompts, brands, competitors, personas, intents, locales, and search engines you are tracking for a given account. For an LLM, this information grounds queries, preventing hallucinations and letting the model resolve fuzzy user references (“my UK brand,” “the retirement topic”) into the exact identifiers needed for data queries. Without it, every downstream queries could be filtering on data that doesn’t exist.