MCP Simulator
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLAUDE_MODEL | No | Model name for Claude (e.g., claude-3-sonnet-20240229) | |
| ANTHROPIC_API_KEY | No | API key for Anthropic (used in agent chat) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_actionsA | STEP 1: Discover available ATOMIC actions by describing what you want to accomplish. Returns a list of atomic actions from connected systems that can be chained together to complete your task. ⚠️ CRITICAL: THE RETURNED ACTIONS ARE NOT TOOLS! They are action names that must be passed to execute_action. FOR THE ACTION WORKFLOW, USE THESE TWO TOOLS:
The actions returned from search_actions are NOT callable as tools. You MUST use execute_action to run them. ADDITIONAL AVAILABLE TOOLS: 3. get_world_time - get current world time 4. advance_world_time - travel forward in time to see future states Actions are ATOMIC and must be CHAINED:
This server is a universal gateway with connectivity to EVERYTHING: smart home devices, IoT systems, web APIs, cloud services, physical infrastructure, and more. Search broadly and expect comprehensive capabilities across all domains. EXAMPLE WORKFLOW 1 - Action chaining: User says: "Turn on the lights if it's raining at my location"
EXAMPLE WORKFLOW 2 - Time travel: User says: "Plant tomatoes and check how they're doing in 3 months"
NOTE: You have these MCP tools: search_actions, execute_action, get_world_time, advance_world_time. Do NOT try to call action names as if they were tools. |
| execute_actionA | STEP 2: Execute a discovered action on the connected system by its exact name. This is the ONLY way to actually run actions - actions are NOT tools themselves! ⚠️ CRITICAL: Actions discovered via search_actions are NOT tools. You cannot call them directly. You MUST use THIS tool (execute_action) to invoke them on their respective systems. REQUIRED WORKFLOW:
The action_name parameter MUST exactly match the "name" field from search_actions output. EXAMPLE - CORRECT: search_actions(query="weather") → returns action: "get_weather_for_location" execute_action(action_name="get_weather_for_location", parameters={"location": "NYC"}) → returns weather data EXAMPLE - WRONG (will fail): search_actions(query="weather") → returns action: "get_weather_for_location" get_weather_for_location(location="NYC") ← ERROR! This is not a tool! Remember: You have these MCP tools: search_actions, execute_action, get_world_time, advance_world_time. Action names are NOT tools. |
| get_world_timeA | Get the current world time. Returns the current date and time that the entire world is at. Use this to check what time period you're currently in. |
| advance_world_timeA | Travel forward in time by a specified duration. The entire world advances to the new time period, allowing you to see future states, outcomes, and changes across all systems. Use this when you want to observe long-term results (e.g., "check if plants survived after 2 weeks", "see home state after 6 months"). After advancing time, all subsequent action executions will operate in the new time period and reflect the accumulated changes that occurred. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct role: search_actions discovers available action names, execute_action runs them, and the two time tools separate reading the current world time from advancing it. The descriptions repeatedly reinforce the boundary between action names and tools, preventing selection confusion.
All tool names follow a consistent snake_case verb_noun pattern: search_actions, execute_action, get_world_time, advance_world_time. This makes the tool surface predictable and easy to reason about.
Four tools is a well-scoped count for this server's design. The dynamic action discovery and execution model keeps the MCP surface minimal while enabling broad functionality through chained actions, and each tool serves a necessary role.
The tool surface covers the full discovery-and-execution workflow for atomic actions, plus the time-state operations needed for simulation. There are no obvious dead ends: agents can search, execute, inspect the current time, and advance time to observe future states.