An MCP server URL is the web address your AI client calls to reach a remote Model Context Protocol server. This article shows how the address is built, real examples from Notion, GitHub and Sentry, and the places where you can find the exact one you need.
You paste a link into an AI client, press connect, and nothing happens. Or a setup screen asks for an "MCP server URL" and you have no idea where that address comes from. Here is the short answer: an MCP server URL is the web address of a remote Model Context Protocol server. It is the exact endpoint your AI client calls to list tools, read data and run actions on your behalf.
This article breaks down what the address means, how it is built, which real examples you can compare against, and the places where you can find the one you need. You will also see the mistakes behind most failed connections, plus a quick way to sanity check a config before you blame the server.
The Model Context Protocol (MCP) is an open standard that lets an AI application talk to outside tools through one predictable language. Three roles are involved: the host (the AI app you use), the client running inside that app, and the server that exposes tools, resources and prompts. Messages between client and server travel as JSON-RPC.
When the server lives on the internet instead of on your own machine, the client needs to know where to send those messages. That location is the MCP server URL. Think of it as the phone number of one specific tool provider: dial it, and the server answers with a list of what it can do.
The official specification calls this address the MCP endpoint. It is one single HTTP path, and the spec requires it to support both POST and GET. Every message from your client is a fresh POST to that path. Optionally, the client opens a GET on the same path to listen for messages the server wants to push. One address, no sprawling list of routes to memorize.
💡 Tip: If a setup page says "server URL," "endpoint URL," "connector URL" or "remote MCP URL," it almost always means this same single address.
The URL does not describe the tools. It does not hold your login. It is only the door. What the server offers appears after the client connects and asks. That is why two servers with similar looking addresses can behave in very different ways, and why a working URL alone never proves the setup is right.
An MCP server URL is a standard web URL. The syntax holds no surprises. The specification itself uses this sample:
https://example.com/mcp
Split that sample into parts and every piece has a job.
| Piece | Example | What it does |
|---|---|---|
| Scheme | https:// | Tells the client to use encrypted HTTP. Remote servers should always use it. |
| Host | mcp.example.com | The domain name of the server. Often starts with mcp. or api.. |
| Port (optional) | :8443 | Only shown when the server skips the default HTTPS port. |
| Path | /mcp | The single endpoint that handles MCP traffic. |
| Query (optional) | ?workspace=123 | Rare, but a few providers append settings such as a workspace. |
Local development servers often use plain http://localhost:3000/mcp. That is fine on your own machine. Never expose an unencrypted address to the open internet.
The spec only says the endpoint "could be a URL like" the sample above. The path is a convention, not a rule. Still, two suffixes dominate in practice:
/mcp usually points to a Streamable HTTP server, the current standard transport./sse usually points to the older HTTP+SSE transport from protocol version 2024-11-05.Treat the suffix as a hint, not a guarantee. A provider can publish its endpoint at /v1/mcp or at the root of a subdomain. Copy the URL exactly as printed, including any trailing slash. GitHub's remote server, for example, ends with /mcp/.
Streamable HTTP replaced the old HTTP+SSE transport. Under the newer design, the client always sends a POST with an Accept header that lists both application/json and text/event-stream. The server replies with either a single JSON object or a stream of events. A server may also return an Mcp-Session-Id header, which the client repeats on every later request, and clients send an MCP-Protocol-Version header so both sides agree on the spec revision.
Claude Code's documentation now describes SSE as deprecated and recommends HTTP servers wherever they exist. Many providers keep an /sse address alive for older clients, which is why you still meet both styles.
💡 Tip: A client that wants to be friendly to older servers accepts one URL from the user and tries a POST first. If the server answers with a 4xx error, it falls back to a GET and expects an SSE stream. That fallback is why the same pasted URL sometimes works in one app and fails in another.
Not every MCP server has a URL. This surprises many people, and it explains why some setups ask for a command instead of an address.
With the stdio transport, the client launches the server as a subprocess on your computer. Messages move through standard input and standard output. There is no network hop and no address. You provide a command and its arguments, for example npx plus a package name, and that is all the client needs. The spec tells clients to support stdio whenever possible, so it remains the default for local tools.
With Streamable HTTP, the server runs as an independent process and can handle many clients at once. That is the setup where a URL becomes essential, because the client has to find the server over the network.
| Transport | Has a URL? | Typical setup | Status |
|---|---|---|---|
| stdio | No | command and args in a config file | Standard, clients should support it |
| Streamable HTTP | Yes, one endpoint | Paste https://…/mcp | Standard remote transport |
| HTTP+SSE | Yes, often /sse | Paste https://…/sse | Deprecated, kept for older clients |
Use the second column as a decision rule. If your provider hands you a command line, you are on stdio. If it hands you a link, you are on a remote transport.
When a server runs on your own machine over HTTP, the spec says it should bind to 127.0.0.1 instead of 0.0.0.0, and it must validate the Origin header to block DNS rebinding attacks. In plain words: a local MCP server on localhost should never be reachable from other devices on your network unless you deliberately want that.
The addresses below come from official documentation pages and public lists. Vendors change endpoints, so treat this table as a pattern reference and confirm each URL in the provider's current docs before you rely on it.
| Provider | Example URL | Style |
|---|---|---|
| Specification sample | https://example.com/mcp | Streamable HTTP |
| Notion | https://mcp.notion.com/mcp | Streamable HTTP |
| GitHub | https://api.githubcopilot.com/mcp/ | Streamable HTTP |
| Sentry | https://mcp.sentry.dev/mcp | Streamable HTTP |
| Supabase | https://mcp.supabase.com/mcp | Streamable HTTP |
| PostHog | https://mcp.posthog.com/mcp | Streamable HTTP |
| Asana | https://mcp.asana.com/sse | Legacy SSE |
| Local test server | http://localhost:3000/mcp | Streamable HTTP on your own machine |
mcp. subdomain: mcp.notion.com, mcp.sentry.dev, mcp.supabase.com.api.githubcopilot.com.Authorization header.The Claude Code docs show these exact forms for Notion and Asana:
claude mcp add --transport http notion https://mcp.notion.com/mcp
claude mcp add --transport sse asana https://mcp.asana.com/sse
The only difference is the --transport value and the path. Everything else, including the name you choose, stays your decision.
Because the URL belongs to the server owner, the most reliable source is always the owner. This order saves the most time.
Search the provider's documentation for "MCP," "remote MCP" or "connectors." Developer portals usually have a dedicated page, often with a copy button next to the address. That page states the /mcp or /sse suffix outright, so you do not have to guess.
Some products show the address in your account. A settings page for integrations, connections or developer tools may list it together with setup steps for each client. If the page requires a login, that is normal: many providers tie the connection to your account.
Open source servers describe themselves in a README file. Look for a section titled "Usage," "Installation" or "Configuration." If the README shows only a command and args, the server is stdio only and has no public URL until someone deploys it.
Public directories such as MCPservers.org maintain lists of remote MCP servers and their endpoints. Use them to find candidates, then confirm the address against the provider's own docs. Directory entries can go stale.
If a teammate already connected the server, ask them to run claude mcp list or claude mcp get <name> in Claude Code. Both commands show how a server is configured, which is where you can spot the address. Inside a running session, the /mcp command shows the status of each server.
Once you hold the right address, the setup takes under a minute. Three routes fit nearly every client.
Claude Code takes a transport, a name and the URL:
claude mcp add --transport http <name> <url>
To send a token with each request, add a header:
claude mcp add --transport http secure-api https://api.example.com/mcp \
--header "Authorization: Bearer your-token"
Most clients also read a JSON file. Field names differ between apps, so check your client's docs, but the shape is close to this:
{
"mcpServers": {
"notion": {
"type": "http",
"url": "https://mcp.notion.com/mcp"
},
"local-files": {
"command": "npx",
"args": ["-y", "example-mcp-package"]
}
}
}
The first entry is remote and uses url. The second is stdio and uses command. Stick to one style per entry.
Chat apps with a custom connector screen usually ask for two things: a name and the URL. Paste the address, save, and finish the sign in prompt if one appears. Nothing else is needed, because the app finds the tools by itself once the connection opens.
Most failed connections trace back to a short list of causes. Check them in this order before you touch anything else.
A host name alone, such as https://mcp.example.com, often is not enough. The client needs the exact endpoint path. If you get a 404, copy the address again from the provider's current docs and compare it character by character, including the trailing slash.
A regular REST API base URL is not an MCP URL. A base like https://api.example.com/v1 serves ordinary requests and does not speak JSON-RPC over the MCP transport. If a provider offers both, the docs list them on separate pages. Never paste an API base into a field labeled MCP server URL and expect tools to appear.
A correct URL still fails without permission to use it. Servers answer with 401 when your token is missing or expired, and with 403 when your account cannot reach that workspace. Sign in again through the client, or refresh the Bearer token you pass in the Authorization header.
💡 Tip: Keep tokens out of the URL. If a provider asks you to paste a secret into a query string, treat that link like a password and never share it in screenshots or tickets.
| Symptom | Likely cause | Fix |
|---|---|---|
| 404 Not Found | Wrong path, or the provider moved the endpoint | Copy the URL again from the current docs |
| 405 Method Not Allowed | POST sent to an SSE only address, or GET sent to a POST only one | Try the /mcp address or switch the transport to sse |
| 401 Unauthorized | Missing or expired token, OAuth not finished | Sign in again or refresh the Bearer token |
| 403 Forbidden | Account lacks access to that server or workspace | Check plan, workspace and permissions |
| Connection refused | Local server not running, or wrong port | Start the server and check the port |
| Certificate error | Self signed or mismatched HTTPS certificate | Use a valid certificate |
| Works in one app only | Different transport support | Match the transport (http or sse) to the client |
One nuance saves a lot of confusion: the spec lets a server answer a GET with 405 to say it does not offer an SSE stream at that endpoint. A 405 on a GET alone is therefore not always a fault.
PicassoIA publishes a developer API at https://api.picassoia.com/v1. It uses Replicate style endpoints such as POST /v1/models/{owner}/{name}/predictions and GET /v1/predictions/{id}, and it authenticates with a Bearer token that starts with pia_sk_. That address belongs to the REST API. It is not an MCP server URL, so do not paste it into an MCP field.
MCP connections are managed from your account at picassoia.com/en/mcp/accounts, which needs a login. The MCP server URL is not printed on the public pages, so start there instead of guessing one. Plan rules apply, so check the pricing page for what your plan includes.
Four models are available through both the API and MCP:
Jobs run asynchronously: you create a prediction, poll it, then fetch the result. The limit is 5 concurrent predictions per account, shared across tokens and MCP connections, with prompts up to 4,000 characters.
The model Claude Sonnet 5 handles coding and tool use tasks, which makes it a handy second pair of eyes for a config file. Here is a short routine on PicassoIA:
💡 Tip: Treat the answer as a lead, not a verdict. The provider's docs always win when the two disagree.
GPT 5.6 Sol works the same way if you prefer a second opinion.
A connected server is only useful when you have something to build with it. Open Picasso IA, choose PicassoIA Image or Seedance 2.5 Lite, write a prompt describing the scene you imagine, and generate your first result in a few minutes. Try a photo for your next article, a product shot or a short clip, then refine the wording and run it again. The platform rewards experimenting, so start your first prompt today and see what your own words can produce.
