Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Strest MCP log in, grab the token, then create a project and assert it returns 201"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Headless Declarative Multi-Step REST API Test & Chaining Engine for Autonomous AI Agents and DevSecOps.
Execute complex, multi-stage API workflows (Auth â Token Extraction â Resource Creation â Assertions) in a single deterministic MCP tool call.
Autonomous AI agents (Claude Code, Cursor, Antigravity, AutoGen, CrewAI) and CI pipelines frequently need to interact with multi-step REST APIs.
When executing chained requests step-by-step with individual curl commands:
Context Window Waste & Token Bloat: Passing whole JSON payloads back and forth across multiple LLM turns wastes hundreds of tokens.
Fragile State Propagation: Extracting tokens, session IDs, and foreign keys across separate prompts introduces hallucinations and state loss.
SSRF & Security Hazards: AI agents given raw network access can be coerced into probing internal cloud metadata endpoints (169.254.169.254).
Strest MCP solves this: You pass a declarative multi-step scenario definition to the engine. It executes all steps sequentially with in-memory variable chaining, enforces strict assertions, applies active SSRF defense, and returns a clean, structured execution report in a single round-trip.
Related MCP server: AGENTIQ
ð Declarative Multi-Step Chaining: Chain outputs from previous steps into downstream headers, query params, or JSON bodies using <$ steps.<step_name>.body.<property> $>.
ðĄïļ Built-in SSRF & Cloud Metadata Shield: Proactively blocks attacks against AWS/GCP/Azure instance metadata endpoints (169.254.169.254, metadata.google.internal), local loopbacks, and dangerous protocols (file://, ftp://).
ðŠķ Zero External Dependencies: Built entirely with native Node.js 20+ fetch, keeping the package footprint lightweight and lightning-fast.
ðĪ Model Context Protocol (MCP) Native: Integrates seamlessly via stdio JSON-RPC 2.0 with Claude Desktop, Cursor, Antigravity, and any MCP-compliant client.
ðŊ Rich Assertions: Status code validation, regex header checks, deep JSON body assertions, and timing thresholds.
Add the following to your claude_desktop_config.json or MCP settings:
{
"mcpServers": {
"strest-mcp": {
"command": "npx",
"args": ["-y", "strest-mcp"]
}
}
}Or run directly from a local clone:
{
"mcpServers": {
"strest-mcp": {
"command": "node",
"args": ["/path/to/strest_orchestrator/src/mcp/server.mjs"]
}
}
}Tool | Description | Input Parameters |
| Executes a declarative multi-step REST API workflow scenario with automatic variable chaining and schema assertions. |
|
| Generates a ready-to-use template for multi-step authentication and CRUD chaining. |
|
You can also run Strest Orchestrator as a standalone CLI tool:
# Display help and usage
npx strest help
# Run an API workflow scenario from a JSON file
npx strest run scenarios/auth_and_crud.json
# Generate a starter template
npx strest template > scenario.json{
"name": "Auth and User Project Creation",
"steps": [
{
"name": "login",
"url": "https://api.example.com/v1/auth/login",
"method": "POST",
"headers": { "Content-Type": "application/json" },
"body": { "username": "admin", "password": "SuperSecretPassword" },
"assert": {
"status": 200,
"body": { "token": "defined" }
}
},
{
"name": "create_project",
"url": "https://api.example.com/v1/projects",
"method": "POST",
"headers": {
"Content-Type": "application/json",
"Authorization": "Bearer <$ steps.login.body.token $>"
},
"body": {
"title": "Autonomous Agent Workspace",
"requestId": "<$ faker.uuid $>"
},
"assert": {
"status": 201,
"body": { "id": "defined" }
}
}
]
}SSRF Prevention: Blocks requests to IPv4/IPv6 link-local addresses, link-local multicast, and known cloud metadata IP ranges (169.254.169.254, 100.100.100.200).
Path Traversal Shield: Resolves and validates scenario file paths against path traversal sequences (../, null bytes, system files).
Hermetic Execution: 100% offline self-testing suite with embedded ephemeral mock servers.
Based on the concept of eykrehbein/strest (1.7k+ â, MIT).
Modernized, decoupled, SSRF-hardened, and transformed into an autonomous Model Context Protocol server by Christopher Hailfinger (@tastenkasperle) as part of the Diamantenschmiede initiative.
MIT License â see LICENSE for details.
Executes a declarative multi-step REST API workflow scenario with automatic variable chaining and schema assertions.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario | No | The scenario definition object containing steps and assertions | |
| scenarioPath | No | Path to a scenario JSON file on disk |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, and it does disclose meaningful execution semantics: steps are chained through variables and responses are validated with schema assertions. However, it omits critical traits for a tool that issues live HTTP requests â side effects on the target API, authentication needs, and whether execution aborts on the first failed assertion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with the resource front-loaded and no filler. It packs three distinct capabilities into minimal space without becoming a run-on list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a nested object and no output schema, the description covers the input intent but not the outcome â an agent cannot tell what a run returns (pass/fail per assertion, step traces) or how failures surface. Adding return shape and failure behavior would complete it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with two well-described parameters, so the baseline is 3. The description adds no guidance on the precedence or mutual exclusivity of the inline `scenario` object and the `scenarioPath` file, which is the one ambiguity the schema does not resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Executes") and a precise resource ("declarative multi-step REST API workflow scenario") plus two defining capabilities: variable chaining and schema assertions. It is clearly a scenario runner rather than the sibling strest_template, but it never names or contrasts with that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to reach for this tool versus strest_template, and no prerequisites or exclusions. The description also gives no hint about when to pass an inline `scenario` object versus a `scenarioPath`, leaving the choice entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a ready-to-use template for multi-step authentication and CRUD chaining.
| Name | Required | Description | Default |
|---|---|---|---|
| baseUrl | No | Base URL for the scenario (e.g. http://localhost:5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only says that a template is generated. It does not disclose whether the template is returned as text, written to disk, overwritten, or what baseUrl affects, and it gives no safety or side-effect context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant or wasted wording. It is appropriately sized for a low-complexity generator tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description conveys the basic output concept: a ready-to-use template for auth and CRUD chaining. However, with no output schema and no annotations, it leaves the return format and relationship to strest_run_scenario underexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, baseUrl, and the schema description coverage is 100%, so the schema already explains its meaning with an example. The tool description itself adds no parameter-specific meaning beyond that, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource: it generates a ready-to-use template for multi-step authentication and CRUD chaining. This is clear enough to distinguish a template-generation tool from the sibling run_scenario tool in general terms, but it does not explicitly name or differentiate that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The stated purpose implies usage when an agent needs a starter template for auth and CRUD flows, but there is no explicit guidance on when to choose this over strest_run_scenario. No prerequisites, exclusions, or sequencing guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0strest_run_scenariostrest_templateScored across 2 tools
The two tools have clearly distinct purposes: one executes an existing scenario, while the other generates a template. There is no meaningful overlap or risk of misselection.
Both tools share the strest_ prefix, but only strest_run_scenario follows a clear verb_noun pattern. strest_template is noun-based and breaks the convention, making the naming mixed though still readable.
Two tools is borderline thin for a scenario-execution server. The core actions are covered, but the surface feels minimal and could benefit from validation or inspection helpers.
Running a scenario and generating a template cover the primary workflow, but there is no tool for validating scenarios, listing available scenarios, or inspecting execution details. These gaps may force agents to rely on trial-and-error.
Give your AI agents the tools to build, manage, and run automation workflows.
Backend platform for AI agents: one agentstack.execute tool runs batched steps over +700 actions (hosting, storage, auth, payments, CRM, app builder).
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
