orgspec
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | Port for the HTTP server (e.g., 3456). | |
| GITHUB_TOKEN | No | GitHub token with contents and pull requests permissions for the context repository. | |
| MCP_ACCESS_KEY | No | Bearer key for MCP clients on /mcp. Required when a default repository is configured unless ORG_CONTEXT_ALLOW_OPEN=1. | |
| ORG_CONTEXT_PATH | No | Local context repository root. Default: current directory. | |
| ORG_CONTEXT_APP_ID | No | GitHub App ID for hosted mode with GitHub App. | |
| ORG_CONTEXT_BRANCH | No | Branch to serve in GitHub mode. Default: the repository's default branch. | |
| ORG_CONTEXT_GITHUB | No | GitHub repository to serve (e.g., 'owner/repo'). | |
| ORG_CONTEXT_WEB_KEY | No | Key for the optional read-only web view at /c/<key>/. | |
| ORG_CONTEXT_ALLOW_OPEN | No | Set to '1' to run without MCP_ACCESS_KEY (only for local development). | |
| ORG_CONTEXT_APP_ORIGIN | No | Explicit origin for the GitHub App host (if different from MCP host). | |
| ORG_CONTEXT_WRITE_MODE | No | 'direct' or 'propose'. Default: 'direct' for local folder, 'propose' for GitHub repository. | |
| ORG_CONTEXT_GITHUB_TOKEN | No | Alternative to GITHUB_TOKEN; same usage and permissions. | |
| ORG_CONTEXT_APP_CLIENT_ID | No | GitHub App client ID for OAuth flows. | |
| ORG_CONTEXT_APP_PRIVATE_KEY | No | GitHub App private key (PEM) for hosted mode. | |
| ORG_CONTEXT_APP_CLIENT_SECRET | No | GitHub App client secret for OAuth flows. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_contextA | Read the organizational context (Org Context Spec repo). Without arguments: returns the context README (the reading order and writing rules — always start here) plus a list of all context files — or, for a new/empty repository, onboarding instructions for seeding it. With a path: returns that file, or its starter template if the file does not exist yet. Read the relevant context BEFORE writing code, stories, or product documents. If you know which team you work for, read teams/.md early — it maps the team's tracker, systems, and product areas. |
| propose_context_changeA | Propose one coherent change to the context — one or several files that together make up a single logical decision. Bundle everything that belongs together into ONE call: one proposal becomes one commit (and one pull request for review), never one per file. IMPORTANT: the model recommends, a human decides — show the user exactly what will change and get their explicit approval BEFORE calling this tool. Provide the complete new content of each file. |
| searchA | Search the organizational context files. Returns matching files; use fetch to read one. |
| fetchA | Read one organizational context file by id (its path, as returned by search). |
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 4 tools
get_context(path) and fetch both read a single context file, so a model could be unsure which to use; get_context's no-argument entry-point behavior and fetch's 'file id from search' purpose do differentiate them somewhat. search and propose_context_change are clearly distinct.
get_context and propose_context_change follow a verb_noun pattern, while search and fetch are bare verbs, producing a mixed but readable convention. The names are not chaotic, but they do not form a fully predictable pattern.
Four tools is a well-scoped set for an organizational context repository: an entry point, a search mechanism, an exact file reader, and a change proposal action. None feel gratuitous, and the count is comfortably within the ideal range.
The surface covers the core workflow: start from context, search/fetch existing files, and propose coherent changes. There is no direct create/update/delete tool outside propose_context_change, but that appears intentional for a human-reviewed context repo, so the gap is minor.