MCP questions, answered

An MCP server is a small program that exposes tools, resources, and prompts to an AI client over the Model Context Protocol. It speaks JSON-RPC 2.0 over stdio, Server-Sent Events, or Streamable HTTP – and once connected, the AI can call any tool the server defines.

MCP-compatible clients include Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf, VS Code, Zed, and JetBrains IDEs. One MCP server works across all of them – you install it once, every client can use it.

Glama indexes every MCP server in the ecosystem – browse by category, search across every tool they expose, or deploy a hosted connector in one click.

Open Cursor Settings → Features → MCP → + Add New MCP Server, or edit ~/.cursor/mcp.json directly. Each server takes a command, an args array, and an optional env map – for example, command: "npx" with args: ["-y", "@example/mcp-server"].

Pick any server from the Glama registry – each server page shows the exact JSON block to paste, pre-filled for Cursor, Claude Desktop, Claude Code, and VS Code. To test a remote server before adding it, use the Glama MCP Inspector – no install required.

In Claude Desktop, open Settings → Developer → Edit Config – that opens claude_desktop_config.json. Add your server under the mcpServers key using the same command/args/env structure Cursor uses, then quit and relaunch Claude Desktop.

In Claude Code, run claude mcp add <name> <command> from your terminal – it writes the entry to your project's MCP config directly.

Every server on the Glama registry ships with a pre-filled config block for both clients – copy it, paste it, done. To test a server remotely before wiring it up, open the Glama MCP Inspector and point it at the server URL.

Three causes account for almost every "MCP server won't connect" report:

• Missing -y flag – npx refuses to auto-install without it. Change "args": ["@example/mcp-server"] to "args": ["-y", "@example/mcp-server"].
• Windows path escaping – inside claude_desktop_config.json, use forward slashes (C:/Users/...) or doubled backslashes. Single backslashes break JSON parsing.
• spawn ENOENT – the client can't find the binary. Give command an absolute path, or make sure the binary is on PATH for the shell the client launches from – Claude Desktop launches without your login shell's PATH.

If the handshake completes but individual tool calls fail, open the Glama MCP Inspector and point it at the server URL – it shows raw JSON-RPC requests and responses so you can see exactly where the error originates.

MCP is an open-source standard introduced by Anthropic in November 2024 that standardizes how AI applications connect to external tools and data sources. Think of it as USB-C for AI – one protocol replaces custom integrations between every AI app and every tool.

Before MCP, every AI application needed custom code to talk to every tool – an N×M integration problem. MCP reduces it to N+M: each app implements MCP once, each tool implements MCP once.

An MCP setup has three roles:

• The host – the AI application (Claude Desktop, ChatGPT, Cursor, VS Code)
• A client – the host's internal connection to one specific server
• An MCP server – exposes three primitives to the client:
  • tools – functions the model can call (like "send email" or "query Postgres")
  • resources – data the model can read (like a config file or database schema)
  • prompts – templated messages the user can pick from

Servers speak to clients over stdio, Server-Sent Events, or the modern Streamable HTTP transport using JSON-RPC 2.0.

Glama sits at the infrastructure layer. We index every MCP server and hosted connector in the ecosystem, search every tool they expose, and proxy every call through a gateway that logs inputs and outputs, enforces per-tool access control, and manages OAuth credentials – so your agents get the MCP ecosystem plus production-grade observability.

An MCP Gateway is a reverse proxy that sits between AI clients and MCP servers. It appears as an MCP server to the client while acting as an MCP client to the backend.

Without a gateway, every agent manages its own connections to every server – a tangled point-to-point mess that breaks at enterprise scale. A gateway consolidates all of that into one control plane that:

• Authenticates – one identity in front of every connected server
• Injects credentials – OAuth tokens and API keys stored once, refreshed automatically
• Controls tool access – enable or disable individual tools per connection
• Manages sessions – Mcp-Session-Id tracking across reconnects
• Logs every call – full JSON-RPC audit trail

Glama's MCP Gateway turns the open MCP ecosystem into a production-grade control plane – every connector in the registry is fronted by the gateway, so every call your agents make is visible, auditable, and revocable. Read the full Gateway overview →

An MCP Proxy is a thin pass-through – it takes a JSON-RPC request from a client, forwards it to an upstream MCP server, and returns the response. Nothing else.

An MCP Gateway includes a proxy and adds the control plane on top:

• Access control – enable or disable individual tools per connection
• Credential management – encrypted OAuth storage and automatic token refresh
• Session lifecycle – Mcp-Session-Id tracking across reconnects
• Usage analytics – aggregated tool call counts, latency, cost attribution
• Full call logging – every JSON-RPC message persisted for audit

Use a proxy when you need basic routing for a single upstream server. Use a gateway when you are running MCP at enterprise scale and need governance. Glama is a full gateway – not a roll-your-own routing layer.

An MCP connector is a pre-configured MCP server you can plug into an AI client in one step. In Claude, ChatGPT, and other clients, any remote MCP server a user has added to their account shows up as a "connector".

A Glama connector goes further. It adds hosting, managed credentials, and per-tool access control on top of the underlying server – so you don't have to run the server, store the tokens, or touch any config. Paste the Glama URL into Claude, ChatGPT, or Cursor, and the Glama Gateway does the rest.

MCP hosting is a managed service that runs an MCP server for you on infrastructure you don't have to provision. You get a public URL with TLS, OAuth and credential management, health checks, monitoring, and scaling – without running the server yourself.

Most MCP hosting platforms – Cloudflare Workers, Google Cloud Run, Azure Functions, AWS Bedrock AgentCore, Heroku – require you to bring your own server code. You write the MCP server, they run it.

Glama is different. We host open-source MCP servers from the registry directly: pick a server someone else already published, click deploy, and get a streamable-http endpoint fronted by the Glama Gateway – without writing a line of code yourself. Full call logging, per-tool access control, and managed OAuth credentials come out of the box.

Every JSON-RPC message – request, response, and SSE server event – is persisted to Glama's database with the full payload, including:

• tool name
• Input arguments
• Output result
• Timestamps and session IDs

Call logs are scoped to the connection profile owner – workspace members with the right role can view shared logs.

Per-tool access control is a per-connection on/off flag. Disable a tool and the gateway returns a JSON-RPC error to the client without ever forwarding the request upstream – the tool author never knows the call was attempted.

OAuth credentials are stored encrypted and automatically refreshed, so your client never holds the tokens. Revoking access is one click – no credential rotation required on the client side.

Heads up: the gateway captures full JSON-RPC payloads, so tool arguments containing sensitive data (API keys, PII, customer data) are visible in the audit log. For sensitive workloads, mask those arguments at the client side before calling.

Credentials. Glama stores OAuth access tokens, refresh tokens, and API keys encrypted with AES-256-GCM – each value gets its own random 16-byte IV and authentication tag, and the 256-bit key is held server-side only. They are decrypted in memory only at the moment of making an upstream request, and automatically refreshed before expiration. Your client never sees the raw credentials – only the Glama Gateway does.

Call logs. Full JSON-RPC payloads – including tool name, input arguments, and upstream output – are stored per connection profile so you can audit exactly what your agents did, with timestamps and session IDs for traceability.

Use the Glama MCP Inspector – an in-browser tool that connects to any MCP server URL and lets you:

• List tools, resources, and prompts
• Call them with structured inputs
• See raw JSON-RPC responses
• Handle OAuth flows, bearer tokens, and custom headers
• Exercise advanced spec features – tasks, elicitations, sampling, progress notifications, audio, and images

All state is encoded in the URL so you can share or bookmark a debug session. No install, no login, no local MCP client required – paste a URL, click inspect, and you're debugging.

The official reference inspector (@modelcontextprotocol/inspector) is an npm-installed local tool. Glama's is web-based – it works against remote MCP servers directly, and requests go from your browser to the MCP server without Glama ever logging them.

Yes. When you know what capability you need but don't know which server provides it, tool-level search gets you there in one query.

Glama indexes every tool exposed by every server in its registry – names, descriptions, input schemas, and the MCP annotation hints (readOnlyHint, destructiveHint, idempotentHint) that tell you whether a tool is safe to run in automated agent loops. You can search for capabilities like:

• query Postgres – find every database-query tool
• send email – find every email-sending tool
• generate Figma component – find every Figma-integration tool

Once you've found a matching tool, you can either install the underlying server yourself or plug in the Glama-hosted connector for that server in one click. Few other MCP directories index at the tool level.

A Glama connector URL works across every MCP-compatible client. Depending on your client:

• Claude – Customize → Connectors → click + → Add custom connector
• ChatGPT – Settings → Apps & Connectors → Create (Developer Mode must be enabled)
• Cursor – Settings → Features → MCP → + Add New MCP Server, or edit ~/.cursor/mcp.json
• VS Code – Command Palette → MCP: Add Server, or edit .vscode/mcp.json in your workspace

For other MCP-compatible clients (Windsurf, Zed, JetBrains IDEs, Replit, …), setup is client-specific – check your client's MCP configuration docs. Any client that speaks MCP will accept a Glama connector URL – one connector, every agent.

Submit open-source MCP servers to the Glama registry straight from a GitHub repository. On the servers page, click Add MCP Server and fill in:

• The GitHub repository URL for your server
• A display name and short description

Glama runs automated quality checks (license detection, security scan, health test) during indexing. Most submissions pass automatically within minutes and become discoverable through Glama's search, category pages, and recommendation feeds.

Control how your server is indexed by adding a glama.json metadata file to your repo – it lets you set the display name, description, category, environment variables, and build spec. Servers must be on GitHub today; for other sources, reach out on Discord.

Connectors are remote MCP servers you've already deployed somewhere with a public endpoint. On the connectors page, click Add MCP Server → Connector and provide:

• A name and short description
• The server URL – must be HTTPS and speak the streamable-http transport
• Optional private test credentials (API keys, OAuth details) so Glama can verify the connector is reachable

If your server implements OAuth 2.1 dynamic client registration (RFC 7591), you can skip the test credentials – Glama will register automatically.

Only healthy connectors are indexed for search. Unhealthy connectors stay in pending state until they become reachable. Submitted connectors are public by default and discoverable immediately once healthy. You can mark a connector as deprecated later if you're retiring the upstream server – users browsing Glama will see a notice.

The auth method on your connector's test profile is what sets the auth: badge. A maintainer's declaration is what the badge reflects wherever there is one; where there is not, Glama falls back to what it can detect – a server that advertises OAuth metadata and refuses unauthenticated traffic is listed as auth:oauth2 automatically. Nothing else is inferred, because a connector that lets anyone list tools looks identical to one that needs no auth at all.

To set it, claim your connector and open its page, then create or edit the test profile and pick the authentication method your server actually requires – No Auth, API Key, Basic Auth, or OAuth 2.0. That choice becomes the connector's primary auth method and updates the badge. Until a test profile declares one, a connector reads as auth:none.

Open discovery with authenticated calls is a common shape – tools/list is left open so directories can index and health-check the server, while every tools/call requires a key and returns 401 with WWW-Authenticate. Declare the method the calls need, since that is what someone integrating the connector has to provide. Set the test profile to API Key, add a test credential so health checks exercise the authenticated path, and describe the open-discovery behaviour in your connector description.

Selecting No Auth will not clear a badge your server contradicts. If the last health check was refused with a 401, the test profile still switches to connecting without credentials, but the connector stays listed as it was – publishing auth:none for a server that turns away unauthenticated callers would tell integrators they need no key when they do. Health-checking a server without credentials is not the same claim as the server being open.

The badge carries one method. If your server accepts more than one – say an API key or OAuth – set the test profile to the one most integrators will use and document the rest in the description. Declaring a method also overrides the automatic OAuth detection above, so a server that speaks both is listed the way its maintainer describes it.

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

1. Open the connector listing, choose Claim ownership, and sign in to Glama.
2. Complete one verification method:
   • GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
   • HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
   • DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
3. After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

The following AI clients support MCP natively or via adapter:

• Claude Desktop, Claude Code
• ChatGPT
• Cursor, Windsurf, Zed
• VS Code (with the MCP extension)
• JetBrains IDEs
• Replit
• Sourcegraph (via Cody)

Glama tracks every MCP-compatible client with its supported features listed in the client directory.

The official MCP Registry is a vendor-neutral index of MCP server metadata maintained by the MCP steering group – the canonical source of truth for publicly published servers.

Glama builds on top of it with much deeper per-connector data and a full control plane:

• Rich metadata on every connector – health checks, quality scores, security audits, tool schemas with annotations, usage telemetry, license info, and maintainer notes
• One-click hosting on managed infrastructure
• Full observability and control over every call – JSON-RPC logging, per-tool access control, managed OAuth credentials, and usage analytics

Use the official registry for vendor-neutral metadata. Use Glama when you need depth, observability, and control over production MCP traffic. See our indexing methodology for the full technical description of how every server in the Glama registry is built, introspected, audited, and scored.