Using MCP Servers in Vibe

From Configuration to Real-World Use

Lesson 8 showed you how to declare MCP servers in config.toml. The file is written, the servers are responding—but the question that matters day-to-day remains: how does this actually change your workflow? That’s what this lesson covers.

Giving Access to the Web

The most valuable server to install first is mcp-server-fetch, because it removes the most annoying limitation of a local agent: ignorance of anything not on your disk. Once configured, Vibe can read any web page.

Read the Stripe API documentation on webhooks and summarize the implementation steps for me

Fetch the content of this GitHub issue: https://github.com/org/repo/issues/42

Check the latest available version of the fastapi library on pypi.org

Notice that at no point did you specify which tool to use. The agent calls the fetch tool on its own as soon as it detects that a URL or web reference is needed; the context of your request drives the decision, not an explicit instruction from you.

Querying Your Data

The same principle applies to a database via an MCP SQLite or PostgreSQL server. The declaration remains short:

# Configuration in config.toml
[[mcp_servers]]
name = "db_locale"
transport = "stdio"
command = "uvx"
args = ["mcp-server-sqlite", "--db-path", "./data/app.db"]

In a session, you then ask business questions, not SQL: “Show me the 10 most recently registered users with their creation dates,” or “How many orders were placed this month? Group them by status.” The agent writes the query, executes it, and returns a readable result. SQL becomes an implementation detail.

Composing Multiple Servers

The real power of MCP emerges when two servers work within the same exchange. With fetch and SQLite active simultaneously, a request like this engages both:

Compare our database data with the official API documentation. 
Are there any missing fields in our schema?

Vibe reads the documentation via the fetch server, inspects your schema via the SQLite server, and then cross-references the two. Two common workflows rely on this composition. First, technology watch:

1. Fetch the latest React releases on GitHub
2. Compare with the version in our package.json
3. If a major update is available, summarize the breaking changes

The agent chains the call to the fetch server for GitHub, reads the local package.json, and performs the analysis, without you having to break down the request. Dependency auditing follows the same logic, with an extra iteration:

For each dependency in @package.json, check npm for known 
vulnerabilities and generate a report

Vibe iterates through the dependencies one by one, calls the fetch server for each, and compiles the results into a single report.

Knowing What’s Available and Diagnosing Failures

During a session, you don’t have to guess which MCP tools are active. Whenever Vibe uses one, it clearly indicates the server and tool invoked in its output, which you can view with Ctrl+O. You can also ask directly: “What tools does the ‘fetch’ MCP server provide?”

When a server stops responding or returns an error, Vibe informs you explicitly. Four causes cover most cases.

For STDIO transports, the startup question doesn’t arise: Vibe manages the server lifecycle itself, and if the process crashes, it attempts to restart it.

Keeping Sessions Fast

Every active MCP server adds its tools to the agent’s context, and you won’t notice the impact until you have eight of them. The effects are mechanical: response time increases because the model must arbitrate between more options, and the cost per request rises because all these tool definitions consume tokens in the billable context. The rule is simple: activate only the servers useful for the current session.

When you’re interested in only part of what a server exposes, filtering is better than complete deactivation:

# Use only the fetch tool from the server, not the others
enabled_tools = ["fetch_fetch"]

Finally, prefer STDIO for anything running locally. Vibe starts and stops these servers automatically: you don’t have to maintain any services in the background or restart them after a reboot.

Key Takeaways

• MCP servers extend Vibe with web, database, and other capabilities
• The agent automatically chooses which MCP tool to use based on context
• Multiple MCP servers can be combined in a single workflow
• Limit the number of active servers to maintain performance
• Tool filtering allows fine-grained control over available capabilities