How is an MCP Server different from an API?

An API is an interface for software. An MCP Server presents tools, resources, and prompt templates through a standard protocol for AI clients. It will often call your existing REST, GraphQL, or database APIs behind the scenes.

Should I install an MCP SDK in the browser part of my Next.js app?

No. Keep MCP connections, tokens, and tool calls on the server or in a separate service. The browser should call only your own protected API.

Where can I find a list of MCP Servers?

Start with the official MCP Registry. It is a public discovery directory, not a security guarantee: check each publisher, source repository, permissions, auth model, and maintenance status.

Can I give an MCP Server direct production database access?

Do not give it administrator credentials. Start with a read-only role, restricted views, row limits, and audit logs. Route every write through narrow, validated business tools.

MCP Servers for Developers: What to Use and How to Connect Them to Your App

One-Sentence Answer

MCP (Model Context Protocol) is an open standard that lets AI clients discover and call external data, tools, and workflows in a consistent way. The practical developer path is to connect a few least-privilege servers first, then wrap the small set of business capabilities that an AI genuinely needs in your own MCP Server.

What Is an MCP Server?

Think of MCP as USB-C for AI.

Instead of every AI product building a different integration for GitHub, files, databases, and internal services, an MCP Server exposes capabilities in a common format. It can offer three main primitives:

Tools: actions the AI can request, such as searching issues or retrieving an order summary.
Resources: context the AI can read, such as files, database schemas, or product documentation.
Prompts: reusable, user-selected workflow templates.

This should not mean handing control to a model. A good client makes the tool and its inputs visible, and a good server keeps every tool narrow. A get_order_summary tool is far safer than a general-purpose run_sql tool.

Read the official MCP introduction and the guide to tools, resources, and prompts.

Where Can I Browse MCP Servers?

Start with the official MCP Registry, rather than a stale “top 100 MCP servers” list. It is the official metadata directory for publicly available servers, with search and installation/configuration details. It is still in preview, so use it for discovery—not as an automatic endorsement.

Before connecting a server, check five things:

Who published it? Prefer an official company or open-source project repository over a same-name wrapper.
What can it read and write? Inspect tool descriptions, input schemas, and OAuth scopes.
Where do credentials live? Local stdio servers commonly receive credentials through environment variables; remote HTTP servers need an appropriate authorization flow.
Is it maintained? Look for source, releases, ownership, and a maintenance history.
Can you start read-only? Search, preview, and draft before enabling creation, sending, or deletion.

The official Example Servers are also valuable for learning the protocol: filesystem, git, memory, fetch, time, and sequential-thinking examples are available there.

Which MCP Servers Should a Developer Start With?

Do not optimize for the largest collection. Optimize for one clear friction point per server. Search the Registry for an official or well-maintained implementation in each of these categories:

| Job | Useful capability | Safe starting point | | ---------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Repository work | Git, GitHub, issues, pull requests | Search and diffs only; do not begin with merge or push access | | Local projects | Filesystem | Limit access to the current repository or a named working directory—not your whole home directory | | Current technical docs | Documentation / API-reference search | Read-only access to official docs | | Frontend verification | Browser automation / Playwright | Limit it to local or preview URLs and test accounts | | Data access | PostgreSQL, Supabase, or another data service | Use a dedicated read-only role, views, row limits, and auditing | | Observability | Sentry, logs, analytics | Investigate and summarize before allowing alert changes or data deletion | | Deployment | Vercel, GitHub Actions | Read deployment status first; keep production releases behind human confirmation | | Team work | Linear, Slack, Notion | Search and draft before sending messages or changing tickets |

Local Server, Remote Server, or an MCP Server for Your App?

These are separate goals:

| Goal | Recommended approach | | -------------------------------------------------------- | --------------------------------------------------------------------------- | | Let Codex, Claude Code, or a desktop AI help you develop | Configure a local MCP server, usually launched over stdio | | Let a team connect to a shared integration | Deploy a remote MCP server using Streamable HTTP and real authentication | | Let an AI understand or operate your product | Build an MCP Server around selected business APIs with strict authorization |

Local stdio is convenient for development: the client starts a child process and communicates over stdin/stdout. A key rule: a stdio server must never log to stdout, because that corrupts JSON-RPC; log to stderr instead. For a multi-user remote server, the official TypeScript SDK recommends Streamable HTTP; the older HTTP+SSE approach is retained for backwards compatibility. See the TypeScript SDK server guide.

Design MCP Tools Around Business Boundaries

Do not expose your whole database, internal API surface, or environment variables through a “universal” tool. Start from an AI task, then make the tool small enough to authorize and test.

For a content site, a sound first release might contain:

search_published_articles(query, limit) — searches only published content with a hard limit.
get_article_outline(slug) — returns title, summary, table of contents, and public URL.
draft_related_links(slug) — produces suggestions but does not edit an article.
get_contact_message_summary(date_range) — gives an authorized admin an aggregate, not unnecessary personal data.

Avoid these first-release tools:

execute_sql(sql)
read_any_file(path)
call_internal_api(url, body)

The first group makes authorization, testing, and auditing possible. The second is an administrator key handed to a model.

A Minimal Architecture

AI client (Codex / Claude / your agent)
              |
       MCP transport
              |
       MCP Server (server-side)
              |
   authenticated business service / API
              |
     database, CMS, GitHub, Vercel

Never place MCP service credentials in a browser. If a web user should trigger an AI action, the browser calls your protected Next.js Route Handler; that handler or a background worker applies the current user’s authorization before it calls a business service or MCP client.

Build an MCP Server for Your Next.js App

Install the official Node/TypeScript SDK in a server-side package:

npm install @modelcontextprotocol/sdk zod

Start with a separate server package or directory—not a React component. Here is the shape of a narrow, read-only tool:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "my-app", version: "0.1.0" });

server.registerTool(
  "search_published_articles",
  {
    title: "Search published articles",
    description: "Search public, published articles only.",
    inputSchema: {
      query: z.string().min(2).max(120),
      limit: z.number().int().min(1).max(10).default(5),
    },
  },
  async ({ query, limit }) => {
    const articles = await searchPublishedArticles({ query, limit });
    return { content: [{ type: "text", text: JSON.stringify(articles) }] };
  },
);

searchPublishedArticles should be your server-side function. It should query only published data, use parameterized queries, limit rows and returned fields, and record the caller and action. Do not concatenate SQL or trust a model-supplied URL, path, or user ID.

Use a stdio transport for local development. For a remote deployment, use Streamable HTTP and establish identity, authorization, and rate limits on every request. The SDK’s client APIs for listing and calling tools are documented in the TypeScript SDK client guide.

A Practical Integration Plan

Inventory allowed business actions. Define caller, read/write scope, input limit, failure behavior, and audit fields for every candidate tool.
Create a server-only service layer. Keep Supabase, CMS, and third-party access behind server-side functions; do not call browser code from an MCP handler.
Ship one read-only tool. Test it against a small, known dataset and verify its schema and permission failures.
Add identity and authorization. A remote endpoint must not be usable merely because someone knows its URL. Validate an access token and carry the user/tenant into every query.
Add limits and logs. Set timeouts, pagination or limit caps, rate limits, and audit logs that avoid storing sensitive content.
Deploy last. Validate the flow against test data in a preview environment. Confirm that your chosen Vercel runtime supports your Streamable HTTP connection and authentication model before using a production domain.

The Right First MCP Tools for This Website

This site already keeps articles, tools, and wiki content in Markdown with clear loaders. Before opening up Supabase administration, the most useful MCP tools would be:

Search published articles, tools, and wiki entries.
Read public metadata and the table of contents for one entry.
Suggest internal links from the current tags.
Validate new Markdown frontmatter against the project schema.
Create a draft or Git branch only after explicit human confirmation.

That gives an AI real editorial and development help without access to SMTP passwords, Supabase admin keys, or the entire filesystem.

Security Checklist

Install only servers whose publisher and source you can trace.
Keep keys out of Git, MCP config files, articles, and browser bundles; use environment variables and secret management.
Separate read-only and write credentials for databases and SaaS products. Keep production writes behind approval.
Restrict filesystem servers to one project directory.
Treat text from untrusted web pages, issues, and documents as data—not instructions. It can contain prompt-injection attempts.
Require explicit confirmation and audit trails for deletion, messages, deployments, payments, and permission changes.
Remove unused servers and tokens regularly.

Read the official MCP Security Best Practices before operating a remote server.

Conclusion

MCP is valuable not because it gives an AI every permission, but because it lets the AI do real work inside clear boundaries. Start with a small, read-only developer stack. Then expose the most stable and auditable parts of your app through narrow tools. That produces a capable collaborator instead of an uncontrolled admin key.