bitra
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| XAI_API_KEY | No | API key for the xai provider. | |
| GROQ_API_KEY | No | API key for the groq provider (free tier); the provider named by `tra init my-desk --profile autonomous --agent groq`. | |
| GEMINI_API_KEY | No | API key for the google provider. | |
| GOOGLE_API_KEY | No | Alternative API key for the google provider. | |
| OPENAI_API_KEY | No | API key for the openai provider. | |
| 9ROUTER_API_KEY | No | API key for the 9router provider, a local router. | |
| MISTRAL_API_KEY | No | API key for the mistral provider. | |
| DEEPSEEK_API_KEY | No | API key for the deepseek provider. | |
| ANTHROPIC_API_KEY | No | API key for the anthropic provider. | |
| DASHSCOPE_API_KEY | No | API key for the qwen provider. | |
| OPENROUTER_API_KEY | No | API key for the openrouter provider. |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_cost_floorA | Check whether a claimed edge can pay for trading it, before any data is touched. |
| observe_eventsA | Layer 1: count whether the event declared in observation.toml recurs in a dataset. |
| check_registrationA | Read a sealed pre-registration: its hypothesis, universe, power and kill criteria. |
| audit_datasetA | Audit a raw trade archive before anything is tested on it. |
| validate_tradesA | Layer 5: judge a set of closed trades against the registration sealed before them. |
| show_ledgerA | List the kill ledger: every verdict that stands, and the count per verdict. |
| show_ladderA | Show the promotion ladder: the tier a strategy is on and how it got there. |
| read_run_reportA | Read one run's report: what a replay, shadow or canary run did, and how it ended. |
| search_ledgerA | Search the kill ledger for verdicts that mention the words in |
| list_runsA | List past runs under a directory, newest first, with the summary of each. |
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 10 tools
Every tool targets a distinct artifact or pipeline stage: run listings vs. a single run report, full ledger vs. ledger search, ladder, cost floor, event observation, registration reading, dataset audit, and trade validation. Overlap-prone pairs like list_runs/read_run_report and show_ledger/search_ledger are explicitly distinguished in the descriptions (list vs. detail, full picture vs. one idea). No two tools could plausibly be mistaken for each other.
All ten tools follow a strict verb_noun snake_case convention (list_runs, show_ledger, read_run_report, search_ledger, check_cost_floor, observe_events, audit_dataset, validate_trades). Verbs are chosen sensibly and no convention mixing or vague naming appears.
Ten tools is well within the healthy range and each maps to a concrete research step or view. Nothing feels redundant or padded, and no obvious operation is missing from the count alone.
The read-only research lifecycle is well covered end to end: audit dataset, check cost floor, observe events, read registration, validate trades, plus run/ledger/ladder views. Gaps exist only on the write side (sealing registrations, promoting tiers, writing verdicts), which the descriptions state is intentionally out of scope for this surface.