Which integrations are available for this server?

Provides testing capabilities for WordPress sites, including plugin and theme validation, page content checks, and performance testing.

How do I use MCP QA 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., "@MCP QA Server run QA tests for the current project" 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.

MCP QA Server

by 404Yeti

Overview Schema Related Servers Score Discussions

TypeScript

Local

MCP QA Server

A reusable Model Context Protocol (MCP) server for QA automation testing. Works across multiple project types — web apps, API services, CLI tools, VM environments, and WordPress sites.

The server itself is project-agnostic. All project-specific test targets live in a .mcp-qa-config.json file inside each project's repository.

Quick Start

# Clone and install
git clone <repo-url> mcp-qa-server
cd mcp-qa-server
npm install
npm run build

# Install CLI globally
npm link

# In any project directory:
mcp-qa init

Related MCP server: mcp-playwright-test

Adding to Claude Desktop

Add to your Claude Desktop claude_desktop_config.json:

{
  "mcpServers": {
    "qa": {
      "command": "node",
      "args": ["/absolute/path/to/mcp-qa-server/dist/src/index.js"]
    }
  }
}

Then ask Claude: "Run QA tests for this project" — Claude will use the qa_run_tests tool with your project path.

CLI Commands

`mcp-qa init`

Interactive initialization. Creates .mcp-qa-config.json in the current directory with sensible defaults based on your project type.

$ mcp-qa init

  MCP QA Server — Project Initialization
  ──────────────────────────────────────────

? Project name: my-web-app
? Project type: Web Application
? Base URL: http://localhost:3000
? Which testing modules do you need? Web/UI Testing, API Testing
? Report format: Console

`mcp-qa validate`

Validates the config file in the current directory. Reports specific errors with field paths.

$ mcp-qa validate

  Config is valid
    Project:  my-web-app
    Type:     web-app
    Modules:  web, api (2 active)
    Issues:   none

`mcp-qa list-modules`

Lists all available testing modules.

$ mcp-qa list-modules

  Available Modules:
    web            Web/UI testing (page loads, forms, workflows)
    api            API endpoint testing (REST, response validation)
    cli            CLI tool testing (command execution, output validation)
    vm             VM environment validation (tools, deps, configs)
    wordpress      WordPress testing (plugins, themes, pages)
    integration    Integration testing (cross-module orchestration)
    performance    Performance testing (load, response times)

MCP Tools

The server exposes 5 tools to Claude:

Tool	Description
`qa_run_tests`	Run all (or filtered) tests for a project
`qa_run_module`	Run a single testing module
`qa_list_modules`	List available modules and their status
`qa_check_config`	Validate the project config file
`qa_get_report`	Retrieve the last test report

Testing Modules

Web/UI (`web`)

Browser-based testing via Playwright (headless Chromium).

Page loads — URL reachability, status codes, load timing, content checks
Forms — Field filling, submission, redirect/content/error validation
Workflows — Multi-step browser interactions (navigate, click, fill, wait, assert)

Requires: npx playwright install chromium

API (`api`)

HTTP endpoint testing.

REST requests — All HTTP methods, headers, query params, request bodies
Response validation — Status codes, body type, key presence, value matching
Authentication — Bearer token, API key, Basic auth via environment variables
Chaining — Capture response values for use in subsequent requests

CLI (`cli`)

Command-line tool testing.

Execution — Spawn processes with args, env vars, stdin, timeout
Output validation — stdout/stderr exact match, contains, regex patterns
Exit codes — Assert specific exit codes
File creation — Verify commands create expected files with expected content

VM Environment (`vm`)

Validate development environment setup.

Tool checks — Binary existence on PATH via command -v
Version validation — Semver range checking (e.g., >=20.0.0)
Dependencies — Arbitrary command-based version checks
Config files — Existence, permissions, content pattern matching
Services — Systemd/launchd service status checks

WordPress (`wordpress`)

WordPress-specific testing.

Plugins — Installation and activation status via WP-CLI or HTTP fallback
Themes — Active theme validation
Pages — Content loading, status codes, content checks

Performance (`performance`)

Basic load and response time testing.

Timing — Single-request response time thresholds
Load testing — Concurrent request bursts with p50/p95/p99 percentiles
Error rates — Track failures under load

Integration (`integration`)

Cross-module test orchestration.

Scenarios — Sequential steps spanning multiple modules
Shared state — Pass data between modules via context.store
Stop on failure — Abort scenario when a step fails

Configuration

Config files live in each project as .mcp-qa-config.json. Run mcp-qa init to generate one, or create manually.

Schema

{
  "configVersion": 1,
  "projectName": "my-project",
  "projectType": "web-app",        // web-app | api-service | cli-tool | vm-environment | wordpress-site
  "modules": ["web", "api"],       // Which modules to enable
  "reportFormat": "console",       // console | json | github
  "baseUrl": "http://localhost:3000",
  "timeout": 30000,                // Global timeout in ms
  "env": {},                       // Environment variables for test runs
  "moduleConfig": {                // Per-module config (see below)
    "web": { ... },
    "api": { ... }
  }
}

Module Config Examples

See the templates/ directory for complete examples:

templates/web-app.json — Web app with page loads, forms, workflows, API endpoints, performance targets
templates/api-service.json — API service with auth, CRUD endpoints, performance
templates/cli-tool.json — CLI with version, help, file processing, error handling commands
templates/vm-environment.json — VM with tools, dependencies, config files, services
templates/wordpress-site.json — WordPress with plugins, themes, pages, performance

Report Formats

Console

Human-readable with [PASS]/[FAIL]/[SKIP]/[ERR!] indicators, file:line error locations, module grouping, and summary.

JSON

Machine-readable structured output. Full TestReport object with all results, timing, and error details.

GitHub Actions

Annotation format for CI. Produces ::error file=X,line=Y::message output that creates inline annotations on pull requests.

Error Reporting

All errors include location information when available:

Config errors — File path + line number pointing to the invalid field
Test failures — Test name, module, and the config entry that defined the test
Runtime errors — Stack traces with source locations

Console format: .mcp-qa-config.json:25 — Expected redirect to /dashboard GitHub format: ::error file=.mcp-qa-config.json,line=25::Expected redirect to /dashboard

Development

npm run build     # Compile TypeScript
npm run dev       # Watch mode
npm test          # Run tests
npm run lint      # Lint

Architecture

.mcp-qa-config.json (per project)
        │
        ▼
┌─── MCP QA Server ──────────────┐
│  Config Loader → Module Registry│
│       │              │          │
│  Test Runner ← Base Module      │
│       │              │          │
│  Reporter       7 Modules       │
│  (console/json/github)          │
└─────────────────────────────────┘
        │
        ▼
  Claude Desktop (via stdio)

The server reads .mcp-qa-config.json from disk on every tool call (never cached) so edits are picked up immediately.

Available Tools

5 tools

qa_check_configA

Validate a project's .mcp-qa-config.json file. Returns validation results with specific error messages and line numbers if invalid.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	Absolute path to the project directory containing .mcp-qa-config.json

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must disclose all behavioral traits. It states the tool returns validation results with error messages and line numbers, but does not indicate whether it modifies any files, requires permissions, or has side effects. While not contradictory, it lacks depth for a validation 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 with no wasted words. It front-loads the core purpose and then specifies the output format, making it efficient for an AI agent to parse.

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 (single parameter, no output schema, no annotations), the description is reasonably complete. It explains what it validates and what results to expect, though it could mention that it is a read-only operation.

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% for the single parameter 'projectPath', and its schema description adequately explains it. The tool description does not add any additional meaning beyond the schema, warranting 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 validates a specific file (.mcp-qa-config.json) and returns validation results. The verb 'Validate' and resource 'project's .mcp-qa-config.json file' are specific, and it distinguishes itself from sibling tools (e.g., qa_run_tests, qa_list_modules) by focusing on configuration validation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., qa_run_module, qa_run_tests) or context for usage. It does not mention prerequisites, when validation is needed, or when it might not be appropriate.

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

qa_get_reportB

Retrieve the last test report for a project. Optionally specify a different output format than what the config defaults to.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format. Defaults to the project's configured format.
`projectPath`	Yes	Absolute path to the project directory

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action. It does not disclose consequences of missing reports, required permissions, side effects, or error behavior. This leaves the agent with incomplete understanding.

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 very concise—two sentences that cover the core functionality and an optional parameter. No wasted words, and the structure is front-loaded with the primary action.

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?

The description is adequate for a simple retrieval tool with well-documented parameters, but it lacks details about the output format (no output schema) and error conditions. It does not explain what 'last test report' means or how failures are handled, leaving some 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 description coverage is 100%, so the schema already explains both parameters. The description adds slight value by noting that the format parameter can override the config default, but it does not elaborate on other parameter details or add meaning beyond the schema.

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 that the tool retrieves the last test report for a project, using a specific verb ('Retrieve') and resource ('test report'). It distinguishes itself from sibling tools like qa_run_tests (which runs tests) and qa_check_config (which checks config).

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. It mentions an optional format parameter but lacks explicit context about when the tool is appropriate or what prerequisites exist.

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

qa_list_modulesA

List available QA testing modules. If a projectPath is provided, also shows which modules are enabled for that project.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	No	Optional project path to show project-specific module status

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 discloses the main behavior (listing modules) and conditional behavior (with projectPath), but does not mention read-only nature, authentication needs, or rate limits. For a simple list tool, this is adequate but not exceptional.

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-loaded with the main purpose, and uses minimal words to convey the tool's function and conditional behavior. No wasted text.

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 simplicity of the tool (one optional parameter, no output schema), the description covers the essential functionality. It could mention return format or that it returns a list of module names and statuses, but for a list tool, it is sufficiently 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 description coverage is 100% (one parameter fully described). The tool description repeats the same information about the optional parameter, adding no new meaning beyond what the schema already provides.

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 'List' and the resource 'QA testing modules', and distinguishes itself from sibling tools like qa_run_module or qa_check_config by focusing on listing rather than execution or configuration.

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 when to use the optional projectPath parameter (to see enabled modules for a specific project), which provides clear usage guidance. However, it does not explicitly state when not to use alternatives, but the sibling tools are sufficiently different.

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

qa_run_moduleA

Run a single QA test module for a project. Use this for targeted testing of a specific area (e.g. just API tests or just VM checks).

ParametersJSON Schema

Name	Required	Description
`module`	Yes	Module name to run (e.g. 'web', 'api', 'cli', 'vm', 'wordpress', 'performance', 'integration')
`testFilter`	No	Only run tests whose names contain this substring
`projectPath`	Yes	Absolute path to the project directory containing .mcp-qa-config.json

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not reveal what happens on module failure, whether it modifies state, access permissions needed, or output format. For a test-running tool, basic behavioral info is missing.

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 with no unnecessary words. It front-loads the action and purpose immediately, making it easy to parse.

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?

For a tool with three simple parameters and no output schema, the description covers the main purpose and usage scenario. It mentions 'targeted testing' and gives examples. It could mention the requirement of .mcp-qa-config.json (implied in projectPath schema), but overall it is reasonably 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?

Input schema coverage is 100%, so the schema already documents all three parameters adequately. The description adds no additional meaning or context beyond what the schema provides, adhering to the baseline 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 that the tool runs a single QA test module for a project, using a specific verb ('Run') and resource ('single QA test module'). It also distinguishes from siblings like qa_run_tests by emphasizing targeted testing of a specific area (e.g., 'just API tests or just VM checks').

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 provides explicit context, recommending use for targeted testing of a specific area (e.g., 'just API tests or just VM checks'). It implies when to use this tool over alternatives like qa_run_tests, but does not explicitly state when not to use it or name alternatives directly.

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

qa_run_testsA

Run QA tests for a project. Loads .mcp-qa-config.json from the project path, executes the configured test modules, and returns a formatted report. Optionally filter by module names or test name substring.

ParametersJSON Schema

Name	Required	Description
`filter`	No	Only run tests whose names contain this substring
`modules`	No	Only run these modules (e.g. ['web', 'api']). Defaults to all configured modules.
`projectPath`	Yes	Absolute path to the project directory containing .mcp-qa-config.json

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses loading config, executing modules, and returning a report. However, it does not mention safety (e.g., whether tests can modify state), idempotency, or error 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 with no fluff. Front-loaded with the core action and quickly provides additional details. Every word earns its place.

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 no output schema, the description mentions returning a 'formatted report' but lacks specifics on the report format or contents. Also lacks error handling or edge case info. Adequate but not comprehensive.

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%, so baseline is 3. The description adds slight context (e.g., 'Only run tests whose names contain this substring' for filter) but largely restates schema descriptions. No deep semantic enrichment.

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 'Run QA tests for a project' with a specific verb and resource, and references the config file .mcp-qa-config.json. It distinguishes from siblings like qa_run_module by mentioning optional filtering by modules or test name.

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 (when you want to run tests) but does not explicitly state when to use this tool versus alternatives like qa_run_module or qa_list_modules. No exclusions or 'when not to use' guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jun 28, 2026
- First observedqa_check_config
- First observedqa_get_report
- First observedqa_list_modules
- First observedqa_run_module
- First observedqa_run_tests

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: validating config, retrieving reports, listing modules, running specific modules, and running full test suites. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent 'qa_verb_noun' pattern (e.g., qa_check_config, qa_run_tests), making them predictable and easy to understand.

Tool Count5/5

Five tools is well-scoped for a QA-focused server, covering essential operations without being excessive or insufficient.

Completeness5/5

The tool set covers the core workflow: configuration validation, module listing, selective or full test execution, and report retrieval. No obvious gaps for the given domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2
Qase Test ManagementOAuth
io.qase
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
Testing & QA Tools Developer Tools
231
agentcentral AOAuth
to.agentcentral
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
E-commerce & Retail Customer Support
26

Related MCP Servers

Web-QA
Testing & QA Tools App Automation Browser Automation
GroundNG
A
license
Not graded
quality
D
maintenance
An AI-powered MCP server that automates web testing workflows by enabling recording, execution, and discovery of tests through natural language prompts.
Updated 9 months ago (2025-11-29 11:31 UTC)
67
Apache 2.0
mcp-playwright-test
Testing & QA Tools App Automation Developer Tools
owen-whf
A
license
Not graded
quality
D
maintenance
An MCP server that automates Playwright-based UI and API testing, supporting test case generation from requirements or API specs, and execution with detailed reports.
Updated a year ago (2025-07-10 02:20 UTC)
17
1
MIT
Glance
Browser Automation Web Scraping Testing & QA Tools
DebugBase
A
license
C
quality
D
maintenance
An MCP server that gives Claude Code real browser control for web automation, testing, and screenshots.
Updated 5 months ago (2026-04-16 13:41 UTC)
32
55
151
MIT
web-automation-mcp
Browser Automation Web Scraping
ssql2014
F
license
B
quality
D
maintenance
An MCP server that enables Claude Code CLI to interact with Cloud Desktop, ChatGPT, and Gemini web interfaces through browser automation.
Updated a year ago (2025-07-21 23:16 UTC)
6
-

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/404Yeti/MCP-QA-Server'

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

MCP QA Server

Quick Start

Adding to Claude Desktop

CLI Commands

mcp-qa init

mcp-qa validate

mcp-qa list-modules

MCP Tools

Testing Modules

Web/UI (web)

API (api)

CLI (cli)

VM Environment (vm)

WordPress (wordpress)

Performance (performance)

Integration (integration)

Configuration

Schema

Module Config Examples

Report Formats

Console

JSON

GitHub Actions

Error Reporting

Development

Architecture

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`mcp-qa init`

`mcp-qa validate`

`mcp-qa list-modules`

Web/UI (`web`)

API (`api`)

CLI (`cli`)

VM Environment (`vm`)

WordPress (`wordpress`)

Performance (`performance`)

Integration (`integration`)