BoteX
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BOTEX_LANG | No | CLI language: en, pl, or auto. Overrides ui.language. Example: BOTEX_LANG=pl. | |
| BOTEX_REFERER | No | Attribution URL sent to OpenRouter in the HTTP-Referer header. | |
| BOTEX_ENV_FILE | No | Path to a custom .env file that contains OPENROUTER_API_KEY. An alternative to setting OPENROUTER_API_KEY directly. | |
| NVIDIA_API_KEY | No | Optional API key if using the NVIDIA provider. Resolved from this env var, .env, or botex.config.local.json (secrets.nvidia_api_key). | |
| BOTEX_MAX_TURNS | No | Maximum number of tool-loop steps per task. Example: BOTEX_MAX_TURNS=20. | |
| BOTEX_BUDGET_USD | No | Daily spend cap in USD. Example: BOTEX_BUDGET_USD=1.0. | |
| BOTEX_MAX_TOKENS | No | Per-turn completion token limit. Example: BOTEX_MAX_TOKENS=8000. | |
| BOTEX_TEMPERATURE | No | Sampling temperature. Example: BOTEX_TEMPERATURE=0.2. | |
| BOTEX_CODING_MODEL | No | Model slug for the coding profile. | |
| BOTEX_DEFAULT_MODE | No | Default capability mode: readonly, edit, destructive, full. Example: BOTEX_DEFAULT_MODE=edit. | |
| BOTEX_EXEC_ENABLED | No | Set to '1' to enable the run_command tool (requires exec.enabled and per-request authorization). Defaults to 'false'. | |
| BOTEX_SNAPSHOT_DIR | No | Directory where snapshots are stored. Defaults to .snapshots. | |
| OPENROUTER_API_KEY | No | Your OpenRouter API key. Required for provider calls. It can be supplied directly via this environment variable, via a .env file, BOTEX_ENV_FILE, or botex.config.local.json (secrets.openrouter_api_key). | |
| BOTEX_DEFAULT_MODEL | No | Explicit default model slug for the default provider profile. | |
| BOTEX_ANALYTICS_FILE | No | Path to the analytics ledger file. Defaults to .agent_analytics.json. | |
| BOTEX_AUTO_BETA_MODEL | No | Model slug for the auto-beta profile. | |
| BOTEX_DEFAULT_PROFILE | No | Default model profile: default, coding, fast, auto-beta. Example: BOTEX_DEFAULT_PROFILE=coding. | |
| BOTEX_PRICE_MAX_INPUT | No | Maximum input price per million tokens. 0 disables the cap. | |
| BOTEX_PRICE_MAX_OUTPUT | No | Maximum output price per million tokens. 0 disables the cap. | |
| BOTEX_ALLOW_DESTRUCTIVE | No | Set to '1' to globally enable destructive operations (delete_file/move_file). Defaults to 'false'. | |
| BOTEX_ANALYTICS_FULL_TEXT | No | Set to '1' to store full text in analytics. Defaults to 'false'. |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_taskA | Start a detached BoteX task and return its task_id immediately. Runs the same engine as The capability/limits arguments are identical to
Returns:
{"task_id": str, "status": "QUEUED"} — poll with get_task_status.
The finished task's |
| get_task_statusA | Return status and result for a task started with start_task.
|
| fetch_urlA | Fetch one public http(s) text document for caller-side research. This tool is intentionally separate from BoteX's internal read_url: the orchestrating agent chooses the URL, so arbitrary public hosts do not have to be configured in net.allowed_hosts. SSRF protections, redirect revalidation, content-type checks, byte limits, and secret masking still apply. In net.policy='allowlist', only configured hosts may be fetched. |
| recommend_modelsA | [EN] Fetches the most cost-effective and capable models from OpenRouter based on live benchmarks.
USE THIS TOOL BEFORE calling [PL] Pobiera rekomendacje modeli z OpenRouter na podstawie benchmarków.
Użyj tego narzędzia ZANIM wywołasz |
| run_subagentA | Runs BoteX — an autonomous code execution engine (agent-agnostic harness). BoteX performs multi-step tasks on local files inside workspace_dir. TIP: If the user didn't specify a model, DO NOT guess. Use the Key engine features:
Args: task: Precise description of the coding or refactoring task. files: Optional list of primary files affected by the task. workspace_dir: Project directory path (defaults to current directory). model: Any model from the provider's catalog. Empty = model from config (see 'profile' and botex.config.json). profile: Model profile from botex.config.json (e.g. 'default', 'coding', 'auto-beta', 'fast'). When both 'model' and 'profile' are empty, the capability mode picks the tier via engine.mode_profiles (readonly -> 'fast', destructive/full -> 'coding'). Ignored when 'model' is given explicitly. provider: API provider from the 'providers' section of botex.config.json ('openrouter', 'nvidia'). Empty = provider marked 'default: true' in the configuration. mode: Capability preset: 'readonly' (read only — the contract is an analysis report, DONE requires non-empty findings), 'edit' (read + edit — default), 'destructive' (+delete/move), 'full' (+run_command). Empty = engine.default_mode from config. Explicit allow_* flags may only WIDEN a preset — they never narrow it (readonly can never gain file writes). In headless mode this is pre-authorization — grant it consciously. max_turns: Maximum tool-loop steps (0 = config value). max_tokens: Per-turn completion cap (0 = config value; reasoning models need ~8000+ since thinking shares this budget). max_duration_s: Total wall-clock limit in seconds (0 = config value, 0 disables only when config is also 0). Checked between turns. budget_limit_usd: Daily spend limit in USD (negative = config value, 0 = no limit). allow_destructive: Authorize destructive operations (delete_file/ move_file) for this task. Headless mode cannot confirm mid-run — grant ONLY with the user's consent. allow_exec: Authorize run_command for this task (also requires exec.enabled=true in config). WARNING: this is NOT a sandbox — commands run with operator privileges. Grant only for trusted workspaces with the user's consent. api_key: Optional provider API key passed per-request (highest priority — overrides env/.env/config). Empty = resolved internally by the harness. output_path: Optional required output file (workspace-relative). Sets the file_output contract: DONE is accepted only when the file exists on disk, is non-empty, and passes the syntax gate; a DONE response carrying the payload as text is salvaged to disk. Requires a mutating mode. allow_net: Explicitly authorizes the read-only public web tool for this run. It is never enabled by a capability mode. net_allowed_hosts: Optional per-run host authorization. In net.policy='caller' these replace config defaults; in 'public' they narrow public access; in 'allowlist' they must stay inside net.allowed_hosts. net_allowed_urls: Optional per-run URL authorization rules. A URL ending in '/' authorizes that subtree; otherwise it authorizes the exact URL including its query string. verify_command: Optional allowlisted command that must pass before DONE is accepted — it runs against the workspace as it stands, including when the task made no writes (a passing verifier validates a legitimate no-change result). Requires exec.enabled=true in config and exec authorization. recipe: Optional operational persona / workflow prompt (e.g. 'planner', 'code-explorer', 'reviewer', 'security-reviewer', 'build-resolver', 'tdd'). Returns:
A pretty-text report in the text content (unchanged format for legacy
clients) plus the full engine result as structuredContent (status,
failure_kind, ok, files_touched, exec_ran, rollback_verified,
attempts[], cost_usd, ...). |
| get_outlineA | Returns a lightweight file skeleton (classes, methods, functions, headers, line numbers) without reading the whole file. Saves ~90% of tokens. |
| save_memoryA | Saves a persistent context note, architectural decision, task handoff, or lesson into the workspace Memory Vault (/.botex/memory/). Masks secrets and provides directory isolation. Args: title: Short descriptive title of the memory entry. content: Detailed markdown notes, architectural rationale, or handoff context. workspace_dir: Workspace root directory (defaults to current directory). kind: Entry category ('context' | 'decision' | 'handoff' | 'lesson'). tags: Optional list of keyword tags for filtering and discovery. memory_id: Optional custom identifier (alphanumeric/hyphen/underscore). Auto-generated if omitted. |
| search_memoryA | Searches the workspace Memory Vault (/.botex/memory/) by keyword query, tag, or entry kind (context, decision, handoff, lesson). Args: workspace_dir: Workspace root directory (defaults to current directory). query: Free-text search string matched against title, content, and tags. tag: Filter by specific tag. kind: Filter by entry kind ('context', 'decision', 'handoff', 'lesson'). |
| read_memoryA | Reads the full content and metadata of a specific memory entry by ID from the workspace Memory Vault. Args: memory_id: The ID of the memory entry to retrieve (e.g. 'mem_a1b2c3d4'). workspace_dir: Workspace root directory (defaults to current directory). |
| get_statsA | Returns an analytics summary of executed BoteX tasks (USD costs, token usage, code-line balance). Args: period: 'week' (last 7 days) or 'month' (last 30 days). |
| check_healthA | Checks BoteX environment readiness (provider keys, snapshot dir, disk). |
| clean_snapshotsC | Purges old or excess backup snapshots from disk. |
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 12 tools
Most tools target distinct resources or actions, but run_subagent and start_task are near-duplicates sharing the same engine and argument contracts, differing mainly in sync vs. async execution. The descriptions clearly clarify the intended usage, so confusion is possible but manageable.
All tool names follow a consistent snake_case verb_noun pattern: get_task_status, start_task, save_memory, clean_snapshots, etc. There are no mixed casing styles or vague generic verbs.
Twelve tools is well within the ideal range and each tool serves a distinct operational need: task execution, async polling, model selection, memory vault access, stats, health, and snapshot cleanup. No tool feels superfluous.
The core workflows are well covered: synchronous and detached task execution, status polling, memory persistence and lookup, model recommendation, and environment maintenance. Minor gaps exist, such as no explicit cancel_task and no update/delete for memory entries, but agents can work around these in most scenarios.