AgentStack (agentstack.tech)
Server Details
Backend for AI agents: one batched tool over ~668 actions (hosting, storage, auth, payments).
- Status
- Healthy
- Uptime
- 91.7% over 20 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- agentstacktech/AgentStack
- GitHub Stars
- 1
TDQS
Scored across 1 tool
There is only one tool, so cross-tool misselection is impossible, but the single tool is a mega-operation whose description glues together many distinct verbs (work_next, plan_claim, plan_execute, discovery.search, auth, CRM, upload) under one name. An agent cannot tell what 'execute' actually does on a given call, or which of the many referenced sub-actions are real versus runbook narration.
The lone name 'agentstack.execute' follows a namespaced verb convention and is readable, but with a single tool no pattern can be established or verified. The description itself mixes conventions (dotted namespaces like agents.work_next, snake_case like plan_claim, prose recipe names), which does not set a predictable precedent.
The advertised domain is a full work-graph control plane — auth/bootstrap, plans, claims, execution leases, catalog discovery, and domain actions like CRM/upload — and one opaque tool is far too thin a surface for that scope. It appears to be a deliberate gateway pattern, but the effect is that dozens of operations are hidden behind a single entry point with no schema-level visibility.
The description hints at broad coverage (plan lifecycle, discovery, auth, domain actions), but none of it is exposed as inspectable operations, so an agent cannot confirm CRUD/lifecycle coverage or recover from dead ends without following prose instructions. The surface as presented is a single entry point with an implicit, undiscoverable API behind it.
Available Tools
1 toolagentstack.executeAgentStack executeAInspect
AgentStack MCP = Work Graph control plane. After session + context.project_id: agents.work_next (mcp_work_loop_v1) -> plan_claim -> plan_execute (CAS/leases). Follow packet.next_action; catalog/discovery.search only if no packet. One-shot CRM/upload may call domain actions directly. Spine: agents.plan_get -> agents.work_next -> agents.plan_claim -> agents.plan_execute. Auth: Connect (G-A174) or Device Code, then auth.get_profile (bootstrap: include_settings false, include_subscriptions false; recipe mcp_session_setup), then context.project_id on every batch. Prompts: agentstack_session_setup, agentstack_execute_budget.
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Steps; one heavy LLM per sync execute. | |
| context | No | session.v1; project_id required. | |
| options | No | batch.v1 controls. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | No | False on total failure. |
| job_id | No | Poll id. |
| agent_os | No | Follow next_step. |
| recovery | No | Next action when blocked. |
| trace_id | No | Support trace. |
| error_code | No | Stable failure code. |
| execution_mode | No | async when queued. |
| partial_success | No | Some steps failed. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds required auth via Connect/Device Code, project_id on every batch, CAS/leases, and async polling. It does not contradict annotations and adds meaningful operational constraints, though it omits some mutation impact details.
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 compact but packed with internal jargon and repeated spine/agent sequences, and it does not front-load the tool's own purpose. Some auth/prompt details are useful context, but the structure is hard to parse.
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 complex nested batch executor with an output schema and annotations, it supplies auth prerequisites, project_id scoping, work-loop routing, and async behavior. Missing a plain-language statement of the tool's core action keeps it from full completeness.
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 description coverage is 100%, so the schema already documents steps/context/options. The description adds only limited semantic guidance (project_id required, sync vs async, packet usage), so baseline 3 is appropriate.
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 frames the tool as the AgentStack work-graph control plane and names related planning/execution calls, but it never directly states that agentstack.execute runs a batch of catalog actions. The purpose is inferable from the tool name and schema, yet the description itself remains jargon-heavy and indirect.
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?
It prescribes an explicit sequence after session/project_id and says to follow packet.next_action, with discovery.search only when no packet and direct domain actions for one-shot CRM/upload. Alternatives are named, though the routing remains terse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
agentstack.execute6 fields changed- removed
Input schema / properties / context / additionalPropertiesRemoved value: -true - removed
Input schema / properties / options / additionalPropertiesRemoved value: -true - removed
Input schema / properties / steps / items / properties / params / additionalPropertiesRemoved value: -true - removed
Output schema / additionalPropertiesRemoved value: -true - removed
Output schema / properties / agent_os / additionalPropertiesRemoved value: -true - removed
Output schema / properties / recovery / additionalPropertiesRemoved value: -true
Related MCP Connectors
The agent-native cloud: database, functions, AI, storage, computers. 51 tools, one API key.
Backend for AI-built apps: database, auth, files, email, AI, payments, deploy, realtime. 170+ tools.
Managed database, auth, file storage, email, analytics, and deployment for coding agents.
Production backend for AI-built apps: storage, data, jobs, webhooks, email, metering and billing.
Related MCP Servers
AlicenseNot gradedqualityCmaintenanceEnables AI agents to create and run a backend with database, auth, file storage, server-side functions, and a site, all without opening a browser.12 npmMIT- AlicenseNot gradedqualityCmaintenanceTurns coding agents into full-stack builders by enabling backend features like auth, databases, file storage, serverless functions, and LLMs to be added to apps in seconds.2 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to build and deploy an app from a GitHub repository to a managed live server and then operate it — logs, captured errors, health checks, managed Postgres, secrets, custom domains, email authentication, and Stripe checkout links. It also exposes safe, read/write-labelled tools so agents can rebuild, start/stop, and inspect projects without ever editing source code.MIT

scalix-cloud-mcpofficial
AlicenseNot gradedqualityCmaintenanceThe agent-native cloud: provision Postgres-compatible databases, deploy services and functions in isolated microVMs, manage storage, auth and AI inference, and read logs and billing — 50 tools behind one API key. Hosted remote server; this repository carries the connection docs.2MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.