Cortex Gateway
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OAUTH_ISSUER | Yes | Your OAuth 2.1 authorization server | |
| CORTEX_BACKENDS | Yes | Comma-separated list of backend IDs | |
| CORTEX_DATABASE_URL | No | PostgreSQL for audit persistence + gateway tickets | |
| CORTEX_CANONICAL_URI | No | Canonical MCP resource URI (RFC 9728), default JWT audience | |
| CORTEX_ALLOWED_ORIGINS | No | Web origins allowed (exact or *.suffix) | |
| CORTEX_TECHNICAL_TOKEN | Yes | Static token for catalog discovery | |
| CORTEX_DEV_BYPASS_TOKEN | No | Dev bypass token for local development | |
| CORTEX_DEV_BYPASS_SCOPES | No | Scopes for dev bypass token | |
| CORTEX_TICKET_WEBHOOK_URL | No | Webhook for blocking missing-capability tickets |
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
} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoamiA | Returns the caller's OAuth identity (email, sub, pool, scopes, client, audience, jti) and aggregates the whoami of every healthy federated backend (effective role in that backend, derived capabilities). Useful to know who you are and what you may do before invoking a write tool. |
| list_cortex_resourcesA | Lists the MCP resources exposed by the gateway (self-describing architecture document, dynamic backend resources through URI templates). Wrapper tool over the resources/list channel, needed because some MCP clients do not surface the resources primitive in their visible tool palette. |
| read_cortex_resourceA | Reads an MCP resource by URI (e.g. cortex://architecture, docs://document/42). Wrapper tool over the resources/read channel. Returns Markdown or JSON depending on the resource. Use after list_cortex_resources to discover available URIs. |
| report_missing_capabilityA | Reports a missing capability or an insufficient tool to the platform team. Use it when you cannot fulfil a user request because no MCP tool offers what is needed, OR when an existing tool limits you (incomplete return, missing parameter, unhelpful error, ...). Typical example: the user asks for a link to a file; you search the returns of list_files / read_file, there is no webUrl field; you report the missing capability. The platform team prioritizes and ships the field in a next release. Principle: your ticket is a SIGNAL, not an implementation order. Several converging tickets = a priority. Do not hesitate to report even when unsure — noise is filtered at triage. Do NOT report an obvious bug (the API returns 500) — let the error surface naturally instead. Auto-dedup: an identical ticket (same description + same tool + same agent) within 24h just refreshes the timestamp instead of creating a duplicate. Before reporting, consider calling Returns: { ticketId, deduplicated, ackMessage }. |
| list_cortex_ticketsA | Lists your own previously filed Possible statuses: open (just filed), triaged (the team looked at it), planned (work scheduled), resolved (capability shipped, resolvedPrUrl points at the PR), wont_fix (deliberately not implemented, triageNote explains why), duplicate (merged with another). Returns: { tickets: [{ id, status, severity, contextTool, contextApp, whatIWanted, suggestedShape, triageNote, resolvedPrUrl, createdAt, updatedAt }] }, sorted by createdAt desc, max 100. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Gateway architecture | Self-generated description of the gateway: OAuth chain, federation model, live-discovered backends, principles. |
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: listing resources, listing tickets, reading resources, reporting missing capabilities, and identity check. No overlap or ambiguity.
Most tools follow a 'verb_cortex_noun' pattern (list_cortex_resources, list_cortex_tickets, read_cortex_resource), but report_missing_capability lacks 'cortex' and whoami is a single verb, causing minor inconsistency.
5 tools is well-scoped for a gateway providing resource discovery, ticket management, and identity checking; each tool earns its place without bloat or deficiency.
The tool set covers all essential operations: discovering resources, reading them, filing tickets, viewing own tickets, and identity verification. No dead ends or missing functionality for the stated purpose.