How to Query Your Competitor Data From Claude or Cursor
One Config Block, a Read-Only Key, and Questions That Answer From Real Records
Short answer
Add an MCP server entry with your API key and restart the client. Your competitor records then become tools the assistant can call, and Claude Desktop, Claude Code and Cursor all read the same style of config file with read-only access.
1. What can I ask once competitor data is connected?
Questions with a date and a name in them. Which competitor moved most this month, what a rival ran on Meta in May, which reviews mention a specific complaint, what the battlecard says about their pricing.
- MCP server
- A program that exposes a defined set of tools and data to an AI client over the Model Context Protocol, controlling exactly what the connected assistant can read or do.
- Also known as: Model Context Protocol server
These are the questions that stop being research tasks once the connection exists, phrased the way you would actually type them:
- Which competitor moved the most this month, and what specifically changed?
- Compare two competitors on engagement over the last 90 days and tell me who gained.
- What ads was this competitor running in May, and what offer did each one lead with?
- Pull the reviews from the last quarter that mention onboarding, and theme them.
- Draft talking points against this competitor using their latest ad copy and their battlecard.
- What are the three competitive threats worth reading this week?
The shared property is a date, a name, or both. Those are precisely the questions a model answers badly from training data, because a training snapshot has no notion of this month and no record of a company you happen to track.
2. How do I connect the server to Claude or Cursor?
Generate an API key in the web app, add an HTTP MCP server entry to your client configuration with that key as a bearer token, restart the client, then confirm the tool list appears before trusting an answer.
Setup is configuration rather than development, and it is the same shape for every MCP client. The slow part is deciding which questions the connection is meant to answer.
- Generate an API key in the web app. Create a personal key in your profile settings. Oppira keys are prefixed ca_ and are available on the Basic and Pro plans. The key is scoped to your own account, so the assistant sees exactly the workspace you see when signed in.Create a separate key per client. If one leaks you revoke that key rather than every connection you have made.
- Open your client MCP configuration file. Claude Desktop reads claude_desktop_config.json and Cursor reads an mcp.json file. Both take the same structure: an mcpServers object with one named entry per server. Claude Code accepts an equivalent entry through its own MCP configuration.
- Add the server as an HTTP entry with a bearer token. The entry needs three things: a transport type of http, the server address https://api.oppira.com/mcp, and an Authorization header carrying Bearer followed by your key. The copyable block on the MCP feature page has the exact JSON.
- Restart the client and check the tool list. MCP clients read their configuration at startup, so a fresh launch is required. Once it reconnects, open the tool or connector panel and confirm the server is listed with its tools. An empty list means the key or the address is wrong.
- Test with a question whose answer you already know. Ask for something you can verify by hand in under a minute, such as the post count last week for one competitor. Matching that once against the app tells you the connection works and the assistant is reading the right account.
- Write down the three questions it is for. A connector earns its place by answering repeated questions, not by existing. Note the three you set it up for, and check after a fortnight whether it actually answered them or whether you kept opening the dashboard anyway.
3. Which tools does the connected assistant get?
Eight groups of read-only tools: competitor discovery, competitor detail, posts, ads, reviews, insights and alerts, strategy documents, and cross-competitor comparison. Each returns structured records rather than prose.
| Tool group | What it returns | The question it settles |
|---|---|---|
| Discover | Competitor matches by name, plus the profile held for each one | Which of these companies am I actually tracking? |
| Competitor detail | The full record for one competitor and its activity timeline | What has this competitor done, and when? |
| Posts | Organic posts inside a date range, and the top posts across a period | What did they publish in May, and what worked? |
| Ads | Ad creatives for a competitor, and the ads live inside a date range | What were they advertising last month? |
| Reviews | Reviews for a competitor, and the notable ones across a period | What are their customers complaining about? |
| Intelligence | Generated insights, unread alerts and a summary of what needs attention | What changed that I have not read yet? |
| Strategy | The battlecard for a competitor and your marketing playbook | What is our approved position against this rival? |
| Compare | Two competitor timelines side by side, and how tone shifted over time | Who gained on whom, and did anyone change their message? |
The assistant chooses which tools to call from your question, which is why plain language works. Asking what changed this week typically triggers the intelligence group, and asking about a specific month triggers a date-ranged posts or ads query.
4. Why does the value depend on the data rather than the protocol?
The protocol only moves records to the model. If nothing collected a competitor channel on a schedule, no connection makes that history exist, and the assistant will answer confidently from the gap.
This is the honest limit of every MCP integration, and it is worth stating before the setup rather than after. A connector is a pipe. The answer quality is set by what is on the other end of it.
Three specific consequences follow. A competitor you added yesterday has no history, so trend questions about them cannot be answered. A channel nobody tracks is absent from every answer without being mentioned as absent. And a metric nobody collects, such as a rival ad spend, stays unavailable no matter how the question is phrased.
So judge a connection by the record behind it. Daily collection across the channels your buyers actually see is what makes a connected assistant useful, and the protocol is the least interesting part of the arrangement.
5. How do I tell whether the assistant read real data or guessed?
Ask which tool it called and open the record. A genuine tool call names a competitor record and a date range you can check in the app, and a guess produces a fluent answer with no retrievable source.
Three checks, each taking seconds:
- Ask it to name the tool it used and the arguments it passed. A real call has a competitor and usually a date range. A refusal to name either is the tell.
- Open one record it cited in the app and confirm the figure matches. Doing this once per new question type is enough to build trust in that question type.
- Ask the same question twice in separate conversations. Retrieved answers agree on the numbers. Recalled answers drift, because each one is generated rather than read.
Grounding removes fabrication and leaves ordinary misreading in place. A connected assistant can still compare two periods of unequal length, read a total as an average, or treat a partial week as a full one, so a specific going into a deck still deserves a glance at the source.
6. What can a connected assistant change in my workspace?
Nothing, when the server is read-only. Oppira exposes read access to competitor records, insights, battlecards and the playbook, so the assistant can look but cannot publish, edit or delete anything.
Read-only is the right default for competitive data, because the entire value is retrieval and none of it requires writing. It also removes a whole category of risk: a misread instruction cannot become a change in a real system if no tool can write.
Treat the key like a password regardless. It carries your account access, so keep it out of shared documents and repositories, and regenerate it if it is ever exposed. Keys can be revoked and reissued from the web app at any time.
Key Takeaways
Setup is one configuration entry plus a key
An HTTP MCP server entry with a URL and a bearer token, added to your client config and followed by a restart. No development work is involved.
The tool list is the proof of connection
After restarting, the client lists the server and its tools. An empty list means the address or the key is wrong, not that the protocol failed.
Date-and-name questions are the payoff
What a competitor ran in May, who gained over 90 days, which reviews mention onboarding. These are the questions a training snapshot cannot answer.
The protocol is a pipe, not a data source
A channel nobody collected is absent from every answer without being flagged as absent, so judge a connection by the record behind it.
Ask which tool it called
A real retrieval names a competitor record and a date range you can open. A guess produces fluent prose with nothing to check.
Read-only removes the risky category
When no exposed tool can write, a misread instruction cannot change anything. Keep the key out of shared documents and revoke it if exposed.
Frequently Asked Questions
Sources
- Model Context Protocol Model Context Protocol project, July 2026.The specification and client documentation for the protocol, including how a server describes the tools it exposes to a connected client.
- Model Context Protocol in Claude Anthropic, July 2026.Anthropic's own documentation for connecting MCP servers to Claude clients, which is the authority on current configuration paths.
Explore More
Related analyses, benchmarks, and industry insights
Related Guides
Glossary Terms
Turn reading into a reaction
Oppira watches your competitors, keeps your playbook current, and drafts the response. Start free and see your market clearly by tomorrow.