Neha Prasad

Posted on Aug 2

I gave my Cursor agent real tools without five API keys

#agents #ai #llm #mcp

I Tried Building an AI Agent That Does Real Work. The Biggest Bottleneck Wasn't the Model.

Last week, I wanted to build an AI agent that could do more than chat.

My goal was simple:

Drive a live browser through our product
Find a small ICP lead list
Enrich work email addresses
Draft personalized outreach in our brand tone

Surprisingly, the LLM wasn't the bottleneck.

The real challenge was the setup.

The Setup Problem

Every capability required another tool:

Another vendor account
Another API key
Another subscription
Another credit card

For a one-off experiment, I spent more time connecting tools than actually building the workflow.

So I tried using Vaaya as a single MCP server inside Cursor.

Installation

Install Vaaya MCP:

npx @vaaya/mcp install

It automatically added this to my Cursor MCP configuration:

{
  "mcpServers": {
    "vaaya": {
      "command": "npx",
      "args": ["-y", "@vaaya/mcp"]
    }
  }
}

Then I simply:

Restarted Cursor
Opened Settings → MCP and verified that vaaya was running
Switched to Agent Chat (Tools Mode)
Approved the one-time connect/signup prompt on first use

That was the entire onboarding experience.

The Prompt I Used

Using Vaaya tools:

1. Open our product in a live browser and record a short walkthrough.
2. Find 15 Series A SaaS Product Managers matching our ICP.
3. Enrich their work email addresses.
4. Draft short outreach in our brand tone.

Show every step while you work.

Do not send anything.
Drafts only.

I intentionally kept everything in draft mode so I could review the output before anything was sent.

What Worked Well

✅ One MCP instead of managing multiple vendor accounts for a demo

✅ Tool calls were visible inside the agent UI, making it easier to understand and debug what the agent was doing

✅ Pay-per-successful-call felt much better for experimentation than paying for multiple monthly subscriptions

What I Wouldn't Skip

Always review outputs before sending
Start with a single workflow instead of trying to automate your entire GTM process
Keep your first experiment small (15 leads instead of 500)

Who This Is For

If you're a:

Founder
DevRel engineer
AI engineer
Developer building agent workflows or demos

…and you're spending more time wiring APIs than testing ideas, this approach is worth trying.

It's not magic.

It just removes a lot of the setup friction between:

"I have an idea."

and

"My agent actually called the tools."

You can check it out here:

https://vaaya.ai/
https://www.linkedin.com/company/vaayaio/posts/
https://x.com/getvaaya

and follow this pages!

If you've built similar agent workflows, I'd love to know what your stack looks like.

What part of the setup still feels the most painful?

Top comments (2)

Zira • Aug 2

The one-server setup removes a lot of integration friction, but I would make capability boundaries visible before trusting a workflow like this. A useful preflight is to list each tool, whether it can read, write, send, or browse, and require a separate approval for the first side-effecting call. Keeping the demo in draft mode is the right default, especially for enrichment and outreach.

Neha Prasad • Aug 2

Totally fair - and I agree.

One MCP cuts setup friction, but it doesn’t remove the need for clear capability boundaries. Before I’d trust this in a real pipeline, I’d want a preflight too:

list tools in scope for that run
mark each as read / write / browse / send
keep send + anything side-effecting behind an explicit first approval
That’s why I forced drafts-only in the demo. Enrichment and outreach are exactly where “helpful agent” becomes “oops, that went out.”

Curious how you’d want that surfaced in the agent UI - tool manifest at session start, or approval on first write/send only?

DEV Community