AI Features

Mockarty integrates AI across the platform to help you generate mocks, write test scripts, diagnose errors, analyze performance, and more. Every AI feature follows a consistent pattern: an action button, a settings gear for customization, and results rendered as formatted Markdown.

About URLs in examples: All examples use localhost:5770 as the default Mockarty address. If your instance runs on a remote server, replace localhost:5770 with its actual address (e.g. https://mockarty.company.com or http://192.168.1.50:5770). See Tips & Useful Features for details.

What Is an AI Agent? Why Would I Need One for Testing?

An AI agent is a software assistant powered by a large language model (LLM) that can understand natural-language instructions and take actions on your behalf. Instead of clicking through menus and filling out forms, you describe what you need in plain English (or any language), and the agent figures out how to do it.

In the context of API testing and mocking, an AI agent can:

• Generate mocks from a description – “Create a mock for GET /api/users that returns 10 users with realistic names and emails” becomes a fully configured mock in seconds.
• Diagnose failures – paste an error response and the agent explains the root cause and suggests a fix.
• Write test scripts – the agent examines your request/response and writes assertions automatically.
• Run security scans – ask the agent to fuzz an endpoint and it configures and launches a security test.
• Query databases, call APIs, send notifications – the agent has access to 90+ built-in tools that let it interact with real systems on your behalf.

You do not need any AI or machine learning expertise. If you can describe what you want in a chat message, the agent can help.

Quickstart: Your First AI-Generated Mock

Follow these steps to create your first mock using AI. Total time: under 2 minutes.

Prerequisites: An admin must have configured at least one LLM profile (see Getting Started).

1. Open the Mock Constructor – navigate to Mocks in the sidebar, then click Create Mock.
2. Click the “Generate Mock” button – it is located in the toolbar above the mock editor.
3. Describe what you need – for example:

   Create a REST mock for GET /api/products that returns a JSON array of 5 products. Each product should have an id (integer), name (realistic product name), price (decimal between 10 and 500), and inStock (boolean).

4. Review the generated mock – the AI fills in the route, HTTP method, response body with Faker functions, and a 200 status code.
5. Click Save – your mock is live. Send a request to http://localhost:5770/stubs/sandbox/api/products to see it in action.

That is it. You can iterate by clicking Improve Mock to add error responses, edge cases, or additional conditions.

Table of Contents

• What Is an AI Agent?
• Quickstart: Your First AI-Generated Mock
• Getting Started
• LLM Profiles
• Model Selection
• AI Buttons Reference
• AI Settings (Gear Button)
• MCP Marketplace
  • What Is the MCP Marketplace?
  • Source Types
  • How Tools Are Created from APIs
  • Custom Headers and Credential Overrides
  • Tool Lifecycle
• AI Agent System
  • Overview
  • Agent Chat Widget
  • Sub-Agent Architecture
  • How Agent Routing Works
  • Built-in Tools Reference
  • Parallel Tool Execution
  • Credentials Store
  • Sessions and Context
  • Agent Tasks (Background Operations)
  • Using Marketplace Tools in Agent Chat
• Custom Agents
  • What Are Custom Agents?
  • Creating a Custom Agent
  • LLM Profile Binding
  • Routing Keywords
  • Tool Whitelists
  • Feature Key Mapping
  • Custom Agent Examples
• Marketplace Integration
• A2A Protocol (Agent-to-Agent)
• Administration Guide
  • Setting Up AI Features
  • Configuring the MCP Marketplace
  • Monitoring with AI Audit Log
  • Rate Limiting and Security
• Notifications
• Tips for Better Results
• Troubleshooting

Getting Started

AI features require at least one enabled LLM profile. Navigate to Admin → AI & LLM → LLM Profiles to create one. Mockarty supports these LLM providers:

Once a profile is configured, AI buttons appear throughout the platform.

LLM Profiles

Each profile defines:

• Provider — which LLM service to use
• Model — the default model (e.g., gpt-4o, claude-sonnet-4-20250514, qwen3:8b)
• API Key — credentials (not needed for Ollama)
• Base URL — override for self-hosted or custom endpoints
• Available Models — models users can choose from in this profile
• Enabled — toggle profile on/off

If only one profile is enabled, it’s used automatically. When multiple profiles exist, users select which one to use per AI feature.

Choosing the right profile:

• For quick operations (script generation, error diagnosis): use a fast model like gpt-4o-mini or claude-haiku
• For complex analysis (performance analysis, security audit, report generation): use a powerful model like gpt-4o or claude-sonnet
• For cost-sensitive environments: use Ollama with a local model
• For experimentation: OpenRouter provides access to many models through a single API key

Model Selection

You can choose which LLM model to use at two levels:

Per AI Feature

Every AI button (Generate Mock, Diagnose Error, etc.) has a gear icon that lets you select:

1. LLM Profile — which provider and credentials to use
2. Model — which specific model within that profile

Different features can use different models. For example, use a fast model for script generation but a powerful model for security analysis.

In Agent Chat

The agent chat widget has a model selector in the header. You can switch models mid-conversation — the new model applies to subsequent messages while the conversation context is preserved.

Custom Agent Model Binding

Admins can bind a specific LLM profile and model override to a custom agent. When a message is routed to that agent, its bound model is used automatically, regardless of the user’s default selection. See LLM Profile Binding.

AI Buttons Reference

Mock Constructor

API Tester

Fuzzing

Recorder

Performance

AI Settings (Gear Button)

Every AI button has a gear icon that opens a settings panel with three controls:

1. AI Profile

Select which LLM profile to use for this specific operation. Different profiles may have different models (fast vs. smart) or different cost tiers.

Example: Use a fast model for script generation but a powerful model for security analysis.

2. Custom Prompt

Add additional instructions for the AI. This is appended to the system prompt and lets you customize the AI’s behavior without changing any code.

Practical examples:

The custom prompt is saved per feature — your “Generate Script” prompt won’t affect “Diagnose Error”.

3. MCP Tools

If your admin has configured MCP Marketplace tools, you can select which external tools the AI can use during this operation. When tools are selected:

1. They are sent to the LLM alongside your request
2. The LLM may call tools during generation (e.g., querying a live API, fetching real data)
3. Tool results are fed back to the LLM for a more accurate response
4. The final response incorporates real-time data from the tools

Example: You have an OpenAPI tool pointing at your staging server. When generating a mock, the AI can call the real API to understand response structure, then create a mock that matches the actual behavior.

Each feature stores its tool selections independently — tools enabled for “Generate Mock” don’t affect “Diagnose Error”.

MCP Marketplace

What Is the MCP Marketplace?

The MCP Marketplace is a tool integration system that lets your admin connect external APIs, services, and AI agents to Mockarty’s AI features. Once connected, their capabilities become tools that the AI can call during any operation.

The core idea: Instead of the AI only having its own knowledge, it gains the ability to call real APIs, query databases, interact with external services, and collaborate with other AI agents — all during a single AI operation.

Example workflow:

1. Admin registers your staging API’s OpenAPI spec in the marketplace
2. Each endpoint in the spec becomes an available tool (e.g., GET /api/users → getUsers tool)
3. When you ask the AI to “generate a mock for the users API,” it can call the real getUsers endpoint
4. The AI sees the actual response structure, field types, and realistic data
5. It generates a mock that accurately mirrors your real API

Source Types

The marketplace supports six integration types, each converting a different protocol into AI-callable tools:

How Tools Are Created from APIs

OpenAPI (REST APIs)

When you register an OpenAPI/Swagger spec URL, Mockarty:

1. Fetches and parses the spec (JSON or YAML)
2. Converts each endpoint into a tool:
   • Tool name = operation ID or method + path (e.g., getUserById)
   • Tool description = endpoint summary from the spec
   • Tool inputs = path params, query params, headers, request body — all with types from the spec
   • Tool tag = first OpenAPI tag (for grouping)
3. When the AI calls the tool, Mockarty constructs a real HTTP request and executes it

Example: An OpenAPI spec with GET /api/users/{id} becomes a tool named getUserById with an id parameter. The AI calls it with {"id": "123"}, and Mockarty makes the real HTTP request, returning the response to the AI.

WSDL (SOAP Services)

When you register a WSDL URL, Mockarty:

1. Parses the WSDL document
2. Extracts all operations from port types
3. Creates tools with soap_ prefix (e.g., soap_GetCustomerInfo)
4. Builds the SOAP XML envelope automatically when the AI calls the tool

This lets the AI interact with legacy SOAP services without knowing XML or SOAP protocols — it just passes JSON parameters.

MCP Server

MCP (Model Context Protocol) servers are purpose-built tool providers:

1. Mockarty connects to the server via JSON-RPC
2. Calls tools/list to discover available tools
3. Each tool has a name, description, and JSON Schema input definition
4. Tool calls go through tools/call with JSON-RPC

Stateful sessions: MCP servers can maintain state across tool calls within a single conversation. For example, a Playwright MCP server can open a browser in one tool call and navigate pages in subsequent calls — all within the same chat session.

A2A Agent

Agent-to-Agent integration connects to external AI agents:

1. Mockarty fetches the agent card from /.well-known/agent.json
2. The agent’s skills become available tools
3. Tool calls are proxied to the external agent

Custom Headers and Credential Overrides

Many external APIs require authentication. Mockarty handles this at two levels:

Server-level authentication (set by admin):

User-level header overrides:

Each user can override server authentication headers per feature. This is useful when:

• Different team members need different credentials (e.g., dev vs. staging)
• You want to test against different environments
• A tool needs per-user API keys

How to set custom headers:

1. Open the AI settings gear for any feature
2. In the MCP Tools section, expand a server’s “Custom Headers” area
3. Add or override headers with key-value pairs
4. Click Save

Your header overrides are merged on top of the server’s default headers at execution time. If you set Authorization: Bearer my-token, it replaces the server’s default auth for your requests only.

Tool Lifecycle

Once a server is registered in the marketplace:

1. Discovery: A background worker refreshes tool lists periodically (default: every 2 hours, configurable per server)
2. Health check: The worker also checks server connectivity and updates status (online, offline, error)
3. Caching: Discovered tools are stored in the database for fast loading
4. Selection: Users select which tools to enable per AI feature via the settings gear
5. Execution: When the AI calls a tool, Mockarty routes the call through the appropriate adapter
6. Result: Tool output is returned to the AI for incorporation into the final response

Admins can trigger manual health checks and tool refreshes from the marketplace admin page.

AI Agent System

Overview

The AI Agent System (ADK — Agent Development Kit) provides intelligent, multi-step AI interaction. Unlike single-prompt AI buttons (which do one thing and return), the agent system can:

• Route your request to a specialized sub-agent
• Execute multiple tool calls in parallel
• Maintain conversation context across messages
• Run background tasks asynchronously
• Access 90+ built-in tools for mock CRUD, API testing, database queries, notifications, and more

Agent Chat Widget

The floating chat widget in the bottom-right corner connects you to the AI agent system.

How it works:

1. Type a message describing what you need
2. The system routes your message to the most appropriate sub-agent
3. The agent analyzes your request and may call tools (you’ll see tool calls in the chat)
4. If tool calls require approval, you’ll be prompted to approve or decline
5. The agent returns a response incorporating tool results
6. The conversation context is preserved — follow-up messages build on previous context

Key features:

• Streaming responses — you see the AI thinking in real-time
• Tool call transparency — see which tools are called and their results
• Tool approval — for data-modifying tools, you approve before execution
• Session persistence — close the chat and come back later, context is preserved
• Multiple sessions — start new conversations or continue existing ones

Sub-Agent Architecture

The agent system uses a multi-agent architecture with 13 specialized sub-agents plus an orchestrator. Each sub-agent is optimized for a specific domain and has access to only the tools relevant to its specialization.

How It Works

When you send a message, the orchestrator routes it to the most appropriate sub-agent based on keywords in your message. Each sub-agent has:

• A domain-specific system prompt that guides its behavior
• A filtered tool set containing only the tools it needs
• Routing keywords that determine when it is activated

If no sub-agent matches, the orchestrator handles the request directly with access to all utility, database, and notification tools.

The 13 Built-in Sub-Agents + Orchestrator

How Agent Routing Works

When you send a message, the system automatically selects the best sub-agent based on keywords in your message:

Routing priority:

1. Custom agents (admin-created) are checked first — their keywords take priority
2. Built-in sub-agents are checked in the order listed above
3. If no keywords match, the orchestrator handles the request directly

Built-in Tools Reference

The agent system includes 90+ built-in tools organized by category. Each sub-agent has access to a subset of these tools relevant to its domain.

Mock Management Tools (via MCP)

Store Management Tools (via MCP)

Code Generation Tools (via MCP)

Template and File Tools (via MCP)

API Testing Tools

Fuzzing Tools

Performance Testing Tools

Recorder Tools

Contract Testing Tools

HTTP and API Client Tools

Database Tools

Web and Content Tools

Data Transformation Tools

Notification Tools

Session Management Tools

Parallel Tool Execution

The agent system executes multiple tool calls simultaneously when an LLM requests several tools in a single response turn. This significantly speeds up complex operations.

How it works:

1. The LLM decides it needs to call multiple tools (e.g., list_mocks + list_collections + current_time)
2. Mockarty dispatches all tool calls in parallel using goroutines
3. Results are collected concurrently and returned to the LLM together
4. The LLM processes all results in the next turn

Example: When asked “Show me all mocks and test collections in the payments namespace,” the agent calls list_mocks and list_collections simultaneously rather than sequentially, halving the response time.

Inline tools (such as form_update and permission checks) are handled synchronously before parallel execution begins, ensuring security checks are never bypassed.

Credentials Store

The Credentials Store allows you to provide API keys, database connection strings, tokens, and other secrets to the agent without including them in your chat messages.

Key security property: Credentials are stored in your browser’s localStorage only. They are never sent to the Mockarty server for storage — they are included in the request payload only when the agent needs them for a specific tool call.

How to use:

1. Click the key icon in the agent chat header to open the Credentials panel
2. Add entries as key-value pairs (e.g., POSTGRES_DSN → postgres://user:pass@host:5432/db)
3. Close the panel — credentials are saved in your browser immediately
4. When chatting, reference credentials by name: “Query the database using my POSTGRES_DSN credential”
5. The agent automatically passes matching credentials to tools like sql_query, http_request, send_slack, etc.

Common credential names:

Privacy note: Since credentials are in localStorage, they are per-browser and per-device. Clearing your browser data will remove them. Other users cannot see your credentials.

Sessions and Context

Agent chat sessions are persisted to the database:

• Session creation: A new session starts when you open the chat or click “New Chat”
• Message history: Up to 100 previous messages are loaded when you reopen a session
• Context window: Active conversations are trimmed to 200 messages to prevent memory issues
• Session expiry: Sessions expire after 24 hours of inactivity (configurable)
• MCP session isolation: Each chat session gets its own MCP session — stateful MCP tools (like Playwright) maintain state per conversation

Agent Tasks (Background Operations)

Some operations are too long for a chat response. Agent tasks run in the background:

• Created via: Agent chat, AI buttons (when operation is complex), or the A2A protocol
• Progress tracking: Real-time step-by-step execution log with SSE streaming
• Tool call visibility: See which tools were called and their results
• Cancellation: Cancel running tasks at any time
• Edit & Rerun: Edit any step in the flow and re-execute from that point
• Export: Download the full task flow as JSON for debugging or sharing
• Completion notifications: Get notified via bell icon and (if configured) email
• Concurrency limit: Configurable max concurrent tasks (default: 3)

Tasks are managed entirely within the Agent Chat Widget. Click the Tasks tab (clipboard icon) in the floating chat to see all your tasks. A badge appears when tasks complete while you’re working on other pages.

Flow Overlay: Click View Flow on any task to see the full step-by-step execution trace:

• Steps are grouped by parent-child relationships (tool calls paired with their results)
• Parallel tool call batches are visually grouped
• Each step shows duration, token count, model, and agent name in micro-chips
• LLM-generated text (thoughts, decisions, answers) is rendered as Markdown
• Error steps show the full error description

Edit & Rerun: Click the pencil icon on any step to edit its content, then click Rerun from step N to re-execute the task from that point with your modifications applied.

Using Marketplace Tools in Agent Chat

When marketplace tools are configured, they become available in the agent chat:

1. Open the agent chat settings gear
2. Select which marketplace tools to enable
3. Start chatting — the agent can now use both built-in and marketplace tools

Example: With a staging API registered as an OpenAPI source, you can ask:

“Call the getUsers endpoint on staging, then create a mock that returns the same response structure”

The agent will:

1. Call the getUsers marketplace tool (real HTTP request to staging)
2. Analyze the response structure
3. Use built-in tools to create a mock with matching fields

Custom Agents

What Are Custom Agents?

Custom agents are admin-created specialists that extend the agent system. While Mockarty comes with 13 built-in sub-agents plus an orchestrator, your organization may need domain-specific agents with:

• Custom system prompts tailored to your domain
• Specific tool whitelists (only the tools this agent should use)
• Routing keywords that match your team’s vocabulary
• Bound LLM profiles and model overrides
• Feature key mapping to customize AI button behavior

Creating a Custom Agent

Admins create custom agents from Admin → AI & LLM → Agent Settings.

Each custom agent requires:

LLM Profile Binding

Custom agents can be bound to a specific LLM profile and model. When a message is routed to this agent:

1. The bound LLM profile is used instead of the user’s default selection
2. If a model override is set, that specific model is used within the profile
3. This ensures the agent always uses the optimal model for its domain

Use cases:

• Bind a security review agent to a powerful model (e.g., claude-sonnet) for thorough analysis
• Bind a simple FAQ agent to a fast model (e.g., gpt-4o-mini) to reduce cost
• Bind a code generation agent to a code-optimized model

Routing Keywords

Keywords determine when the system routes a chat message to your custom agent. Custom agent keywords are checked before built-in agents, giving admin-defined agents priority.

Example: A payment_specialist agent with keywords ["payment", "checkout", "billing", "invoice"] will handle any chat message containing those words — even if built-in agents would otherwise match.

Tips for keywords:

• Use domain-specific terms your team actually uses
• Include synonyms (e.g., both “payment” and “billing”)
• Avoid overly generic words (e.g., “test” would capture too many requests)
• Keywords are case-insensitive

Tool Whitelists

By default, agents can use all available tools. A tool whitelist restricts an agent to only specific tools — useful for:

• Security: An analysis-only agent shouldn’t modify mocks
• Focus: A mock specialist doesn’t need fuzzing tools
• Compliance: Limit which tools can access production data

Select tools from the list of built-in tools and any registered marketplace tools.

Feature Key Mapping

A custom agent can be mapped to an AI button feature key. When mapped, the agent’s system prompt is appended to the button’s default prompt, and the agent’s tool whitelist is applied.

Available feature keys:

Example: Map payment_specialist to generate-mock → whenever anyone clicks “Generate Mock”, the payment specialist’s system prompt is added, giving the AI extra context about payment APIs.

Custom Agent Examples

Domain-Specific Mock Expert

Name: healthcare_mock_expert
Description: Creates HIPAA-compliant healthcare API mocks
System Prompt: |
  You are a healthcare API specialist. When creating mocks:
  - Never use real patient data — always use Faker functions
  - Follow HL7 FHIR resource structure for healthcare endpoints
  - Include proper error responses for auth failures (401, 403)
  - Add X-Request-ID and X-Correlation-ID headers to all responses
  - Use ICD-10 codes from the valid range for diagnosis fields
Keywords: [healthcare, patient, fhir, hl7, medical, hipaa, diagnosis]
Feature Key: generate-mock

Security Review Agent

Name: security_reviewer
Description: Reviews API configurations for security issues
System Prompt: |
  You are a security specialist. When analyzing:
  - Check for missing authentication on sensitive endpoints
  - Verify rate limiting is configured
  - Look for PII exposure in response payloads
  - Check CORS configuration
  - Verify TLS/HTTPS usage
  - Flag any hardcoded credentials or tokens
Keywords: [security review, audit, compliance, pentest, owasp]
Tools: [browse_url, analyze_content, sql_query]
LLM Profile: claude-sonnet-profile

CI/CD Integration Agent

Name: cicd_agent
Description: Generates test configurations for CI/CD pipelines
System Prompt: |
  You are a CI/CD integration specialist. Help users:
  - Create test collections suitable for pipeline execution
  - Generate performance test scripts with CI-friendly thresholds
  - Configure fuzzing with time-bounded durations
  - Format results for JUnit/TAP output parsers
Keywords: [ci, cd, pipeline, jenkins, github actions, gitlab ci, deploy]
Tools: [build_api_collection, generate_test_script, configure_fuzzing]

Notification Router Agent

Name: alert_manager
Description: Routes test results and alerts to the right channels
System Prompt: |
  You are an alert routing specialist. Based on the severity and type of event:
  - Critical failures → PagerDuty incident + Slack #incidents
  - Test suite failures → Teams channel + email to QA lead
  - Performance degradation → Slack #performance + Opsgenie alert
  - Successful deployments → Slack #releases + Jira comment
  Always include: timestamp, environment, summary, and link to results.
Keywords: [alert, incident, notify team, send report, broadcast]
Tools: [send_slack, send_teams, send_pagerduty, send_opsgenie, send_email, send_jira_comment, current_time]

Marketplace Integration

The MCP Marketplace connects external services to the agent system, giving agents access to tools beyond the built-in set. This section explains how marketplace tools and agents work together.

Connecting External MCP Servers

MCP (Model Context Protocol) servers are the most powerful integration type. They provide custom tools that the agent can call during conversations.

Popular MCP servers:

• Playwright — browser automation (navigate, click, screenshot, fill forms)
• File System — read/write files on a server
• Database — query external databases
• GitHub — manage repositories, issues, PRs
• Custom — build your own MCP server for any API

Stateful sessions: Each agent chat conversation gets its own MCP session. This means a Playwright MCP server can open a browser in one tool call, navigate in the next, and screenshot in the third — all within the same chat.

Connecting OpenAPI/gRPC/WSDL Services

Register your existing API documentation and the agent gains the ability to call your real APIs:

1. OpenAPI — each endpoint becomes a callable tool. The agent can test real APIs, fetch data, and verify behavior.
2. gRPC — discovers service methods via gRPC server reflection. Tool calls are proxied as real gRPC requests to the target server.
3. WSDL — each SOAP operation becomes a tool with automatic XML envelope construction.

Connecting A2A Agents

Connect external AI agents that follow the Agent-to-Agent protocol:

1. Register the agent’s base URL in the marketplace
2. Mockarty fetches the agent card from /.well-known/agent.json
3. The external agent’s skills become tools available in Mockarty’s agent chat

This enables multi-agent workflows where Mockarty delegates tasks to specialized external agents.

Tool Selection Per Feature

Each AI feature (and each agent chat session) maintains its own selection of marketplace tools. This prevents tool overload — the LLM only sees tools relevant to the current task.

Configure tool selection:

• AI buttons: Click the gear icon → MCP Tools section
• Agent chat: Click the gear icon in the chat header

A2A Protocol (Agent-to-Agent)

External AI agents can interact with Mockarty using the Agent-to-Agent protocol:

Use cases:

• An external orchestrator agent delegates mock creation to Mockarty
• A CI/CD agent asks Mockarty to run tests and report results
• A multi-agent system coordinates testing across services

The A2A protocol follows the Google Agent-to-Agent standard, making Mockarty compatible with any A2A-compliant agent platform.

Administration Guide

Setting Up AI Features

Step 1: Create an LLM Profile

1. Navigate to Admin → AI & LLM → LLM Profiles
2. Click Add Profile
3. Select a provider (OpenAI, Anthropic, etc.)
4. Enter your API key and select a model
5. Click Save and ensure the profile is Enabled

Step 2: (Optional) Register Marketplace Tools

1. Navigate to Admin → AI & LLM → MCP Marketplace
2. Click Add Integration
3. Choose source type and enter the URL
4. Configure authentication if needed
5. Click Save — tools are auto-discovered within 30 minutes

Step 3: (Optional) Create Custom Agents

1. Navigate to Admin → AI & LLM → Agent Settings
2. Click Create Agent
3. Fill in name, description, system prompt, and optional keywords/tools
4. Optionally bind an LLM profile and model override
5. Click Save

Configuring the MCP Marketplace

Adding an OpenAPI Source

1. Click Add Integration → Source Type: OpenAPI
2. Enter the URL to your OpenAPI/Swagger spec (JSON or YAML)
   • Example: https://api.staging.example.com/swagger.json
3. If the API requires auth, set the Auth Type:
   • Bearer: paste your access token
   • API Key: enter the key and header name (e.g., X-API-Key)
   • Basic: enter username and password
4. Click Save
5. Click the plug icon to verify connection — you should see “online” status
6. Click the list icon to view discovered tools

Adding an MCP Server

1. Click Add Integration → Source Type: MCP Server
2. Enter the MCP server endpoint (e.g., http://localhost:3000/mcp)
3. Set auth if required
4. Click Save

MCP servers support stateful sessions — each agent chat conversation gets its own session, allowing tools like Playwright to maintain browser state across calls.

Adding a WSDL (SOAP) Source

1. Click Add Integration → Source Type: WSDL
2. Enter the WSDL URL (e.g., https://legacy.example.com/service?wsdl)
3. Set auth (many SOAP services use Basic auth)
4. Click Save

Each SOAP operation becomes a tool with a soap_ prefix.

Refresh and Health

• Auto-refresh: A background worker checks servers every 30 minutes. Each server has its own refresh interval (default: 2 hours).
• Manual check: Click the plug icon on any server to trigger an immediate health check.
• Status indicators: Green = online, Red = error (hover for details), Gray = unknown.

Monitoring with AI Audit Log

Navigate to Admin → AI & LLM → AI Audit Log.

Every AI operation is logged:

• Timestamp — when the operation ran
• User — who initiated it
• Action — which AI feature (generate_mock, diagnose_error, etc.)
• Profile — which LLM profile was used
• Duration — LLM call duration in milliseconds
• Status — success, error, or rate_limited
• Tokens — token usage (if reported by provider)

Filter by user, action type, status, and date range. Export to CSV for compliance reporting.

Rate Limiting and Security

AI rate limits:

• Each user has a daily AI call limit (configurable by admin)
• When the limit is reached, AI buttons show a rate limit error
• The audit log tracks all calls for monitoring

Security measures:

• browse_url tool blocks private/internal IP addresses (SSRF protection)
• sql_query tool is read-only (SELECT/WITH only) and blocks sensitive tables
• db_list_tables is read-only — no schema modification
• redis_command is limited to read-only commands
• Tool calls to marketplace servers validate URLs against SSRF
• User header overrides are isolated per user — one user’s credentials don’t leak to others
• MCP sessions are isolated per conversation
• Credentials Store data stays in browser localStorage, never stored on server
• All AI requests are logged in the audit log
• Custom agent tool whitelists enforce least-privilege access

Notifications

AI operations generate notifications:

The bell icon in the top navigation shows unread notification count. Click it to view, dismiss, or follow notification links.

Tips for Better Results

1. Be specific: “Generate a mock for GET /api/users that returns 10 users with name, email, and role fields” is better than “create a user mock”
2. Provide context: Use the custom prompt to tell the AI about your domain, SLAs, or coding standards
3. Choose the right model: Fast models for simple tasks, powerful models for analysis
4. Iterate: If the first result isn’t perfect, use “Improve Mock” or adjust your custom prompt
5. Use MCP tools: When available, enable relevant tools so the AI can access real data from your APIs
6. Review AI triage carefully: Auto-triage is a starting point — always verify critical findings manually
7. Leverage custom headers: If tools need your credentials, set them in the settings gear rather than including them in prompts
8. Use the Credentials Store: For database connections, API keys, and webhook URLs — store them once in the Credentials panel and reference by name
9. Use agent chat for complex tasks: Multi-step operations work better through the chat interface where the agent can iterate
10. Scope your custom agents: Give custom agents specific keywords and tool whitelists to keep them focused
11. Bind models to agents: Use LLM profile binding to ensure each custom agent uses the optimal model for its task
12. Ask your admin to add integrations: If the AI lacks context about your APIs, ask your admin to register them in the MCP Marketplace

Troubleshooting

“LLM not configured”

No enabled LLM profiles exist. Ask your admin to create one in Admin → AI & LLM → LLM Profiles.

“LLM profile not found”

The selected profile was deleted or disabled. Click the gear button and select a different profile.

AI response is slow

• Try a faster model (switch from GPT-4o to GPT-4o-mini)
• Reduce custom prompt length
• Disable unnecessary MCP tools (each tool call adds latency)
• For agent chat: reduce the number of enabled marketplace tools

MCP tools not working

• Check that the marketplace server is online (Admin → AI & LLM → MCP Marketplace)
• Verify the tool is enabled on the server
• Check that you’ve selected the tool in the feature’s settings gear
• If using custom headers, verify your credentials are correct
• Check the server logs for auth errors

Agent chat not routing correctly

• The routing is keyword-based — try rephrasing your request with clearer keywords
• Custom agent keywords take priority over built-in agents
• Check Admin → Agent Settings to see which custom agents and keywords are active
• Use explicit phrases like “create a mock for…” to target the mock_builder agent

Database tools returning errors

• Verify the connection string in your Credentials Store is correct
• Check that the database is accessible from the Mockarty server
• SQL tools only support SELECT and WITH queries — UPDATE/INSERT/DELETE are blocked
• Check for network/firewall issues between Mockarty and the database

Notification tools failing

• For email: verify SMTP is configured in Admin → Email Settings
• For Slack/Teams/Discord: verify the webhook URL is valid and not expired
• For Telegram: verify bot token and chat_id are correct
• For PagerDuty/Opsgenie: verify the API key or routing key
• Check the Credentials Store for typos in keys or values

Tool calls are being declined

• Some tools require approval — you’ll see an approve/decline prompt
• Read-only tools (browse, analyze, query) are auto-approved
• Data-modifying tools (create, update, delete) may require approval depending on your admin’s configuration

AI analysis not saved

For features that persist analysis (test reports, fuzzing findings, perf results), the analysis is saved automatically. Refresh the page to see it in the report.

Custom headers not applied

• Header overrides are per-feature — check that you set them for the correct feature
• Overrides replace server defaults — if you set Authorization, it overrides the server’s auth
• Clear your overrides if you want to fall back to server defaults