Run Competitive Intelligence From Claude Code

01The short answer

You can run a complete competitive intelligence cycle without opening a dashboard, and the reason it works is not that chat is a nicer interface. It is that the two halves of the job have different owners. Judgment work, which means reading a competitor brief and deciding what it means for next quarter, is something a reasoning model does well the moment it has the facts. Measurement work, which means knowing what four answer engines actually said about your buying questions last Tuesday and how that changed since last month, is something no model can do unaided, no matter how good the prompt is. Connect a measurement source over MCP and both halves land in the same conversation.

What follows is the loop we run and the loop the connector was designed around. Six tool calls carry it. Everything else in the 65-tool surface is refinement on one of those six. Every tool name printed here exists on the live connector, and the full parameter list for each one is in the connector tool reference.

02Why the loop moved into the agent

The move out of dashboards is not an aesthetic preference, it is a complaint about overhead, and practitioners have been unusually blunt about it. The most quoted framing in this space right now is short enough to fit in a sentence.

The same argument shows up with the tab count attached. One practitioner described the appeal as being able to skip “the 15-tab BI dashboard” and ask a plain question instead, and another put the same point in terms of client work: it “avoids the full logging in to a financial portal drama when a client asks a finance question” (both via r/mcp). A longer version of the argument has been circulating under the name the Death of the Dashboard:

The behaviour that follows from this is worth noticing, because it is what actually forces vendors to move. People do not wait for the vendor. They rebuild the workflow themselves inside their own agent, and they do it with whatever access they can get. One founder described watching it happen every week: “I see people in support communities building DIY versions of this with Claude Code and MCP servers every week” (via r/SaaS). Another described abandoning an in-product assistant halfway through building it for exactly this reason.

The honest counterpoint, and the best one in the thread, is that the interface does not disappear. It changes job. “I do not think the UI disappears. It becomes the place where users inspect state, fix policy, and approve higher-risk actions. The agent gets the repetitive path; the UI keeps the judgment path” (via r/SaaS). That is right, and it is why this article does not claim you will never open a browser again. It claims that the research loop, the part you run weekly, belongs in the agent, and that the browser is for onboarding, billing, approving something consequential, and showing a result to someone who is not in your chat window.

Worth knowing what already ranks for this, because the gap is instructive. The best existing walkthrough of competitor research in Claude Code uses the built-in web search, runs about five minutes, and produces a genuinely good markdown report. The best existing walkthrough of competitor research in Claude web opens with a disclaimer from its own author that AI tools alone are not enough for thorough competitive analysis and that you need a dedicated tracking tool. Both are correct. The unwritten piece is what happens when the tracking tool is inside the agent instead of next to it.

03Connect once, then forget it

Three values and one browser sign-in, and none of them is an API key. The connector lives at https://mcp.linkeddit.com/mcp, the OAuth client id is linkeddit-mcp-claude, and the client secret field stays empty because it is a public PKCE client. In Claude Code the whole thing is one line:

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

Then /mcp inside Claude Code to authorize in the browser. In Claude.ai it is Settings, then Connectors, then Add custom connector, then paste the URL and the client id under advanced settings. Cursor and Windsurf bridge the OAuth flow with the mcp-remote package; VS Code takes the HTTP URL directly. The per-client detail lives in the setup guide, and this article assumes you have finished it.

One more thing to settle before the loop. How many servers should be connected at once is a real question with a real cost attached, and the answer is fewer than instinct suggests. That argument is its own article: the MCP-first GTM stack covers which servers earn a slot and why subtraction improves the ones you keep.

04The loop, in six calls

Here is the whole cycle before the detail, so you can see the shape. Each row is one tool call and one job. The sections after this walk each step with the prompt that triggers it.

Two things to notice about that table. The first is that only one row is a write, and it is the last one. Research is overwhelmingly a read workload, which is why the connector is safe to leave enabled in a working session. The second is that no row in it generates prose. The generation step is not missing from the loop, it is just not ours: it happens in your agent, between rows five and six, and section nine explains why we made that choice on purpose.

051. Ground the questions in real demand

Start from queries buyers actually typed, not from questions you invented in a planning doc. This is the step almost every competitor-research workflow skips, and it is the one that decides whether the rest of the loop measures anything that matters. gsc_queries_get returns the search queries real buyers used to reach your site, ranked by impressions, with clicks and average position attached. That is a demand list with evidence behind it rather than a brainstorm.

Pull the last 90 days of Search Console queries for my project.
Group them into buying questions versus navigational or brand
queries. For the buying questions only, show impressions,
clicks and average position, and flag the ones where we have
high impressions and a position worse than 10.

That grouping is judgment work, so the agent should do it and we should not ship a classifier for it. What we ship is the numbers. Note the shape of the answer you want out of this: high impressions plus a bad position is the definition of demand you are visible for and losing. Those are the questions worth measuring in an answer engine, because they are the ones where a buyer is already asking and someone else is already being recommended.

Now turn that into a tracked prompt set. answer_prompts_propose generates a draft set of commercial-intent buying questions for a project, and it is explicitly a draft for you to approve rather than a set it commits on your behalf. answer_prompts_list shows what is currently tracked and answer_prompts_update edits the set. The approval step is not ceremony: every prompt in the set costs measurement on every run, so a sloppy set is a recurring bill for noise.

Propose 12 commercial-intent prompts for the project, then
compare them against the Search Console queries you just
pulled. Drop any proposed prompt that has no demand behind it,
add any high-impression buying question that the proposal
missed, and show me the final list before you save it.

That single prompt is a good illustration of why the loop belongs in an agent. Reconciling a proposed list against a demand list is a two-source judgment call. In a dashboard it is two tabs, a CSV export and a spreadsheet. In a conversation it is one sentence, and the reconciliation happens in the place where you can argue with it.

062. Measure the engines

Estimate first, then start the audit, then poll. Never block a conversation on a fan-out. An audit reserves budget, fans measurements out across the engines, and aggregates the results into gaps. It is the only genuinely expensive step in the loop, which is why answer_audit_estimate exists as a separate read-only call that returns a cost with no spend attached. Run it first. Always.

Estimate an audit for the project across all tracked prompts
at 3 samples per prompt, US geography. Show me the estimate.
If it is inside my remaining credits, start it and then check
back in sixty seconds rather than waiting.

answer_audit_start is the managed path: it reserves the budget, fans out the provider measurements and aggregates them. It takes an idempotency key, which matters more in an agent than in a browser, because an agent that hits a timeout and retries would otherwise double-charge you for the same measurement. If you have already created a run in a pending state, answer_audit_launch kicks it off asynchronously and returns immediately.

Then poll. answer_run_get returns one run and its status, and answer_runs_list shows the history. The instruction to give an async run a minute before polling is in the tool documentation for a reason: an agent left to its own devices will poll in a tight loop and burn its own context doing nothing. Tell it to wait.

The samples-per-prompt parameter deserves a sentence, because it is the one people get wrong. Answer engines are not deterministic. Asking a buying question once tells you what one sample said, not what the engine believes. Three samples is the smallest number that lets you tell a consistent recommendation apart from a coin flip, and the metrics carry their sample counts in a disclosure block precisely so that nobody reads a one-sample result as a trend.

073. Read the gaps, not the vibes

A gap is a specific, ranked, evidenced miss: this question, this engine, this competitor named instead of you, these citations. answer_gaps_list returns them ranked by intent, evidence and confidence, so the top of the list is where a real buyer asks a real question and gets a real competitor as the answer. answer_gap_get opens one, and the structure of what comes back is the part worth understanding: observations, citations, hypotheses and recommended actions are kept strictly separate. That separation is the whole product. A tool that blends what was observed with what someone thinks it means produces confident narrative you cannot audit.

List the open gaps for the project. Take the top five, open
each one, and for each tell me: the exact prompt, which
engines answered it, who they recommended instead of us, and
which sources they cited. Keep observations separate from
your own interpretation, and label which is which.

Around that core there are four reads that answer different questions, and knowing which one to reach for saves a lot of wandering. answer_metrics_get is the scoreboard: presence rate, recommendation rate, share of voice, mean ordinal position, sentiment mix and citation share, each carrying its own definition and a disclosure block naming the sample counts and versions behind it. answer_trends_get is the same numbers over time, which is the only version that tells you whether anything you did worked.

answer_content_gaps_get is the one that turns measurement into a task list. It scores each tracked page against each measured question and returns the requirements the engines agreed on, which of them the page covers, and which it misses by name. That last clause is the useful part: not a score, a named list of missing requirements. And answer_fanout_get returns the web searches each engine actually issued while answering your prompts, grouped by prompt and segment, which is the closest thing to a keyword list an answer engine will ever hand you.

For the three worst-performing tracked pages, run the content
gap analysis and show me the named requirements each page is
missing. Then pull the query fan-out for the same prompts and
tell me which of those searches we have no page for at all.

If you want the conceptual background on why answer engines behave this way, the AEO-from-your-assistant overview covers the measurement model without the tool-call detail.

084. The competitor half

Answer-engine gaps tell you where you are losing. Competitor briefs tell you what the winner did. You need both in the same conversation or you are guessing at causation. get_competitor_brief returns the graded brief for a tracked competitor: their moves, their complaint themes, the evidence behind each. list_competitor_monitors shows what is being tracked, get_competitor_changes returns what changed, and get_weekly_brief is the roll-up across all of them.

The one people underuse is get_switching_signals. A switching signal is somebody publicly describing why they are leaving a product, which is the single highest-intent artifact in competitive intelligence and the hardest thing to get from a general web search, because the model has no way to tell a two-year-old complaint from one posted this week. Mined across review sites, discussion communities and the open web, and dated, it becomes a list of live reasons a buyer is currently in motion.

Pull this week's competitor brief for each tracked competitor.
Cross-reference it against the answer-engine gaps you already
listed: for every competitor that engines recommended over us,
tell me what that competitor shipped or changed in the same
period, and pull their switching signals. I want the overlap
between what they are being recommended for and what their own
users are complaining about.

That overlap query is the thing a dashboard cannot do without you doing it by hand across four screens, and it is where the agent earns its place. Two ranked lists, one join, one sentence. The output is a short list of positions where a competitor is winning the recommendation while their own users are publicly unhappy about that exact thing, which is the most actionable artifact the whole loop produces.

Underneath the briefs there is a raw corpus you can query directly when a brief raises a question it does not answer. reddit_search, reddit_fetch_subreddit, reddit_fetch_post_comments and suggest_subreddits reach the discussion layer; keyword_serp and keyword_autocomplete reach live search data; get_keyword_results and list_keyword_jobs return scored keyword jobs. On the pipeline side, search_leads and get_lead_insights return the buyers already surfaced by intent, and create_lead_pipeline plus get_pipeline_results run a new one. If discussion mining is the part you care about most, the discussion-research workflows guide goes deeper on that family specifically. Broader background on how the competitor briefs are assembled is on the Compete overview.

095. The agent writes, we check the sourcing

We deliberately do not ship a copy generator, and this is the section where that decision either earns its keep or does not. The rule behind the whole connector is short: if the capability is something Claude already does well once it has our data, we do not build it. Drafting a brief or an article from evidence is the founding example. Your agent has your tone, your product context, your previous drafts and the ability to argue with you about the angle. We have none of that. A generator on our side would be a worse writer wearing a vendor logo, and it would be metered, because generation is the one workload whose cost scales with how much you use it.

So the two tools in this step do the opposite of generating. answer_fix_draft returns a deterministic evidence skeleton for a gap, assembled from the gap summary, the observed facts and the recommended actions, with no model involved at any point. It is scaffolding with the citations already attached, not a draft. You or your agent then write the actual thing.

Then answer_fix_check, which is the one that only we can build. You hand it a draft you wrote and it reports whether every URL and every citation id in that draft appears in the evidence the gap's run actually recorded. It writes nothing and rejects nothing. It reports every problem at once rather than raising on the first, because one exception per rewrite is useless to an agent, and it returns the evidence that does exist, which is what turns a rejection into a rewrite instead of a dead end.

The rest of this family is state, which is the other thing a chat session cannot hold on its own. answer_fix_save stores a fix for approval, answer_fixes_list and answer_fix_get read them back, answer_fix_update edits one, and answer_sources_fetch pulls a cited web page into the evidence store so a fix can legitimately cite it. That last one refuses rather than degrades: a URL resolving to a private address, redirecting into one, returning a non-text type or exceeding the size cap comes back marked blocked or too large with a reason, which means we declined to fetch it, not that the page was empty.

Take gap 3. Pull its evidence skeleton, then write me a
900-word brief that closes it, in our house voice, citing only
sources from the recorded evidence. Before you show it to me,
run the sourcing check on your own draft and fix anything it
flags. Then save it for approval and register a
re-verification.

The last clause matters. answer_verify_start registers a re-verification of a gap: the same prompts, the same configuration, re-measured after an indexing delay. It deliberately starts no run immediately, because the delay is the entire point. Publishing something and re-measuring the same afternoon tells you nothing. answer_verify_get reads the result after the follow-up date. This is the durability half of the argument for building anything at all: a chat session cannot remember to check something in three weeks, and a scheduled job can. answer_schedule_set is the same idea for recurring audits.

106. Get it out of the chat

The one thing a conversation genuinely cannot do is show a result to somebody who is not in it. answer_share_create produces a link that shows one gap, one run, one fix or a project's metrics to someone without a Linkeddit account. It is the governed side effect in the loop, which is exactly the category the build test says a vendor should own. answer_shares_list shows what is live and answer_share_revoke kills one.

Two constraints on share links, both deliberate. The link shows the summary only, never the underlying answer text or the cited sources, and it expires in 30 days. And the full URL is returned exactly once, by the create call, and cannot be recovered afterwards. In an agent that means one thing in practice: tell it to write the URL down somewhere the moment it gets it.

Create a share link for the run and label it with this
week's date. Print the full URL in your reply and also append
it to notes/competitive-review.md with today's date and a
one-line summary of what the run found.

Two other tools close out the reporting side. answer_digest_get returns the weekly brief, answer_activity_list is the audit trail of what happened in the project, and answer_usage_get shows what you have spent against your allowance, which is the call to make before kicking off a large audit rather than after. On the action-queue side, answer_actions_list, answer_action_get and answer_action_update hold the shared todo state between the agent and the human, across sessions.

11The whole loop as one prompt

Once the connector is authorized, this is a single message that runs the entire cycle. It is long on purpose. A vague prompt against a 65-tool surface produces a model guessing at which tool you meant, and the fix for that is naming the sequence rather than hoping.

Weekly competitive review. Work through this in order and
show me each step's output before moving on.

1. Pull the last 90 days of Search Console queries for my
   project. Flag buying questions with high impressions and a
   position worse than 10.
2. Show me the current tracked prompt set. Tell me which of
   the flagged questions are missing from it. Do not change
   the set yet, just tell me.
3. Estimate an audit at 3 samples per prompt. If it is inside
   my remaining allowance, start it, then wait a minute before
   polling for the result.
4. When the run completes, list the open gaps and open the top
   five. For each: the prompt, the engines, who was
   recommended instead of us, the sources cited.
5. Pull the metrics with their disclosure blocks and compare
   them to the previous run. Tell me what moved and whether
   the sample size supports calling it a move.
6. Pull each tracked competitor's brief and their switching
   signals. Join that against step 4 and give me the list of
   positions where a competitor is winning the recommendation
   while their own users complain about that same thing.
7. Pick the single highest-intent gap. Pull its evidence
   skeleton, write the fix in our house voice, run the
   sourcing check on your own draft, fix what it flags, save
   it for approval, and register a re-verification.
8. Create a share link for the run, print the URL, and write
   the whole review to notes/competitive-review.md.

Rules: name the tool you called at each step and quote the run
id. If a step returns nothing, say so rather than filling the
gap from memory.

Those last two rules are not decoration. They are the defence against the two failure modes in the next section, and dropping them is how you end up with a plausible weekly review that nothing measured.

Save it as a slash command or a project file and it becomes a weekly ritual that costs one message. In Claude Code, a CLAUDE.md carrying your company name, positioning and house voice removes the need to restate any of that, which is the same trick every competent Claude Code workflow uses and one of the few pieces of advice in the existing literature that transfers cleanly to a connector-backed loop.

12What this cannot do

A tool call is not magic, and a workflow article that only lists wins is marketing. Here is what actually goes wrong, in rough order of how often.

The model skips the tool. This is the worst one because it leaves no evidence. As one practitioner put it: “The worst tool-use failure is the one where the agent didn't call your tool at all. No span shows up in your trace because there's no API call to capture. The model just makes up an answer that sounds right” (via r/LLMDevs). The defence is the rule in the prompt above. Make it name the tool and quote the run id, and treat any number without a call behind it as unmeasured.

A call succeeds and the payload is wrong. “The server connects fine, the tool call returns 200, and the actual content is stale data, a parsing error wrapped in a success response. Regular uptime checks are useless here because nothing is technically down” (via r/microsaas). Our answer to this is the disclosure block: every metric carries its sample counts and versions, so a result computed from a thin sample says so on its face rather than looking identical to a solid one. Read the disclosure. That is what it is for.

Tool definitions cost context. Every connected server ships its tool definitions into the context on every request. Practitioners call it the Context Tax, and with several servers connected it is a real fraction of the window gone before you type anything. Sixty-five tools is not free. If your session is doing something else demanding, disable the tools you are not using for that conversation, which Claude supports per conversation.

The client caches the tool list. claude.ai captures the tool set at connect time, so a new tool or a changed schema does not reach an existing connection until the user hits refresh on the tools list. If a tool named here does not appear for you, that is the first thing to check.

Measurement is not instant and not free. Reads return in seconds. An audit fans out to real engines and takes minutes. Re-verification takes days by design. And audits, prompt proposal and verification consume credits, which is why the estimate call exists and why answer_usage_get is worth checking before a large run.

The full toolset is a Compete-plan surface. The connector and all 65 tools, including the 37 Answer Radar ones, require the Compete plan, with a 60 requests per minute per user limit. The legacy header-credential Reddit MCP server remains available on Pro with its own limits and without Answer Radar. If you authorize successfully and then see a not-entitled response on a tool call, that is a plan boundary rather than a bug.

And the browser does not vanish. Onboarding, billing, approving a high-consequence action and showing a result to a person who is not in your chat all still happen on the web surface. The claim is narrower than the headline: the weekly research loop belongs in the agent. The judgment path keeps its interface.

Frequently asked questions

Sources

• Anthropic: Get started with custom connectors using remote MCP (Claude Help Center)
• Claude Platform Docs: MCP connector
• sunpeak: What Are Claude Connectors? Data access, auth, custom setup and troubleshooting (July 2026)
• Claude Code for Marketers: How I use Claude Code to research competitors (January 2026)
• Panoramata: How to Use Claude for Competitor Research (July 2026)
• Practitioner discussion on agent-native workflows and dashboard fatigue (via r/mcp)
• Linkeddit connector tool reference: all 65 tools, parameters and scopes

Community quotations are attributed to the platform they were published on and never to an individual account. Connector facts, tool names, parameters and plan limits are quoted from the live tool registry as of September 2, 2026; the tool reference is generated from the running definitions, so it is the authority if anything here has since drifted. Claude client behaviour is quoted from Anthropic's own documentation as of its stated publication date and changes frequently.