Loading ToolBench
MCP server for Ashlr Stack. Exposes 19 tools and 3 resources so Claude Code / Cursor / Windsurf / Codex can provision every third-party service in a project with one call.
Server exposes 19 tools with consistent naming (stack_* prefix) and documented schemas in mcp.json. Descriptions are present but brief (avg ~80 chars, below 194-char baseline). All tools have input schemas with type definitions and parameter descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is absent; no recovery guidance or categorization. Security concerns: tools like stack_add, stack_remove, stack_sync perform destructive/sensitive operations without explicit permission gates or dry-run patterns. Composition is strong (each tool has one responsibility), but missing idempotency guarantees and confirmation patterns for irreversible ops.
Provision a service and wire its secrets + MCP entry.
Apply a saved Recipe: replay `stack add` for each provider, then pre-wire Phantom rotation envelopes + webhook stubs. Set `no_wire: true` to opt out of the Phantom-wire layer (stays pure-provisioning).
Show the service dependency graph for the current stack.
Verify every service is reachable and credentials are valid.
Report which declared secrets are missing from the Phantom vault.
Show which declared secrets are present in the Phantom vault (masked).
Output schemas not documented. LLMs cannot predict response structure for any tool. Breaks downstream tool chaining and forces agents to guess field names.
No error handling or recovery guidance. Tools like stack_remove (DESTRUCTIVE) and stack_sync (WRITE) provide no error categorization, actionable messages, or retry logic. Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Import an existing .env file into Phantom + .stack.toml.
Deep-dive on a single service: resource, region, auth, secrets, MCP wiring, health.
Scaffold a new .stack.toml in the current directory.
List services configured in this stack.
List every Stack-enabled project on this machine.
List every curated provider Stack can wire up (grouped by category).
Given a free-text description of what the user is building (e.g. 'B2B SaaS with auth, AI, and payments'), return a structured list of the most relevant curated providers with scores, matched terms, and per-category ranking. Pass save:true to also persist a Recipe to .stack/recipes/<id>.toml so you (Claude) can follow up with stack_apply. Retrieval-only — no LLM inference happens here.
Remove a service from the stack (vault entries and MCP config).
Detect providers this repo uses by reading package.json / requirements.txt / config files.
Show Phantom + services + config at a glance.
Push secrets to a deployment platform (via `phantom sync`).
List available starter stack templates.
Check npm for a newer @ashlr/stack release.
Destructive operations lack confirmation/dry-run patterns. stack_remove and stack_sync can cause data loss without agent confirmation. No idempotency guarantees documented.
Brief descriptions (avg ~80 chars, below 194-char baseline). Many tools lack context on WHEN to use them vs similar tools. E.g., stack_status vs stack_info distinction unclear.
No permission gates or scope declarations. Sensitive tools (stack_add, stack_remove, stack_sync) lack access control checks. No audit trail or logging of who called what.