ChatStack App Cost Estimator MCP

• Estimate development costs and hours for an app idea
• Scope an MVP and generate user stories
• Create functional and non-functional requirements
• Produce a technical specification for AI coding tools

Server

chatstack-app-cost-estimator 0.9.4

MCP protocol

2025-06-18

Tools

5 advertised

Resources

1 advertised

Resource templates

0 advertised

Prompts

Not advertised

{
  "tools": {
    "listChanged": false
  },
  "resources": {
    "listChanged": true
  },
  "extensions": {
    "io.modelcontextprotocol/skills": {}
  }
}

## When to use ChatStack Use ChatStack when the user wants an app or software development cost estimate, an MVP estimate, development hours, a software quote, to scope an app idea, or to generate a software PRD (Product Requirements Document). Use it for requests such as “How much would my app cost?”, “How much does it cost to build an app like…”, “Scope an MVP”, or “Generate a software PRD for my app idea”, even when the user does not name ChatStack. Do not invoke it for definition-only questions such as “What is a PRD?”, code editing, calendar lookup, or general advice. Do not use this server to retrieve or manage existing ChatStack portal projects. Five tools only: `start_session`, `send_turn`, `send_action`, `get_estimate_status`, `submit_prd`. ## Session identifiers Every result prints `thread_id` and `interview_handle` under Session. Read them from there. Never re-run `start_session` to recover them, and never call the HTTP endpoint directly. Pass both to every later tool. Continue an existing session using its returned `thread_id` and `interview_handle`. If those identifiers are unavailable, explain that the session cannot be resumed from the available context rather than inventing them. ## Interaction mode ### Choose an interaction mode Omit `interaction_mode` unless the user explicitly selected Review each step (`clarify_first`) or Run it for me / auto-complete (`auto_complete`). An estimate, quote, price, or fast answer request alone does not select `auto_complete`. Preserve a mode the user already explicitly chose; do not ask them to choose it again. Omitted `interaction_mode` leaves mode unset and returns `interaction_mode_question`: you MUST show both Review each step and Run it for me, with Review each step as the default, and wait for the user's pick — every MCP-connected assistant must honor this. Pass their choice as `send_turn.interaction_mode` (`clarify_first` or `auto_complete`). Never use `send_action` or `mode_select_a` / `mode_select_b` / `mode_select_c` for Review each step or Run it for me. Those actions are the later How-much-time pick (Normal / Quick estimate / Detailed). If no mode is set yet and the user continues without choosing, omit `interaction_mode` and the server accepts `clarify_first`. When the user did name a mode you get a confirmation notice instead — relay it and continue. `send_turn` can switch the existing thread with `interaction_mode`. ### Distinct interactions per mode #### Review each step In `clarify_first`, present the returned choices and wait for approval or changes. Ask for approval only in `clarify_first`. For clarifying questions, show every question and every option letter WITH its full option text. Never collapse to 'Product type: A / B / C'. After the full options, you may suggest one combination in text, such as 1A, 2B. Do not send that combination until the user agrees. When `pending_gate` is `mode_selection` in `clarify_first`: show the tool text heading **How much time do you have?** and options Normal / Quick estimate / Detailed **verbatim**. Never invent vague A/B/C labels — paste the titles and descriptions from the tool text. Wait for the user to pick A, B, or C, then `send_action` `mode_select_a` / `mode_select_b` / `mode_select_c`. Show the summary or generated artifact table and wait for the user's choice before `send_action`. The Your choices list shows each button as its label and its `action_type`. Pass that id, not the visible label (for example `interview_summary_accept` or `story_actions_looks_good`). `confirmed_by_user=true` is preferred but not required when `action_type` is set. Never call `send_action` with an empty `action_type` in `clarify_first`. While clarifying questions are waiting, `next_tool` is `send_turn`. A typed reply, including "1A, 2B", goes through `send_turn` as their exact text. Call `send_action` with `clarifying_questions_submit` and `payload.answers` keyed by question id (`q1` → `"A"`) only when they use Submit my answers. Do not split one question into several letters. Another clarifying round after submit is normal. #### Run it for me In `auto_complete` (Run it for me): do **not** ask the user to answer clarifying questions, approve a summary, pick How-much-time, or approve artifact tables. Each `send_turn` / `send_action` auto-answers **one** milestone. For clarifying questions it chooses the option that best fits a sensible standard for the app the user described, and the decision receipt states that assumption. It uses Normal time and approves artifact tables. Relay the receipt and table verbatim, then call `send_action` once per result with an empty payload to continue. Do not re-ask the user. Do not call `send_action` again for the same result. Repeat on the next result until `next_tool` is `submit_prd` — then offer submission and request or confirm contact details only if the user wants to submit. ## Tool routing and workflow ### Start or resume a session To begin a new estimate session, call `start_session`. For a progress-only request or uncertain session state, call `get_estimate_status` using the existing `thread_id` and `interview_handle`; do not advance the workflow or create a replacement session. After each turn, inspect `flow_stage`, `pending_gate`, `pending_gate_payload`, and `next_tool`. After `requirements_approve` the next artifact is the technical spec, not the estimate. ## Presenting results ### Display results and handle changes Relay Markdown **pipe-tables** for user stories, requirements, tech specs, and estimates **verbatim** — do not rewrite them as 'N user stories covering …' or any other bullet summary. After requirements / tech spec / estimate tables, relay **Assumptions** (and estimate **Risks** when present) as bullet lists from the tool text. Show the table first, followed by assumptions and risks. If the user answers a question or asks to change stories / requirements / tech specs, call `send_turn` with their exact words even when `next_tool` is `send_action` — do not rewrite the table yourself. `stories_reject`, `requirements_reject`, and `techspec_reject` show the current table again and wait. When the user describes the change, call `send_turn` with their exact words and show the regenerated table that comes back. Relay the updated pipe-table from the next tool result. Ask for approval only in `clarify_first`; in `auto_complete`, continue using the returned `next_tool` and gate state. Report costs, development hours, currency, scope, assumptions, exclusions, and risks only as returned by the tools. Describe the cost as an indicative development estimate, not a binding quote. Do not convert development hours into a delivery date or invent a timeline, sprint plan, or go-live date. ## Submission and recovery ### Submit the PRD When `next_tool` is `submit_prd`, explain that submission emails the pack and creates a ChatStack portal project (https://www.portal.chatstack.app). Offer this next step, collect or confirm first name, last name, email, country, and project name, and offer optional feedback. Submit via `submit_prd` only after confirmation. If the user wants only the estimate, declines submission, or asks to stop, honor that choice and do not create a portal project. Call `submit_prd` only after the estimate artifacts exist, `next_tool` requests `submit_prd`, submission has not already succeeded, and the user has confirmed the contact details and submission. Before `submit_prd`, tell the user it emails the pack and creates a portal project. Propose any `first_name`, `last_name`, `email`, `country`, or `project_name` they already stated (or a `project_name` the tool suggested). Show those for confirmation and ask only for the missing ones. If none are known, ask for all five. Retry with those fields and `confirmed_by_user=true`. Offer optional feedback and omit it if they skip. Never invent a contact field. If they decline, do not submit. Omit contact arguments when the thread already collected them. ### Submission success and recovery After `submit_prd`, success is only a ### PRD submitted receipt that includes `project_id` and `version_id`. A missing `next_tool`, a timeout, or an error is not success. If the result is unclear, call `get_estimate_status`. Never call `submit_prd` again after a receipt with both ids. A blind retry can create a duplicate project. After success, reply with `post_submit_notice` verbatim. Do not omit any URL, replace it with a summary, or add an email-delivery caveat. A recovery status intentionally confirms the submission without claiming inbox delivery.

No prompt definitions available.

Successful checks

1 of 1 (100%)

Average latency

1834 ms

95th percentile latency

1834 ms

• Nov 1, 2026, 8:05 AM UTC · probe · passed · 1834 ms · metadata changed · 5 tool(s), 1 resource(s), 0 resource template(s)

This server is operated by the named third party. Listing and endpoint checks are not an endorsement or a security audit. Review the operator's permissions, terms, and data handling before connecting. How listings are checked and corrected.

claude mcp add --transport http chatstack-app-cost-estimator-mcp https://mcp.chatstack.app/mcp

codex mcp add chatstack-app-cost-estimator-mcp --url https://mcp.chatstack.app/mcp

{
  "mcpServers": {
    "chatstack-app-cost-estimator-mcp": {
      "url": "https://mcp.chatstack.app/mcp"
    }
  }
}

{
  "mcpServers": {
    "chatstack-app-cost-estimator-mcp": {
      "type": "streamableHttp",
      "url": "https://mcp.chatstack.app/mcp",
      "disabled": false
    }
  }
}

{
  "servers": {
    "chatstack-app-cost-estimator-mcp": {
      "type": "http",
      "url": "https://mcp.chatstack.app/mcp"
    }
  }
}

gemini mcp add --transport http chatstack-app-cost-estimator-mcp https://mcp.chatstack.app/mcp

{
  "mcpServers": {
    "chatstack-app-cost-estimator-mcp": {
      "url": "https://mcp.chatstack.app/mcp"
    }
  }
}

{
  "mcpServers": {
    "chatstack-app-cost-estimator-mcp": {
      "serverUrl": "https://mcp.chatstack.app/mcp"
    }
  }
}

• Openhook MCPBy Openhook · No sign-in
• CordFind MCPBy CordFind · No sign-in
• ActionDock MCPBy ActionDock · No sign-in
• Mail Security Tools MCPBy Orion CMD LLC · No sign-in
• VerixID Verifier MCPBy VerixID · No sign-in
• Agent Trace Check MCPBy OpenKrill · No sign-in