Enables access to Google models through the Glama AI gateway, with tools for listing models, chat completions, streaming completions, and request-status lookup.
Enables access to OpenAI models (such as openai/gpt-4o) through the Glama AI gateway, with tools for listing models, chat completions, streaming completions, and request-status lookup.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@glama-gateway-mcp List the models available through the Glama gateway."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Models Context Protocol (MCP) server that exposes the Glama AI gateway (https://gateway.glama.ai/v1, an OpenAI-compatible endpoint for 100+ models) as MCP tools. Standard library only, Python 3.9+, no model downloads.
MCP clients (Claude Desktop, Cursor, and a growing list of agent runtimes)
each expect an MCP server per capability. When a research project needs to
call language models across many providers — openai/..., anthropic/...,
google/..., and dozens more — wiring every client to every provider is a
tangle of credentials and bespoke plugins. Glama centralizes provider access
behind one OpenAI-compatible API, but it does not, by itself, hand a model
to an MCP client.
glama-gateway-mcp closes exactly that seam. It is a thin, dependency-free
MCP server that fronts the gateway: an agent (or IDE, or personal assistant)
talks MCP to this one server and gains openai/gpt-4o, anthropic/claude-2,
and any other gateway model through four tools — listing models, chat
completion, streaming completion, and request-status lookup. One API key, one
credential, one endpoint for every connected application.
Distinguishing design choices:
stdio MCP, implemented on the stdlib — the protocol layer uses only
json, urllib and sys, so it runs anywhere Python runs and is trivial
to audit.
OpenAI-compatible request/response shapes — the gateway returns raw gateway bodies, so no field mapping is ever wrong.
Server-side stream reassembly — MCP clients that cannot hold a live SSE stream still receive the full completion text plus usage metadata.
Clean JSON-RPC errors — a missing key, unreachable gateway, or unknown tool yields a readable MCP error instead of a hang or silent failure.
Related MCP server: OpenAI Assistant MCP Server
pip install .
# development:
pip install -e ".[dev]"Requires Python 3.9+. Runtime dependencies: none.
Export your Glama key, then run the server:
export GLAMA_API_KEY="your_key_here"
export GLAMA_DEFAULT_MODEL="openai/gpt-4o" # optional
glama-mcpor run it as a module:
python -m glama_mcpConnect any MCP client to the glama-mcp stdio command. The exposed tools:
Tool | Purpose |
| list models available through the gateway |
| one-shot chat completion |
| streamed completion (reassembled) |
| status of a completion request by id |
Ready-to-paste mcpServers blocks for individual applications live in
configs/: Celebrum, Samvit, Collabuild, S-AI, hermes-agent,
teddy-techlearn, health-quest, ai-content-studio, and the portfolio site.
Each block registers this server for that application's MCP client.
{
"mcpServers": {
"glama-gateway": {
"command": "glama-mcp",
"env": { "GLAMA_API_KEY": "your_key_here" }
}
}
}printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
| python -m glama_mcppython -m pytestThe suite covers the gateway client (payload shapes, SSE reassembly), protocol handshake, tool discovery and dispatch, error handling, missing-key behaviour, and a full stdio round trip.
See CONTRIBUTING.md. Keep it dependency-free and Python 3.9 compatible; every change needs a test.
Submission materials in paper/: paper.md, paper.bib, and
JOSS_SUBMISSION_READINESS.md (records which gates are met and which still
require calendar time).
MIT — see LICENSE.
Code and documentation were drafted with generative-AI assistance and reviewed by the human maintainer, who made the design decisions. This disclosure is kept in line with the JOSS AI usage policy.
Run a chat completion against the Glama gateway. messages is an array of {role, content} objects.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | e.g. openai/gpt-4o, anthropic/claude-2 | |
| messages | Yes | ||
| max_tokens | No | ||
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only states the action and mentions the messages structure. It does not disclose whether this is a blocking call, whether it supports streaming, any authentication requirements, rate limits, or error behavior. This is a significant gap for a tool that likely makes network calls and returns a completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the purpose. It avoids unnecessary verbiage and is structurally clean. However, it is so brief that it omits critical details, but that is more about completeness than conciseness. As a structure, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, one required, and no output schema. Given this complexity, the description needs to explain the return value, error handling, and usage context. It only mentions the messages structure and nothing else. It is incomplete for an agent to call correctly, especially without annotations to cover safety or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 25% (only 'model' has a brief example, not a semantic description). The description adds a note about the 'messages' structure, but that is already in the schema. It does not explain the meaning or expected format of 'model', 'max_tokens', or 'temperature' beyond what the schema provides. Since coverage is low, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Run a chat completion against the Glama gateway.' This clearly conveys the tool's primary function. However, it does not explicitly differentiate from the sibling 'glama_stream_completion', which also performs chat completions but likely in streaming mode. The name implies non-streaming, but that is not stated, so the purpose is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'glama_stream_completion' or when not to use it. There are no conditions, prerequisites, or comparisons. The agent is left to infer usage from the name alone, which is insufficient for a tool with multiple siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the models available through the Glama gateway (OpenAI-format model ids).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states it lists models, which is a read-only operation, but does not explicitly say it's read-only or mention any side effects. For a simple list tool, this is adequate, but it could be more explicit about the return format or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It is efficient and to the point, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides enough context: it tells the agent what it returns (model ids in OpenAI format). It is complete for the agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The schema is empty, and the description adds no parameter information, which is fine. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (models available through the Glama gateway), and specifies the format (OpenAI-format model ids). This distinguishes it from sibling tools that handle completions and status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus the siblings. However, the purpose is clear enough that an agent would infer to use it to discover available models before making completion calls. No explicit alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the status of a completion request by id.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that this is a lookup; it does not say whether the call polls, blocks, returns immediately, errors on unknown ids, or requires authentication. With zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, and the verb and object are front-loaded. Nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status-checking tool with no output schema and no annotations, the description should explain the polling workflow and the provenance of request_id. It does neither, so an agent cannot tell whether to call once or repeatedly, or what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. 'by id' confirms that request_id is the identifier of the completion request, adding a small amount of meaning beyond the bare schema; however, it does not say where the id comes from or what format it takes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('look up'), a resource ('status of a completion request'), and the key ('by id'), making the action unambiguous. It is clearly distinct from siblings that list models or create completions, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, such as after invoking glama_chat_completion or glama_stream_completion, nor is there any mention of the async request lifecycle. The sibling names imply the workflow, but the description leaves it entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Streamed chat completion; deltas are reassembled into one text answer with usage metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | ||
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations are provided, the description carries the full burden of exposing behavior. It discloses that deltas are reassembled into one text answer and that usage metadata is included, which is useful. However, it does not mention side effects, error conditions, rate limits, or whether the operation is read-only. For a streaming operation, knowing that it returns an aggregated result is significant, but many behavioral aspects remain opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, a single sentence that front-loads the core purpose and the key reassembly behavior. It earns its place without fluff. However, it is almost too sparse, sacrificing parameter and usage detail for brevity, yet structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the schema (2 params, no descriptions) and lack of output schema and annotations, the description does too little to support correct invocation. It fails to explain the messages array format, the role/content structure, the optional model parameter, or the shape of the returned aggregated answer. An agent would likely underspecify or misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters at all. It doesn't explain what 'messages' or 'model' mean, their formats, or any defaults. Since the schema provides only types, the agent has no semantic guidance, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: it performs a streamed chat completion and reassembles the deltas into one text answer. This distinguishes it from sibling tools like glama_chat_completion (presumably non-streamed) and glama_list_models. The verb 'streamed' and the resource 'chat completion' are specific, and the reassembly detail adds functional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a streamed response is desired, but it does not explicitly mention when to avoid it or name alternatives. There is no guidance on prerequisites, auth, or when to choose non-streamed chat completion. The context is clear but the when/why is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0glama_chat_completionglama_list_modelsglama_request_statusglama_stream_completionScored across 4 tools
list_models and request_status are clearly distinct, but chat_completion and stream_completion overlap in purpose as they both perform chat completions. The descriptions clarify streaming vs. non-streaming, so an agent can differentiate them, though some ambiguity remains.
All tool names share the glama_ prefix and follow a consistent snake_case verb_noun pattern. The naming is predictable and uniform across the set.
Four tools is well-scoped for a gateway-focused server covering model discovery, completion, streaming, and status lookup. Each tool has a clear, non-redundant role.
The core workflow of listing models and running both standard and streaming completions is covered, plus status lookup for async requests. Minor additions like request cancellation or model details would improve completeness, but no critical gap exists.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Connect MCP clients to 2,000+ AI models without managing provider API keys.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
