How do I use Simulatte MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Simulatte MCP Server Test this sleep coaching concept on 50 stressed parents." 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.

Simulatte MCP Server

by Iqbalahmed7

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Simulatte MCP Server

Run any of Simulatte's 26 SKUs from Claude, Cursor, Zed, or any MCP-compatible AI client. Get results back as structured JSON. No new UI to learn.

User: "Test this sleep coaching concept on 50 stressed parents."
Claude: [calls simulatte_estimate_cost] → 150 credits (~$1.80). Approve?
User: "yes"
Claude: [calls simulatte_run_study] → Results in 4 minutes.

Installation

One-off (no install):

SIMULATTE_API_KEY=sim_live_your_key npx @simulatte-io/mcp-server

Global install:

npm install -g @simulatte-io/mcp-server
SIMULATTE_API_KEY=sim_live_your_key simulatte-mcp

Related MCP server: Stack AI MCP Server

Get an API key

Go to app.simulatte.io/settings/api-keys
Create a key — starts with sim_live_
Set it as SIMULATTE_API_KEY in your environment or MCP client config

Claude Desktop setup

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "simulatte": {
      "command": "npx",
      "args": ["-y", "@simulatte-io/mcp-server"],
      "env": {
        "SIMULATTE_API_KEY": "sim_live_your_key_here"
      }
    }
  }
}

Restart Claude Desktop. Simulatte tools appear automatically.

Cursor setup

Edit ~/.cursor/mcp.json (or your project's .cursor/mcp.json):

{
  "mcpServers": {
    "simulatte": {
      "command": "npx",
      "args": ["-y", "@simulatte-io/mcp-server"],
      "env": {
        "SIMULATTE_API_KEY": "sim_live_your_key_here"
      }
    }
  }
}

Zed setup

In ~/.config/zed/settings.json, add:

{
  "context_servers": {
    "simulatte": {
      "command": {
        "path": "npx",
        "args": ["-y", "@simulatte-io/mcp-server"],
        "env": {
          "SIMULATTE_API_KEY": "sim_live_your_key_here"
        }
      }
    }
  }
}

Available tools

Tool	What it does
`simulatte_run_study`	Run any of 26 research SKUs — concept testing, pricing, messaging, B2B committee, and more
`simulatte_get_results`	Retrieve full structured results for a completed study
`simulatte_ask_insights`	Ask a natural-language question across your entire study history
`simulatte_list_pools`	List all synthetic persona pools in your workspace
`simulatte_create_pool`	Create a new persona pool with custom demographic/psychographic specs
`simulatte_depth_interview`	Run a multi-turn simulated depth interview with a synthetic persona
`simulatte_estimate_cost`	Get a credit + USD cost estimate before running a study (local — no API call)

SKUs supported by `simulatte_run_study`

concept-viability · claim-credibility · brand-identity-test · message-resonance · price-sensitivity · feature-priority · ad-copy · b2b-committee · conjoint · iris-pulse · card-sort · open-end · ab-backlog · polarization-stress-test · name-test · founder-positioning · ad-concept-resonance · depth-interview · custom-study · iat · counterfactual-positioning · personalization-sensitivity · regulated-claim-preflight · volume-forecast · brand-tracker · creative-audit

Example prompts

Concept test:

"I have a new sleep coaching app concept. Test it on 50 stressed parent personas and tell me if it'll land."

Pricing sensitivity:

"Run a price sensitivity study on my premium plan ($99/mo) against 100 millennial professionals. Use pool_abc123."

Cross-study synthesis:

"What are the most common objections across all of our B2B studies this quarter?"

Depth interview:

"Conduct a depth interview with a skeptical 35-year-old UK parent about our onboarding flow. 15 turns."

Authentication

Preferred: per-customer API key

Send your sim_live_* key in either of these headers — both are accepted:

x-api-key: sim_live_your_key_here
# or
Authorization: Bearer sim_live_your_key_here

Deprecated: shared platform key

The shared key forge-prod-2026 (used in internal integrations before v0.4) is deprecated and will be removed at v0.5. If your integration sends x-api-key: forge-prod-2026, migrate to a sim_live_* per-customer key now. The worker logs a deprecation warning on every request that uses the shared key.

Response headers

Every successful /v1/forge/* and /v1/iris/* response includes these headers:

Header	Description
`X-Simulatte-Credits-Used`	Credits charged for this request
`X-Simulatte-Credits-Remaining`	Workspace credit balance after this charge
`X-Simulatte-Spend-Warning`	Present only when your key has consumed ≥ 80% of its spend cap. Value: `"85%-of-cap-consumed"` (percentage varies).

Sample curl showing all headers

curl -X POST https://forge-worker-production.up.railway.app/v1/forge/concept-viability \
  -H "x-api-key: sim_live_your_key" \
  -H "x-workspace-id: your-workspace-uuid" \
  -H "Content-Type: application/json" \
  -d '{"concept":"A sleep app for stressed parents","population_id":"default","sample_size":20}' \
  -i

Expected response headers (2xx):

HTTP/2 201
x-simulatte-credits-used: 28
x-simulatte-credits-remaining: 472

If your key is at 85% of its spend cap:

x-simulatte-spend-warning: 85%-of-cap-consumed

Error reference

Status	`error` field	Meaning
`401`	`invalid_api_key`	Key not found, revoked, or expired
`401`	(message)	Bearer JWT invalid or expired
`402`	`key_spend_cap_exceeded`	Key has a spend cap and this request would exceed it. Body: `{"error":"key_spend_cap_exceeded","cap":500,"used":498,"would_charge":10}`
`429`	`rate_limited`	60 req/min or 1000 req/hr limit hit. Check `Retry-After` header
`503`	`database_unavailable`	Worker DB not reachable — retry in 30s

Sample error bodies

402 — spend cap exceeded:

{
  "detail": {
    "error": "key_spend_cap_exceeded",
    "cap": 500,
    "used": 498,
    "would_charge": 10
  }
}

429 — rate limited:

{
  "detail": {
    "error": "rate_limited",
    "limit": "60/min",
    "retry_after_seconds": 42
  }
}

Retry-After: 42 header is also present.

Rate limits and quotas

Rate limits and credit caps are enforced per API key:

Default limit	Value
Per-minute	60 req/min
Per-hour	1,000 req/hr

Spend caps are optional, set per-key by workspace admins. A key with no spend cap has unlimited spend (bounded only by workspace credit balance).

See app.simulatte.io/settings/billing for your current usage.

Troubleshooting

"Missing SIMULATTE_API_KEY" — Make sure the env block in your MCP config contains your key. The key must start with sim_live_.

Tool not appearing in Claude Desktop — Restart Claude Desktop after editing claude_desktop_config.json. Check the MCP logs at ~/Library/Logs/Claude/mcp*.log.

simulatte_get_results returns status: "running" — Studies take 2–8 minutes. Poll again in 30 seconds, or ask Claude to wait and retry.

401 Unauthorized — Your API key may be revoked or incorrect. Generate a new one at app.simulatte.io/settings/api-keys.

429 Too Many Requests — You've hit the rate limit for your tier. Upgrade at app.simulatte.io/settings/billing.

Development

git clone https://github.com/Iqbalahmed7/simulatte-mcp-server
cd simulatte-mcp-server
npm install
npm run build    # compiles TypeScript → dist/
npm test         # runs vitest test suite
npm run dev      # runs directly via tsx (no build step)

License

MIT — see LICENSE.

Available Tools

7 tools

simulatte_ask_insightsA

Ask a question across your entire Simulatte research history using semantic search. Returns a cited answer with themes and source study references. Great for synthesizing findings across multiple studies.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Natural-language question to ask across your Simulatte study history (e.g. 'What do skeptical parents think about sleep coaching?')
`top_k`	No	Number of studies to draw citations from (default: 5)

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only describes the output and does not mention any side effects, permissions, or potential issues like rate limits, leaving significant gaps for a tool that likely performs a query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two clear sentences, front-loading the main action and output without any unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description adequately explains the return type (cited answer with themes and sources). The parameter count is low and schema coverage complete, but potential error conditions or limitations are not mentioned, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described. The description adds a helpful example for 'query' but does not significantly extend the schema's documentation, earning a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Ask a question across your entire Simulatte research history'), the method ('semantic search'), and the output ('cited answer with themes and source study references'), effectively distinguishing it from sibling tools like simulatte_get_results.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage context ('Great for synthesizing findings across multiple studies') but lacks explicit guidance on when not to use or alternatives among the sibling tools, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_create_poolA

Create a new synthetic persona pool with a custom demographic and psychographic specification. Returns a pool_id you can reuse across multiple studies.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Human-readable name for this persona pool
`market`	Yes	Target market descriptor (e.g. 'US millennial parents', 'UK SMB decision-makers')
`size`	Yes	Number of synthetic personas to generate in this pool
`pool_spec`	Yes	Demographic and psychographic specification for the pool (age, income, lifestyle, attitudes, etc.)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions creation and return of a pool_id, but omits side effects (e.g., duplication handling) and permissions. It is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words; front-loaded with the action and key output. Efficient and direct.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the return value (pool_id) clearly, addressing the lack of output schema. It could mention error conditions or duplication behavior, but for a creation tool it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all parameters described. The description adds context 'custom demographic and psychographic specification' for pool_spec, but this is redundant with schema. Baseline score 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and the resource 'synthetic persona pool', specifying it returns a 'pool_id' for reuse, distinguishing it from sibling tools like 'simulatte_list_pools' and 'simulatte_run_study'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the return value and reuse, indicating when to use (before running studies), but lacks explicit exclusions or alternatives. It provides clear context without stating when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_depth_interviewA

Run a simulated depth interview with a synthetic persona. The persona responds in character across multiple turns, surfacing motivations, objections, and language naturally. Returns interview_id and a credits estimate.

ParametersJSON Schema

Name	Required	Description
`persona_id`	No	ID of a specific synthetic persona to interview
`persona_pool_id`	No	ID of a persona pool to draw a random participant from
`goal`	Yes	Research goal for the interview (e.g. 'Understand barriers to adoption for a sleep coaching app')
`product_context`	Yes	Description of the product or concept being explored in the interview
`max_turns`	No	Maximum number of interview turns (default: 12)

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses only that it returns interview_id and credits estimate, but lacks detail on statefulness, authentication, rate limits, or boundaries of the simulation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose. Every word adds value; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output schema, but description explains return values. Given the simulation context (no side effects, limited complexity), the description provides sufficient context for an AI agent to understand what the tool does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema descriptions for parameters like persona_id, goal, etc.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource: 'Run a simulated depth interview with a synthetic persona.' Distinguishes from siblings like simulatte_ask_insights or simulatte_run_study by specifying depth interview behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage through description of surfacing motivations and objections, but no explicit when-to-use or when-not-to-use guidance compared to sibling tools. Alternatives like simulatte_run_study not mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_estimate_costA

Estimate the credit cost and USD price for a Simulatte study before running it. Calculated locally — no API call needed. Credits = base_cost_per_persona × sample_size.

ParametersJSON Schema

Name	Required	Description
`sku`	Yes
`sample_size`	No	Number of personas (default: 50)
`max_turns`	No	Interview turns — only relevant for depth-interview SKU

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It reveals local calculation ('no API call needed') and provides the cost formula, but does not disclose error handling or parameter validation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, concise and front-loaded. Every sentence adds value: estimation purpose, local calculation, and formula.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains what is estimated (credits and USD) and the formula. It could mention return format, but for a simple estimation with no side effects, it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers parameter descriptions for all three params (67% coverage). The description adds the cost formula but no new semantic information for sku or max_turns beyond schema defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool estimates credit cost and USD price for a Simulatte study before running it, distinguishing it from sibling tools like simulatte_run_study. The verb 'estimate' and resource 'cost/price' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use ('before running it') and notes it requires no API call. However, it lacks explicit guidance on when not to use or alternatives to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_get_resultsA

Retrieve results for a completed Simulatte study. Returns full structured results JSON including verdicts, key drivers, objections, persona breakdowns, and Forge Loop recommendations.

ParametersJSON Schema

Name	Required	Description	Default
`study_id`	Yes	Study ID returned from simulatte_run_study

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It lists the contents of the returned JSON (verdicts, key drivers, objections, etc.), but does not mention operational aspects such as read-only nature, latency, error handling for missing or incomplete studies, or any side effects. The description is adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences. The first sentence states the core purpose, and the second enumerates the key data returned. Every word earns its place; no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the main use case and return format. However, it lacks a mention of the prerequisite relationship with simulatte_run_study (i.e., that the study must be run first and completed). Slight improvement would include that linkage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, study_id, is described in the schema as 'Study ID returned from simulatte_run_study'. The description in the tool description repeats exactly that, adding no new semantics beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving results for a completed Simulatte study. It specifies the verb 'Retrieve results' and the resource 'completed Simulatte study', and lists the contents of the returned JSON. This effectively differentiates it from sibling tools like simulatte_run_study (which starts a study) and simulatte_ask_insights (which likely provides interactive insights).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use after study completion by saying 'for a completed Simulatte study', but it does not explicitly state the prerequisite of having run simulatte_run_study first or warn against using it on incomplete studies. No alternatives or when-not-to-use guidance is provided, leaving some ambiguity about proper sequence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_list_poolsA

List all persona pools in your Simulatte workspace. Returns pool IDs, names, markets, and sizes. Use pool IDs in simulatte_run_study to target a specific audience segment.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Only lists output fields; no mention of side effects, permissions, or read-only nature. Minimal behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two front-loaded sentences with no wasted words. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, description fully covers what the tool does and how to use its output. Complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 params, schema coverage 100%), so baseline is 4. Description adds no parameter semantics because none are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list), resource (persona pools), and return fields (IDs, names, markets, sizes). It also differentiates from siblings by mentioning use of pool IDs in simulatte_run_study.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (to list pools) and provides guidance on using output in simulatte_run_study. Lacks explicit alternatives or when-not scenarios, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

simulatte_run_studyB

Run a Simulatte synthetic research study. Choose from 26 SKUs covering concept testing, pricing, messaging, B2B committee simulation, depth interviews, and more. Returns a study_id you can poll with simulatte_get_results.

ParametersJSON Schema

Name	Required	Description
`sku`	Yes
`inputs`	Yes	SKU-specific study inputs
`persona_pool_id`	No	ID of persona pool to use
`sample_size`	No	Number of synthetic personas to run (default varies by SKU)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry the full burden. It hints at asynchronous behavior by mentioning 'poll', but does not disclose whether the operation is destructive, requires authentication, has rate limits, or how inputs are validated. The description is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the action and resource, and includes a concrete follow-up action (poll with simulatte_get_results). There is no extraneous information; every sentence is purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and the complexity of nested inputs, the description provides basic context: it returns a study_id and directs polling. However, it omits details about error handling, required permissions, cost implications, and the dependency of inputs on the chosen SKU, leaving the agent partially informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75% (three of four params have schema descriptions). The description adds context for the sku param by listing example study types, but does not clarify the structure of 'inputs' beyond 'SKU-specific'. This provides marginal added value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool runs a Simulatte synthetic research study and returns a study_id, with examples of SKU categories. It distinguishes from siblings by mentioning simulatte_get_results for polling, but does not explicitly differentiate from other related tools like simulatte_estimate_cost.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by noting that the returned study_id can be polled with simulatte_get_results, providing a chaining hint. However, it lacks explicit guidance on when not to use this tool or clear alternatives like simulatte_estimate_cost for cost estimation before running.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose, covering different stages of the research workflow: setting up pools, running studies/interviews, getting results and insights, and estimating costs. No two tools have overlapping functionality.

Naming Consistency5/5

All tools consistently use the 'simulatte_' prefix followed by a verb_noun pattern (e.g., create_pool, get_results), making names predictable and easy to understand.

Tool Count5/5

With 7 tools, the set is well-scoped for the server's purpose of synthetic research. Each tool addresses a necessary step without being excessive or insufficient.

Completeness4/5

The tools cover the core lifecycle—create pools, run studies, get results, ask insights, estimate costs. A minor gap is the lack of deletion or cancellation tools, but the essential workflows are complete.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

IFTTT MCP server
com.ifttt
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
App Automation
1
futureagievals-mcp
com.clauxel.futureagievals
A paid remote MCP for AI SDK eval dashboard, built to return verdicts, receipts, usage logs, and aud
Testing & QA Tools Monitoring AI & Machine Learning
2
coralquery-mcp
com.clauxel.coralquery
A paid remote MCP for AI SDK data query MCP, built to return verdicts, receipts, usage logs, and aud
Observability AI & Machine Learning Payments & Billing
2
Algenta MCP Server C
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402

Related MCP Servers

mcp-subconscios
Workplace & Productivity
Subconscious-ai
F
license
Not graded
quality
C
maintenance
Run conjoint experiments and causal research through AI powered behavioral simulations
Updated a month ago (2026-07-28 20:54 UTC)
5
Stack AI MCP Serverofficial
RAG Systems Agent Orchestration App Automation
stackai
F
license
Not graded
quality
Not graded
maintenance
Enables users to connect and run Stack AI workflows directly through MCP-compatible clients. It allows for passing user inputs to specific projects and receiving structured responses from deployed AI applications.
Updated 8 months ago (2026-01-07 16:23 UTC)
1
Patronus MCP Serverofficial
AI & Machine Learning Testing & QA Tools
patronus-ai
A
license
Not graded
quality
D
maintenance
Enables running LLM evaluations, experiments, and custom evaluators through a standardized MCP interface.
Updated a year ago (2025-03-26 12:33 UTC)
16
Apache 2.0
Coral Query Plane
Databases Data Platforms
clauxel
F
license
Not graded
quality
D
maintenance
Paid remote MCP endpoint for AI SDK data queries, offering structured JSON tools, token-based access, usage receipts, and audit-ready workflow evidence.
Updated 3 months ago (2026-05-25 09:14 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Iqbalahmed7/simulatte-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Simulatte MCP Server

Installation

Get an API key

Claude Desktop setup

Cursor setup

Zed setup

Available tools

SKUs supported by simulatte_run_study

Example prompts

Authentication

Preferred: per-customer API key

Deprecated: shared platform key

Response headers

Sample curl showing all headers

Error reference

Sample error bodies

Rate limits and quotas

Troubleshooting

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Stack AI MCP Serverofficial

Patronus MCP Serverofficial

Latest Blog Posts

MCP directory API

SKUs supported by `simulatte_run_study`