Brute Genius
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
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| brute_genius_planA | Enumerate the full Cartesian product and return a cost estimate. Does NOT execute anything. Refuses to return a plan_id when the estimated cost exceeds max_cost_usd. |
| brute_genius_launchC | Shard the enumerated space and score every combination. Re-checks balance and cost ceiling before any work is dispatched. Streams progress via ctx.report_progress and logs via ctx.info. |
| brute_genius_statusA | Return live progress, shards done, combinations evaluated, best-so-far. |
| brute_genius_resultsC | Return the top_k highest-scoring combinations (descending score). |
| brute_genius_killB | Stop every node and shard belonging to a plan. Ends billing. Partial results already scored are preserved. Always available even if the calling agent goes silent. |
| xpu_probeB | Detect and report available accelerators on the current machine/fleet. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| define_search | Walk the user through specifying a search space, objective, and cost ceiling. |
| interpret_results | Ask the LLM to explain the top results and any visible patterns. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| list_plans | List of all plans and their current states. |
| hardware_inventory | Live inventory of accelerators visible to this process. |
| pricing | Current burn rate per chip type (USD per hour). |
TDQS
Scored across 6 tools
The lifecycle tools are mostly clearly separated: probe, plan, launch, status, kill, and results each have distinct roles. The main possible confusion is between `brute_genius_status` reporting best-so-far and `brute_genius_results` returning top_k combinations, but the live versus final-results distinction is reasonably clear.
Five of six tools use a consistent `brute_genius_` prefix with readable action/resource suffixes. `xpu_probe` is the only outlier and follows a different prefixing convention, which is a minor deviation rather than a systemic inconsistency.
Six tools is well-scoped for a brute-force planning, execution, monitoring, and retrieval server. Each tool maps to a distinct phase of the workflow and there is no obvious bloat.
The tool set covers the full lifecycle: hardware probing, combinatorial planning with cost guards, launch/execution, live status, termination, and results retrieval. There are no obvious missing operations for the stated brute-force scoring domain.