Create an MCP Server in Less Than Two Minutes Without Writing Code

You already have the material. It is a documentation site, a repository, a handbook PDF, or all three. Your AI client does not have it, so every question that depends on it starts with you finding the right page and pasting it in.

Two minutes from now, your client can query that material directly. This guide covers creating a server with Context MCP Studio, connecting it to an MCP compatible client, and checking that it answers. The two minutes is the wizard. Indexing runs afterwards in the background, and a large site or repository takes longer.

What you have at the end

An MCP server is a standard interface. Model Context Protocol defines how an AI client discovers the tools a server offers, calls one, and reads the result. For a content server, your client can search your pages and get back the passages that answer the question.

The source stays authoritative, so check anything that affects production against the page itself.

Pick one source, and write three questions

Start with one source tied to one task. A focused server is easier to judge than a broad one, and one source is enough to tell you whether this is worth doing.

Write three questions before you touch the wizard. They are your test set, and writing them first keeps you honest about the result. For an upload API they might be:

1. Which authentication header is required?
2. What file size limits apply?
3. How does the sample application handle upload failures?

What you need

An MCP Studio account, one source URL or file, an MCP compatible client such as Cursor, Claude, or VS Code, and your three questions. Decide on visibility and access before you add a private source, and keep credentials out of prompts and shared files.

Build the server

Open the wizard and work through it in order.

1. Name it for its content. Payments API Docs or React Upload Examples tells you what a connection is for six months later, where My Server does not.
2. Paste the source. Documentation sites, websites, GitHub repositories, PDFs, and existing MCP endpoints all go in the same field. Add a second source only if it serves the same task from a different angle, such as reference documentation beside a repository showing a working implementation.
3. Choose the tools your client can call. Documentation search, question answering, passage retrieval, code example lookup, and API reference lookup each suit a different kind of question, so choose against your three. The tool selection guide covers what each one does.
4. Deploy. The endpoint exists straight away and indexing starts in the background. Give the source time to finish before you judge the answers.

Copy the endpoint from the setup page. If the server is private, treat its token like any other secret and store it wherever your client keeps credentials.

Connect your client

Add the endpoint to your client's MCP configuration. An entry looks like this:

{
  "mcpServers": {
    "docker-and-gitlab-mcp-kg6uxd": {
      "url": "https://appatools.com/mcp-studio/api/mcp/docker-and-gitlab-mcp-kg6uxd"
    }
  }
}

Locations and formats differ by client, so follow the current connection guide for Claude, Cursor, and VS Code. Reload the client if it asks you to, then confirm the server appears in its MCP connections with its tools listed. Indexing is separate, so check its status too.

Check that it works

Ask your three questions and read the replies against the source. Compare the specifics rather than the conclusion: method names, parameters, limits, and prerequisites are where a near miss shows up. Each passage links back to the page it came from, so open one and read around it.

Confirm the client called the server. Most clients show a tool call or MCP activity beside the reply, which is the difference between an answer drawn from your content and one drawn from general knowledge.

For a repeatable score across servers, the MCP Server Accuracy Rubric gives you a method instead of an impression.

The habit worth having: ask something you already know

The first question to put to a new server should be one you can answer yourself.

Pick a fact you are certain is in the source, ask for it, and compare what comes back. It takes ten seconds and teaches you more than an interesting question would, because you can tell a correct answer from a merely plausible one. If it is not there, that is information rather than a dead end: either indexing is still working through the source, or the fact lives somewhere you did not connect.

Then ask something the source genuinely does not cover. When nothing in your content is a real match, the server says so before it says anything else, instead of assembling a reply from whatever was nearest.

You: What is our incident escalation policy?

Assistant: Nothing in this server's content covers incident escalation. The closest material is the deployment checklist, which is a different subject. You would need to add that document as a source.

Two known answers and one deliberate miss, on every server you create.

If an answer is not what you expected

Change one thing, then ask the same question again. Rephrase it in the wording the source itself uses, since your wording and the page's are often different. Add the source that holds the answer when the question was never covered by what you connected. Move unrelated material onto its own server, which keeps each endpoint easy to reason about.

You can also add an existing MCP endpoint from a documentation platform as a source alongside your own content. That is retrieval only: your endpoint queries it for material and does not expose its action tools.

Two minutes gets you the server. The three questions tell you it is worth keeping. Create one with a single source and a test set you can run again next week.

Where to go next

• Create an MCP server
• Connect to Claude, Cursor, or VS Code
• Learn how to add useful sources
• Explore the MCP Studio dashboard