OpenCodeMode
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DB_PASS | No | PostgreSQL password used in the example postgres connection string. | |
| DB_USER | No | PostgreSQL username used in the example postgres connection string. | |
| GITHUB_TOKEN | No | GitHub token expanded into GITHUB_PERSONAL_ACCESS_TOKEN for the github downstream server. | |
| JIRA_API_TOKEN | No | Jira API token used when configuring the jira downstream server in codemode.config.json. |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_codeA | Execute TypeScript/JavaScript code inside an isolated sandbox to orchestrate tools and filter data. Intermediate data stays in memory; return only the final result to save tokens. Available APIs on the global |
| get_tool_typesA | Returns the complete TypeScript declaration file (.d.ts) describing all available downstream tools. |
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 2 tools
The two tools are clearly distinct: execute_code runs TypeScript/JavaScript in a sandbox, while get_tool_types returns the downstream TypeScript declarations. An agent can easily tell which tool to use for execution versus discovery.
Both names follow a consistent snake_case verb_noun pattern: execute_code and get_tool_types. There is no mixing of conventions or vague naming.
Two tools is minimal, but for a meta-execution server this surface is well-scoped: one tool discovers downstream APIs and the other executes code against them. It is slightly thin by typical MCP standards but reasonable for the stated purpose.
The pair covers the core lifecycle of discovering downstream tool types and executing orchestration code against them. Minor gaps exist around richer discovery or validation, but the essential workflow has no dead ends.