AgentMarketMCP / SKILL 资产档案馆

目录 / simceptor

MCP 鉴权未知 未评级 已上架

simceptor

Simceptor — AI-Native Mock API Server for Modern Development Teams Simceptor is a cloud-based mock API platform built from the ground up for AI-assisted development workflows. With 26 MCP tools, your AI coding assistant (Claude, Cursor, Windsurf, etc.) can create, configure, and manage your entire mock API layer — no dashboard clicking required. 🤖 Set Up Mock APIs Directly via MCP Simply tell your AI agent: "Create a POST /payments endpoint that returns a 200 success response." Simceptor's MCP integration handles the rest — from creating the endpoint to configuring response bodies, headers, and status codes, all in seconds through natural language. ⚡ Powerful Rule Engine Go beyond static mocks. Define conditional response rules based on request headers, body fields, query params, or path variables. Return different responses depending on the input — simulate edge cases, error states, and complex branching logic without writing a single line of server code. 🔄 Stateful API Simulation Simulate real-world stateful flows such as order lifecycles, authentication sequences, or multi-step checkout processes. Simceptor maintains session state across requests, letting you mock workflows that evolve over time — critical for end-to-end testing and demos. 📡 Webhook Support Configure your mock endpoints to fire outbound webhook calls upon being triggered. Test how your services react to external events without needing a real third-party system in the loop. 🧠 AI-Powered Issue Tracker When your mock doesn't behave as expected, raise an issue directly from the dashboard. Your AI agent can then read the issue, analyze the current mock configuration, apply a fix, and automatically mark it resolved — closing the feedback loop between humans and AI in your development cycle. Perfect for backend developers, QA engineers, and platform teams who want to move fast without waiting for real APIs to be ready. 🔗 simceptor.com

该来源不提供完整文件导出(国内平台多为平台内托管),仅存元数据与原链

接入信息

传输形态
http
鉴权方式
鉴权未知
端点
https://simceptor.run.tools
鉴权方式未标注,请核对官方文档后再接入——不要直接使用以下片段
{
  "mcpServers": {
    "simceptor": {
      "url": "https://simceptor.run.tools"
    }
  }
}

能力清单

工具说明
list_projectsList all active mock API projects belonging to the authenticated developer. Returns project IDs, names, and slugs. The slug is used when calling test_mock to hit the engine.
create_projectCreate a new project workspace for organizing and mocking API endpoints. Each project gets a unique slug used to route requests through the mock engine at: http://engine-host/mock/{slug}/{path}
search_mocksSearch mock APIs across all of the authenticated user's projects by keyword, tags, or HTTP method. Use this BEFORE creating new mocks to avoid duplicates. Results are scoped to the token owner's projects only.
list_mocksList all mock API endpoints in a project, organized by collections. Returns each mock's ID, name, method, path, response config, its rules, and slugId. Use this to understand what endpoints are already mocked before creating new ones. Set slim: true for a token-efficient response containing only IDs, names, methods, paths, and slugIds, omitting all rules and default response configurations.
get_mock_detailGet the full detail of a single mock API endpoint, including all its rules, stateful configuration, webhook settings, slugId, and description. Use this before updating a mock to see its current complete state. This is especially useful when you need to understand existing rule conditions before adding new rules.
create_mockCreate a new mock API endpoint in a project. IMPORTANT: Always use the 'rules' field to set up conditional response logic (the Rule Engine). The Rule Engine allows ONE mock endpoint to return DIFFERENT responses based on request content — this is the primary way to simulate multiple scenarios (success, error, validation failure, auth failure, etc.) without creating separate mocks. Rules are evaluated in ascending 'priority' order; the FIRST rule whose conditions match wins. If NO rule matches, the mock's top-level responseBody/responseStatus is used as the default fallback. Use the 'stateLookupExpr' and 'stateCaptureExpr' fields to enable stateful simulation (e.g., simulate a database that persists data across calls). If collectionName is provided but doesn't exist, it will be auto-created.
update_mockUpdate an existing mock API endpoint. Replaces all fields including rules. PREFER add_mock_rule when you only need to ADD a new rule. Only use update_mock when you need to MODIFY or DELETE existing rules, or update top-level configurations. When updating rules, you MUST provide the full updated rules array.
add_mock_ruleAppend a new conditional rule to an existing mock API endpoint. This is a token-efficient partial update tool. Use this instead of update_mock when you only need to add a new rule. Rules are evaluated in ascending priority order. The first rule whose conditions ALL match wins.
delete_mockPermanently delete a mock API endpoint from a project. This also removes all its rules and request logs.
get_request_logsRetrieve recent incoming HTTP requests captured by a mock endpoint. Each log entry shows: request headers, body, query params, matched rule label, response status returned, and response time. PROACTIVELY call this after test_mock returns unexpected results (wrong status code, wrong rule matched, or fallback fired when it shouldn't). The 'matchedRuleLabel' field is the key diagnostic indicator — a value of 'Fallback' means no rule condition was satisfied. Use debug_last_request for deeper step-by-step condition evaluation when logs alone aren't enough.
get_saved_requestsRetrieve saved request samples from the Playground. The Playground allows developers to save example request bodies, headers, and descriptions for specific mock endpoints. Use this tool to discover what request payloads are expected by a mock, read field names and data structures, and understand the different scenarios that have been documented.
save_requestSave a sample request payload to the Playground for documentation and testing. Best practice: after verifying a mock rule works correctly with test_mock, save that test request using this tool so it is documented in the Playground for the team and can be reused in future tests or issue debugging.
get_stateInspect session state stored in Redis for stateful simulation of a project. Use this after hitting a mock with stateCaptureExpr configured to verify the state was saved correctly. The sessionKey is the resolved value of stateCaptureExpr — e.g. if stateCaptureExpr='request.body.email' and you sent email='john@example.com', use sessionKey='john@example.com'. Also useful to check what data is currently in state before running a multi-step stateful flow.
delete_stateClear/Delete session state stored in Redis for stateful simulation. Use this to reset a stateful session before re-running a stateful test flow from scratch — otherwise stale state from a previous run may cause rules to behave unexpectedly. Also useful when debugging incorrect rule behavior caused by leftover state data.
bulk_create_mocksCreate multiple mock API endpoints at once under a project workspace. All the same features as create_mock apply to each item: Rule Engine (rules array), stateful simulation (stateLookupExpr/stateCaptureExpr/stateCaptureVariables), webhooks, and delay simulation. IMPORTANT: For JSON responseBody in any item, do NOT include raw newline characters ( ) as it will make the JSON payload malformed.
export_projectExport entire project configuration (all collections, mocks, webhooks, and rules) as a portable JSON representation.
import_projectImport an entire project configuration from exported JSON string. Automatically recreates project, collections, and mock endpoints.
debug_last_requestDeep diagnostic tool — use this as a last resort when get_request_logs shows a rule didn't match but you can't determine why. It re-evaluates all rule conditions against the last captured request and explains step-by-step which specific condition failed and why. Prefer get_request_logs first; only escalate to this tool when the root cause remains unclear after reading the logs.
test_mockFire a real HTTP request to the local mock engine to verify a mock endpoint returns the expected response. Use this AFTER creating or updating a mock to self-verify correctness. Test EACH rule scenario by sending different request bodies/headers that should match each rule. Check the 'X-Rule-Matched' response header to confirm which rule fired. If the wrong rule fires or no rule fires, IMMEDIATELY call get_request_logs to inspect the matched rule label and request data. After all scenarios pass, call save_request to document each tested scenario in the Playground.
get_simulator_specRetrieve the complete reference documentation for the Simceptor simulator. Call this ONLY when working on a new type of configuration you are unfamiliar with (e.g., stateful, webhooks) to save tokens. Skip if you already know the rule/condition syntax. Recommended workflow: list_projects -> list_mocks(slim:true) -> list_open_issues_for_mock -> get_mock_detail -> add_mock_rule -> test_mock -> add_issue_comment.
list_labelsList all available labels (tags) created by the authenticated user. Labels exist in 4 scopes: PROJECT (attached to projects), COLLECTION (attached to collection folders), MOCK (attached to mock API endpoints), and RULE (attached to individual rules inside a mock). AI agents MUST call this tool first before using the 'tags' filter in search_mocks or the 'label' filter in list_mocks — to discover what tags are actually available. The response groups labels by their scope so you know where each tag is used.
list_issuesList issues for a specific mock or rule target. Provide either targetSlugId (for a specific mock or rule) or mockId (for all issues across a mock and its rules). Returns summary only — use get_issue to see full comment threads. Use list_open_issues_for_mock instead if you want all OPEN (unresolved) issues across an entire mock in a single call.
list_open_issues_for_mockList all OPEN (unresolved) issues across an entire mock endpoint, including issues on its default response and all its rules. Use this when the user asks you to check all outstanding feedback for a specific mock.
get_issueRetrieve the details of a specific issue. Use includeComments: false for a token-efficient summary containing only the description without the full conversation comments.
add_issue_commentAdd a new comment/response to an issue thread. AI MUST call this tool to write a descriptive comment explaining what was fixed or changed whenever they finish fixing or addressing an issue.
resolve_issueMark an issue status as RESOLVED. DO NOT call this tool automatically. Only the user is allowed to resolve or close issues. The AI should only recommend resolving the issue to the user.
纠错与举报(发现条目失效、署名有误或涉及侵权?)
提交举报 / 纠错

侵权举报经核验成立后,我们会即时下线该条目并删除已存的内容副本。