step-engineer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STEP_API_KEY | No | Your Step API key for live optimization. Required for live MCP usage. | |
| STEP_BASE_URL | No | Base URL for the Step API. | https://api.stepfun.ai/v1 |
| STEPFUN_API_KEY | No | Fallback variable for the Step API key. Alternative to STEP_API_KEY. |
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 |
|---|---|
| submit_optimizationA | Start a Step API optimization job in an isolated copy. Requires an allowed source_dir, explicit files, correctness checks, benchmark, and budget. Returns promptly with a run_id; poll status. Sends selected code to StepFun and may incur API charges. Never changes the parent model or original source. |
| get_optimization_statusB | Read local job progress and estimated API cost. Poll at reasonable intervals. |
| get_optimization_resultA | Read measured results, final validation, and local patch/report paths. accepted=false means no changes are approved by the harness. Parent review is still required. |
| cancel_optimizationA | Cancel a local active job and its current check. A provider request already sent may still be billed. |
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 maps to a distinct phase of the optimization job lifecycle: submit starts, get_status polls, get_result retrieves final output, cancel aborts. No two tools share the same action or resource, so an agent can easily choose the right one.
All four tools use snake_case with a consistent verb_noun pattern (submit_optimization, get_optimization_status, get_optimization_result, cancel_optimization). The structure is predictable and unambiguous.
Four tools cover the essential async job lifecycle without redundancy. This is a well-scoped set for a focused optimization service.
The surface covers the full lifecycle: create, poll status, fetch results, and cancel. No obvious operation is missing for managing an optimization job, and the run_id-centric design avoids dead ends.