frontier-orchestrator
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| specialist_statusA | Check whether the configured Codex, Kimi, and Grok CLIs are available. This does not verify account authentication. |
| delegate_backendA | Delegate backend, API, database, auth, infrastructure, security, performance, or backend-test work to Codex. Use analyze/review for read-only work and implement for edits. |
| delegate_frontendA | Delegate product design, UX, visual systems, components, styling, accessibility, responsive behavior, animation, client state, or frontend-test work to Kimi. Use analyze/review for read-only work and implement for edits. |
| delegate_buildA | Delegate domain-neutral build tooling, dependency or toolchain upgrades, CI and release automation, mechanical repository-wide transformations, generated boilerplate, or test and lint cleanup to Grok Build. Backend behavior belongs to Codex and frontend or UX behavior belongs to Kimi unless the user explicitly overrides routing. Never choose Grok solely for speed. Use analyze/review for read-only work and implement for edits. |
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
Each tool has a clearly distinct purpose: specialist_status checks CLI availability, while delegate_backend, delegate_frontend, and delegate_build target different domains (backend, frontend, build). The descriptions explicitly state boundaries for each delegation tool, so there is no overlap.
The three delegate tools follow a consistent 'delegate_<domain>' pattern, but specialist_status diverges by using a noun-based name instead of a verb. This is a minor deviation that does not cause confusion.
Four tools is well-scoped for an orchestrator that delegates to three specialist CLIs and checks their availability. Each tool earns its place and there is no unnecessary bloat.
The tool surface covers status checking and delegation for all three specialist domains (Codex, Kimi, Grok Build), including read-only and implementation modes. No significant gaps are apparent for the stated purpose.