Codex OpenRouter MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_profilesA | List approved model/provider profiles, privacy policy, server/plugin versions, and configured-but-unverified guardrail expectation. |
| delegate_taskA | Run one bounded inline-text task synchronously with an approved external model. |
| review_filesA | Synchronously review 1-100 explicitly named UTF-8 text or source files under the locked workspace root, up to 500 KB each and 750 KB combined. This call cannot be continued with send_followup. |
| start_file_reviewA | Start a follow-up-capable review of 1-100 explicitly named UTF-8 text or source files, retaining the exact hashed input snapshot in memory for send_followup. |
| start_taskC | Start a bounded external-model task and return immediately with a job ID. |
| get_task_statusB | Read status for an asynchronous delegation job. |
| get_task_resultB | Return the completed result and model/provider audit metadata. |
| send_followupA | Continue a completed in-memory delegation with a bounded follow-up. |
| cancel_taskA | Request cancellation of a queued or running in-memory delegation. |
| prepare_artifactC | Read explicitly approved text inputs and stage new validated artifacts in memory. |
| preview_artifactA | Preview an in-memory artifact proposal and its content hashes without writing files. |
| commit_artifactA | Atomically create validated new artifact files after preview and hash confirmation. |
| discard_artifactB | Discard an uncommitted in-memory artifact proposal; committed files are untouched. |
| list_artifact_jobsA | List metadata for in-memory artifact proposals without returning their contents. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Tools are mostly separable by domain (profiles, tasks, file reviews, artifacts), but there is ambiguity between synchronous and asynchronous variants (delegate_task vs start_task, review_files vs start_file_review) and send_followup applies to both tasks and file reviews, which could confuse an agent about which context it is for.
Naming is mostly verb_noun but inconsistent in verb choice: delegate vs start, review_files vs start_file_review, and get_task_result vs get_task_status are similar but not parallel. The start_ prefix is applied unevenly, and send_followup is a generic verb that doesn't match the pattern.
14 tools is within the ideal 3-15 range and each tool appears to serve a distinct role in task delegation, file review, and artifact management. No tool seems redundant or unnecessary.
The surface covers task lifecycle (start, status, result, cancel, follow-up) and artifact lifecycle (prepare, preview, commit, discard, list), but file reviews lack a dedicated cancel mechanism and there is no explicit result retrieval for async file reviews, relying on generic get_task_result or send_followup, which creates potential dead ends.