My Research Engine Is Now an MCP Server, Thanks to Lovable Agent Integrations. Here Is the Jasper Run.
One line in Claude. Forty-six seconds. A scored teardown against eight competitors, with the buyer quotes underneath.
Last week I typed one line into Claude:
“Run a narrative synthesis on jasper.ai.”
That points a research tool I built and tells it to read what the market is saying, across Reddit, G2, Capterra, review sites, and forums, then turn the pile into a scored teardown: where the company wins, where it loses, what buyers say in their own words, and what to do about it. I spent the last few months building the tool. The new part, and the reason for this piece, is that I can now run the whole thing from inside Claude, on one line, without opening it and it’s…sick.
Forty-six seconds later I had the read on Jasper. The part that stopped me was not really a complaint or a compliment but a recommendation the tool made on its own: retire the line “Jasper generates content fast.”
Speed is what every AI writing tool sells. It is also the exact ground where free tools have caught up, so leading with speed walks the buyer straight into the comparison that hurts most. The tool did not tell me Jasper is fast. It told me Jasper should stop saying so, and it put the buyer quotes underneath to prove it.
Here is the rest of what came back, from 8 public sources and 10 verbatim buyer quotes, scored against eight competitors:
Jasper has the strongest community in its category. Its community score, 88, is the highest in the set. The people who like it are loud and loyal.
Price perception is the weakest thing about it. At 60, it is the lowest score on any dimension and near the bottom of the whole set. The reason is one sentence, repeated across reviews: similar features are free elsewhere.
The defensible ground is “professional-grade,” not “fast.” The reviewers who rate it highly describe a tool built for real marketing work, not a casual writing aid. That framing is what separates Jasper from the free tier. Speed does not.
I wrote none of that. The tool gathered the sources, scored them, and pulled the quotes, and Claude ran it for me on one line of instruction.
Three months ago the thing that produced that read was a slide in a deck. Two months ago it was a private web page I scrolled through. Last week it became something my assistant runs mid-thought. This piece is how that happened, what Lovable shipped on July 15 to turn it into a weekend build, and why the shift underneath it matters most if your buyers are starting to ask an assistant instead of searching for themselves.
If you read the $300k brand audit piece, this is the sequel. If you did not, you do not need to. That one covered building the research tool. This one covers what changes when you make it callable from the assistant you already work in.
What changed
For most of tech history the thing you shipped was a screen. A person opened it and did the work by hand, because a person was the only thing that could. That constraint is lifting. An assistant can do the same work through the same app, without the screen, once you expose the app’s actions as tools it can call.
My own work shows the arc in three steps.
The deck came first. Static, stale the day it shipped, opened twice and filed. Everyone reading this has built a hundred of them.
The URL was the upgrade I wrote about last time. A private research app built in a weekend, refreshable on demand, with the evidence on the screen for anyone who wanted to scroll it. Far better than the deck. It still waited in a tab for someone to visit.
The tool is the step I want to walk you through. The research app and its five screens still exist for the times someone wants to sit with the analysis. Underneath, that same app is exposed as a set of actions Claude can run. I stopped going to the research. It comes to wherever I am already working.
What Lovable shipped, and how good it is
Lovable spent 2026 wiring MCP through the whole product, in both directions. The coverage tends to blur it into a single announcement. There are three separate pieces, and you build better if you keep them straight.
First, Lovable as a tool your assistant drives. The Lovable MCP server arrived in Research Preview in May and went live as a native Claude integration in June. Connect it once in Claude’s connector settings and Claude can spin up projects, edit code, run SQL, and deploy from the chat you are already in. This is the piece that got written up everywhere. It is good but it is not the piece that changed my work.
Second, outside tools available inside a Lovable build. Since late 2025 the Lovable agent has been able to pull from Notion, Linear, Jira, and custom MCP servers while it builds. Handy, and beside the point today.
Third, the one that matters. On July 15 Lovable shipped Agent integrations. Your published Lovable app now runs inside Claude and ChatGPT. Rather than send someone to your app, you let them use it from the assistant they already have open. They pull information, complete tasks, and take action through the app, without opening it.
The mechanism is an MCP server, and the reason it counts as a launch rather than a config flag is how much Lovable handles. You switch it on for a public project. Lovable reads the app and proposes the set of actions the assistant can call. You edit that list and decide who gets access: anyone, signed-in users only, or paying users only. Lovable hosts the server, runs a security check when you publish, and keeps the server in step with the app. Publish an update and the tools move with it. Sign-in is required by default, so the server stays private unless you open it on purpose.
Look at the early-access examples in Lovable’s own post and the audience comes into focus. Operational apps, mostly. A creator platform lets people handle bids from inside ChatGPT. Sales teams stand up ROI cases, quote generation, and pipeline queries. The one that got my attention: marketers running drafts through their team’s go-to-market brain in Lovable to check how copy lands with buyer personas and holds to brand. That is the category I work in every day, sitting in Lovable’s launch announcement as a lead example.
I should be straight about the timeline, because it doubles as the advice. I built my version by hand before this shipped, standing up a Supabase edge function that speaks MCP on the same backend the app already ran on. It worked and it was worth doing early. Then Agent integrations landed and turned the job into a switch with a scope editor and hosting included. What I hand-built is now a toggle. Use the toggle.
The design decision that matters is that the server tracks the published app. The thing I kept in sync by hand, Lovable keeps in sync for you. App and tools read from one source, so an update to one is an update to both. That is the line between a demo and something I run every day, and it is the reason the manual version I built is now the version I would tell you not to build.
Real limits are at the end (because I do not trust a pitch that skips them)
What I built
The $300k brand audit piece ended on a private research app. A dark, editorial URL, five screens, and an engine underneath that pulled public buyer conversation and clustered it into a narrative. I built one for Clay as the worked example.
That became NarrativeOS, the same engine, hardened. It reads public buyer conversation across Reddit, G2, Capterra, TrustRadius, Hacker News, and comparison content, then produces a briefing, a competitive read, a customer-voice layer, and a strategic layer for any company domain I point it at.
Then I exposed the engine as an MCP server.
The setup is deliberately plain. React on the front, Supabase on the back, the default Lovable stack. The synthesis already ran inside Supabase edge functions, since that is where the calls to the scraping and synthesis models lived and where the keys stay off the client. I added one more edge function that speaks MCP and exposes the engine’s operations as typed tools, with OAuth in front so only I can run my own analyses. The function sits at a URL ending in /functions/v1/mcp. I added it to Claude as a custom connector, signed in once, and the tools showed up in the composer.
The server is one more function on the same backend, reading the same tables. Run a synthesis in the app and Claude can read it. Start one from Claude and the app shows it. One source of truth, reached two ways: a screen for sitting with the analysis, a set of tools for putting it to work.
Everything I just walked through, I did by hand, and as of July 15 you do not have to. Agent integrations does the same job as a native feature. You switch it on for the published project, Lovable proposes the tool scope, you set the actions and the audience, and Lovable hosts and syncs it. Building it the manual way taught me which tools were worth exposing, which is the one thing the toggle cannot do for you. If you are starting now, take the native path and spend the weekend on the engine.
The tools, in plain terms:
start_narrative_run takes a company domain and runs a full synthesis.
get_latest_narrative_briefing returns the headline findings from the most recent run.
get_narrative_run pulls any section of a run: briefing, competitive, customer voice, strategic.
list_narrative_sources returns the grounding quotes with attribution and links.
list_narrative_runs lists everything I have run.
A set of delivery tools that run the sponsor content pipeline, covered below.
Each one used to mean opening the app, clicking into a screen, and reading. Now each one is a sentence.
But why not just ask Claude?
Claude can already search the web and summarize it. So why wrap a research app around it and call that through MCP, instead of typing “what does the market think of Jasper” into the same chat?
Because those are two different things that start in the same box.
Ask Claude cold and you get a brilliant generalist improvising. It runs a quick search, reads a few pages, and writes a tidy summary. Ask again tomorrow and you get a different summary, in a different shape, from different sources, with no score you can compare and no record the first answer existed. Fine for a throwaway question. It breaks the moment the work has to be consistent, sourced, comparable, or repeatable.
NarrativeOS is the process I built once so it never has to improvise again. Under “run a synthesis on jasper.ai” sits a fixed pipeline: parallel scrapes across Reddit, G2, Capterra, TrustRadius, Hacker News, and comparison content, a synthesis step that has to return the same schema every time, competitive scores on the same five dimensions, the AEO question layer with rising percentages, and every quote carried with its source and link. The model underneath is the same one you would be typing into. The process around it is the whole point.
Three things it gives me that a cold chat does not.
It is the same every time. Jasper’s run and Apollo’s run are scored on the same axes, so putting them next to each other means something. Two off-the-cuff Claude answers cannot be compared. Two NarrativeOS runs can.
It remembers. Every run is stored with a timestamp. I re-run a competitor weekly and watch a sentiment cell move across a month, which is the displacement play from the last piece. A cold chat has no memory of last week. It has a fresh guess.
Other people can call it. Once the engine is an MCP with tiered access, a client runs NarrativeOS from their own Claude or ChatGPT and gets my method instead of their own improvisation. “Just ask Claude” gives one person one answer. The tool is a capability I can hand to a room, or sell.
The honest version: if it is a one-off and you do not care about structure or receipts, ask Claude directly and move on. The tool earns its place when the job repeats, has to hold up under challenge, or has to be usable by someone who is not you. That is most real research, which is why I built the process instead of retyping the prompt.
The use cases I run every day
This is the daily use rather than the plumbing, with the real runs behind each case.
1. A full teardown from one line
I am mid-conversation with Claude about a competitor, a prospect, or a category, and I want the market’s read rather than my memory of it. I do not change tabs. I ask for a synthesis on the domain and it runs. I use this in advisory work all of the time and it never fails to impress.
The Jasper run up top is real, done live while I wrote this. One instruction, start_narrative_run on jasper.ai, and forty-six seconds later Claude had the whole read: a briefing, a competitive score across eight rivals, a customer-voice layer, and the strategic layer that produced the “retire the speed message” call. Runs on webflow.com and apollo.io in past weeks came back with completely different shapes, which is the tell that the engine is reading the actual market for each subject and not pattern-matching a template.
2. The evidence, the moment someone pushes back
A finding is worth exactly as much as the quote under it. Research falls apart when someone asks “says who” and you do not have the receipt in hand. This closes that gap.
When a finding matters, I ask Claude for the sources. It runs list_narrative_sources and returns the verbatim quotes with attribution and links. On the Jasper run, the price problem is not a guess. It sits on a G2 review saying the cost feels high when similar features are free elsewhere. And the reason to retire the speed pitch sits right next to a review that praises Jasper for producing general “filler” text, which is the exact framing that drags a premium tool down into the free-tier fight.
Headline claim to the exact sentence a buyer wrote, in one follow-up, without leaving the chat. That is what lets the analysis survive a room full of skeptics.
3. The AEO question map, which is the part I care about most
This is the layer that makes the tool mine rather than a generic sentiment reader. The synthesis goes past how buyers feel to the questions they are asking about a company, the gap behind each answer, and whether the question is climbing. That is the raw material for answer engine optimization: owning the answer an assistant gives when someone asks about you.
Jasper surfaced four:
“is jasper ai worth the price compared to free tools,” up 52 percent, with buyers stating outright that similar features exist for free and Jasper offering no clear public answer in concrete time-saved terms.
“how good is jasper ai for long-form blog content,” up 38 percent, where positive reviews praise drafting speed and negative reviews flag shallow output, and no benchmark exists to settle it.
“does jasper ai understand context for complex marketing copy,” up 29 percent, with multiple reviews flagging context failures and no authoritative answer on where it holds up.
“can jasper ai maintain brand voice across a whole team,” up 21 percent, praised in passing but with no case study proving it at team scale.
It is a content roadmap and a positioning brief in the same breath. The top one is the whole game. It is the fastest-climbing question about the company, it goes to the exact objection that caps the price score, and there is nothing published to win it.
Here is where I stop reporting what the tool found and tell you what I would do with it, because that gap is the reason I am still in the chair and the engine is not.
The tool is right that the speed message has to go. It is half right on the fix. Professional-grade is not a position, it is a claim every tool in that set can make, and the scores say so: Writer, Anyword, and Copy.ai all sit within a few points of Jasper on workflow power. Leaning on “built for real marketing work” wins nothing an assistant will repeat back.
The move the data is pointing at is the one it cannot make for you. The fastest-climbing question about Jasper is whether it is worth paying for over the free option, and nobody has published the answer. So publish it. Not a landing page, a benchmark. One honest, reproducible comparison of Jasper against the free tools on the work a marketing team cares about most, with the time and the output sitting side by side. When buyers ask an assistant instead of reading ten reviews, the company that ships the comparison owns the citation the assistant reads back, and whoever writes it first sets the terms of every worth-it answer for the next year. Jasper has the community and the workflow scores to win that fight. It is losing it by leaving the question on the table.
That read took me two minutes on top of the forty-six seconds the tool spent handing me the question. That ratio is the point. The engine finds the unanswered question at the speed of a chat. The call on what to do with it is mine, and it stays mine. The tool did not replace the analyst. It deleted the week of grunt work between the question and the answer.
4. Run it without touching the app, then chain it
Once the engine is a tool, it works alongside everything else Claude can do. I do not just get the analysis. I get it inside the task I am already in.
A real sequence from last week: run a synthesis on a prospect, pull the top three findings, then in the same thread ask Claude to draft the opening of a positioning memo from the strategic layer and lay the competitive scores into a table for a deck. The research never sits in a separate tool I copy out of. It lands inside the document I am building. Synthesis, writing, and formatting happen in one place, and the tool call is one step in a longer move.
5. Run the delivery pipeline from the same place
NarrativeOS is more than the research engine. It also runs the content and delivery pipeline behind the sponsor and advisory work at StackedGTM, on the same backend, so I exposed those actions as tools too. I can ask Claude to list deliverables across the boards, move a status, or leave a timestamped note, without opening the dashboard. The system that runs the business turns into something I talk to instead of a stack of tabs.
Why this matters most for AEO
Every builder gets something out of this launch. Every app you ship now sits one switch away from being a set of actions any assistant can run, which used to be a quarter of engineering you greenlit only when it was strategic and now takes a weekend. When the price of a capability falls that far, it stops being a bet and becomes the default. That is real, and it is the version of this story most people will write.
The version that matters to anyone in my world is narrower and sharper.
Your buyer used to visit sites, read reviews, and compare before they talked to you. A growing share of them now ask an assistant and take the answer it gives. That single change does two things at once, and the Jasper run shows both.
First, the company that owns the answer to the rising question wins the buyer before the buyer reaches a single site. Jasper’s most-asked question is climbing 52 percent, and Jasper has nothing published to win it. So the assistant answers on Jasper’s behalf, using whatever the open web says, which right now is that the same features are free somewhere else. The question was going to get answered either way. The only choice a company gets is whether it wrote the answer or let the reviews write it.
Second, the same shift that pulls your buyer into the assistant is what lets your competitive intelligence live there too. The tool that tells you which question is rising now runs in the same place your buyer is asking it. You find the gap and you can move on it in one session, in one thread, without changing tools. Owning the answer and owning the engine that finds the unanswered question now happen in one place, in one thread.
That is the reason I built the tool into the assistant instead of leaving it as a site I visit. Not for the novelty of a callable app. Because the buyer moved into the assistant, and the work that wins the buyer had to move in with them.
The honest limits
I do not trust a build write-up without a limits section, so here is mine.
The feature is five days old. Agent integrations shipped July 15. It handles the sign-in flow and runs a security check on publish, which is what you want, and it is new enough that the setup will shift under you. Work from the current docs, not a write-up from another month, and expect the screens to move while the ideas hold.
Exposure is the thing to get right, because you are handing an app to an assistant and letting it act. Agent integrations gives you the controls for it: sign-in is on by default, the server stays private until you open it, and every publish runs a security check. Use those controls with intent. Decide who can call each tool, keep write actions locked down, and open only what you mean to. Everything I expose is scoped to my own account on purpose.
The synthesis is directional, not a statistically valid sample. Public data is skewed. Unhappy and loud users post more than quiet, satisfied ones. The tool shows the shape of the truth, and you say so when you present it. Running it from Claude does not fill the gaps in the underlying data. It gets you to a directional read faster, which is the whole value and the whole limit in one.
An assistant that can run your tools can run them wrong. The flip side of letting it choose when to call is that it will sometimes choose badly. Build so a wrong call is cheap and reversible. Read tools are safe to hand out. Write tools need caps, cooldowns, and confirmation, which is why my run tool has a daily cap and my delivery tools are scoped tight. Assume a bad call will happen, because in time it will.
Research sits upstream of the customer conversation, not in place of it. The tool shows the patterns. Talking to buyers tells you which patterns mean something. Do not let a one-line path to a synthesized read pull you out of real conversations.
Build one, seriously.
If you built a research app from the last piece, you are most of the way there. The engine already exists. Switch on Agent integrations for the published project, let Lovable propose the scope, set the actions and the audience, and connect it in Claude. The app you already have becomes a set of tools you run from the assistant you already use, with no edge function to write. That is the reason to do this now instead of the way I did.
If you have not built one yet, the order is: build the app, get the engine right, then switch on agent integrations. Do not lead with the MCP. Lead with something worth running. A tool is only as good as the thing underneath it, and a callable version of a weak engine is still weak. Sharpen the engine first. Then hand it to your assistant.
I ran a live teardown of Jasper while writing this, from one line, in under a minute, and it handed me a positioning call I would not have made on my own, with the buyer quotes to back it. Once the deliverable stops being a place you visit and becomes something your assistant runs, the buyer and the work end up in the same room, which is exactly where you want them.
Build the tool. Then tell me what your engine turned up that you did not already know. I read every reply.