在编码代理宣布网页更改完成之前，为其提供独立的 QA 证据：扫描页面、检查 UI、生成聚焦的 Playwright 复现，然后审查执行结果。
npx -y @qualitymax/qmax-mcp这四个本地工具不需要 QualityMax 账户、API 密钥或托管服务。
让支持 MCP 的代理扫描它更改的 URL，或运行本地 CLI：
npx -y @qualitymax/qmax-mcp scan https://example.com --format markdown报告包含分级摘要、发现的问题、具体的复现步骤和建议的修复。一条命令即可针对已检入、无依赖的测试夹具运行所有四个工具——请参阅可复现演示。
所有九项检查都在单次页面加载中运行。传递 checks 以运行子集。
检查 | 报告内容 |
| JavaScript 错误、警告和失败的请求 |
| 损坏和重定向的链接，最多 |
| 缺少替代文本、未标记的控件、无名称的交互元素、标题结构 |
| 核心 Web 指标：LCP、CLS、TTFB、FCP |
| 标题和元描述 |
| CSP、HSTS、 |
| 缺少 |
| HTTPS 页面上的 HTTP 子资源和表单操作，分为浏览器阻止的活动和被动 |
| 传输字节、请求数、阻塞渲染的资源、过大和未压缩的资产、第三方成本 |
scan_url 还返回一个 metrics 块，其中包含测量的核心指标和页面重量明细，包括最慢的请求。该块中明确说明了两个限制，而不是隐藏：不测量 INP，因为它需要真实的用户交互，并且核心指标来自扫描机器上的一次冷加载，而非现场数据。设置 weightBudget 以根据您自己的性能预算进行扫描。
--format markdown 以结果概览开头，因此人类或代理可以在阅读任何发现之前看到问题所在：
等级：🔴 F (0 / 100) · 发现 17 个问题
░░░░░░░░░░░░░░░░░░░░░░░░0 / 100
类别
问题
最严重
控制台错误
██░░░░░░░░1🔴 高
无障碍
████████░░3🔴 高
安全标头
██████████4🟠 中
Cookie 和跟踪器
█████░░░░░2🟠 中
页面重量
██████████4🟠 中
每个条都按该次运行中最嘈杂的类别进行缩放，因此最高的条是需要首先修复的内容。当 weight 运行时，测量部分还会归因字节：
script ████████████████ 18 kB
document ██░░░░░░░░░░░░░░ 3 kB
stylesheet ██░░░░░░░░░░░░░░ 1 kB
image ░░░░░░░░░░░░░░░░ 417 B然后每个发现都附带其严重性、可复制粘贴的复现步骤和建议的修复。使用 --format json 以结构化输出获取相同的数据。
Related MCP server: ProdPoke MCP Server
工具 | 本地能力 | 需要审查的边界 |
| 扫描 URL 以获取控制台、网络、链接、无障碍、SEO、安全标头、Cookie/跟踪器、混合内容、页面重量和核心 Web 指标发现。 | 它会发出出站请求，并且可以写入截图。 |
| 返回页面结构和角色/名称定位器候选，可选地使用 Playwright 存储状态文件来访问需要认证的页面。 | 它会发出出站请求，并可能读取明确选定的包含凭据的工作区文件。 |
| 编写确定性的、包含在工作区内的 Playwright 复现。 | 它写入 |
| 执行一个本地 Playwright 测试并返回结构化状态。 | 它执行代码并写入受控工件；默认情况下，它需要接受一个绑定摘要的 MCP 人工审批提示。 |
本地服务器不需要账户。托管代理模式 是用于账户支持的 QualityMax 功能的单独可选连接；除非需要该功能，否则不要添加它。
使用 browserContext.storageState() 保存已登录的 Playwright 上下文，将该文件保留在 gitignore 中，并传递其相对于活动工作区的路径：
{
"url": "https://example.com/account",
"storageStatePath": "playwright/.auth/user.json"
}inspect_page 在首次导航之前将状态加载到其一次性浏览器上下文中。路径必须解析为工作区内的常规文件；拒绝绝对路径、路径遍历、符号链接逃逸和超过 10 MB 的文件。不会返回状态路径和凭据值，但会返回检查的页面结构，该结构本身可能包含私有账户数据。请相应处理状态文件和工具结果，并使用仅包含被检查应用程序所需凭据的专用状态文件。Playwright 存储状态涵盖 Cookie、本地存储以及可选的 IndexedDB；它不会持久化会话存储。
为您的客户端复制一份现成的、无需凭据的配置以及随附的指令文件：
Claude Code | Cursor | Codex | VS Code |
代理设置指南 解释了预期的审批界面，并提供了通用的 stdio 配置。根目录下的 AGENTS.md 是可移植的指令：收集证据、报告未解决的失败，并在修改文件或执行提供的代码之前请求批准，除非服务器明确宣传无人值守模式。
对于可信、隔离的自动化环境，其中没有人能回答 MCP 提示，请使用显式的 --unattended 标志启动服务器：
{
"mcpServers": {
"qmax": {
"command": "npx",
"args": ["-y", "@qualitymax/qmax-mcp", "--unattended"]
}
}
}对于 Codex TOML，使用 args = ["-y", "@qualitymax/qmax-mcp", "--unattended"]。此进程启动时的选择加入授权该服务器处理的每次 run_playwright_test 调用；它有意不作为工具参数或环境变量提供。服务器向代理通告活动模式，打印 UNATTENDED 启动警告，并在每次执行时返回 approval.mechanism: "unattended-cli-opt-in-v1"。确切的测试仍然会被快照和摘要检查，现有的工作区、环境、超时、取消和输出控制仍然有效。
服务器会告知连接的代理三个独立的 QualityMax 工具，这些工具覆盖了这四个工具未涵盖的 QA 工作。它们是独立的程序——qmax-mcp 不会安装、运行、捆绑或代理其中任何一个，并且它们都不需要 QualityMax 账户。代理被指示仅在其触发条件出现时提及一个，并且只提及一次，然后由您决定是否运行它。
工具 | 使用情况 | 命令 | 适用场景 |
9lives (MIT) |
| 一个曾经通过的 Playwright 规格在变更后变红，且失败看起来像是漂移。修复定位器，而不是削弱断言。 | |
qualitymax-grader (Apache-2.0) |
| 规格即将提交，或套件以测试质量而非通过与否来评判。离线 A-F 评分，无需模型或网络。 | |
free-qa-skills (Apache-2.0) | install from skills.sh | QA 请求针对的是仓库而非运行中的 URL，或代理没有可用的 MCP 服务器。 |
它们与本地工具共同构成一个循环：scan_url 发现失败，generate_playwright_repro 编写规格，qualitymax-grader 在规格落地前进行评分，run_playwright_test 在服务器选定的授权模式下执行它，而 9lives 在后续变更导致漂移时进行修复。
本地扫描基于网络。私有目标默认被拒绝；allowPrivateNetwork: true 仅是对狭窄回环目标的调用方明确同意。
生成的复现文件保存在受控的工作区目录中。测试运行使用最小化环境和受控的产物目录。
默认情况下，run_playwright_test 在执行前使用 MCP 表单引导。服务器向客户端显示目标、副作用和 SHA-256 摘要，并且仅在客户端返回针对该确切摘要的已接受人工批准后才运行。不支持表单引导的客户端默认失败关闭；仅由调用方提供的布尔值不被接受为证明。--unattended 是面向隔离自动化的显式进程级例外，允许提供的代码以本地用户的文件系统和网络权限运行，无需再次人工提示。
发布对比 记录了 TestSprite、BrowserStack、mabl 和 Momentic 的带日期的一手能力参考。这是一个事实性的边界对比，而非排名。
本地工具是开放、本地优先的层。托管 QualityMax 是面向工作区支持的项目、测试用例、脚本和可观测性工作流的显式代理：
QUALITYMAX_API_KEY="<your-api-key>" npx -y @qualitymax/qmax-mcp proxy仅在需要仅托管能力时才配置代理。Bearer 凭据仅发送到固定的 https://app.qualitymax.io/api/mcp/ 端点；端点覆盖和重定向均被拒绝。
对于非敏感的使用和文档支持，请使用 GitHub Issues。请勿在公开 issue 中报告漏洞；请遵循仓库的安全策略。发布检查清单 包含任何公开公告前所需的所有者检查。
运行时要求 Node 22.13.0 或更高版本。
npm install
npx playwright install chromium
npm run check
npm run demonpm run demo 启动一个无依赖的本地夹具，默认打印 Markdown 质量回执，并将其生成的复现文件和 Playwright 产物保留在 .qmax-mcp/ 下以供检查。使用 npm run demo -- --format json 获取机器可读的回执。
0.4.0 之后的候选工作——以及其必须遵守的边界——记录在路线图中。它是一个方向，而非交付承诺；已发布的变更列在变更日志中。
包在何处列出、刻意不在何处列出，以及每个渠道接受什么，均记录在分发渠道清单中。
server.json 是规范的 MCP Registry 清单。npm run validate:registry 在不发布任何内容的情况下，对照官方模式检查它。使用 npm run version:sync -- <semver> 将所有公开元数据面——package.json、package-lock.json、server.json、smithery.yaml 和 src/metadata.ts——一起更新；npm run check 验证它们是否一致，并在漂移时失败，而 npm publish 仅限于基于来源的发布工作流。发布工作流和回滚程序记录在发布运行手册中。
MIT — 版权所有 (c) 2026 QualityMax。
Generate a minimal Playwright test from a scan finding, URL, or plain-English goal and write it below the approved workspace directory .qmax-mcp/repros. outputPath must be relative; existing files require overwrite:true after review. No outbound network request is made by generation.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| goal | No | ||
| finding | No | ||
| testName | No | ||
| overwrite | No | ||
| outputPath | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It adds substantial behavior beyond the destructiveHint annotation: it states the exact write location, mandates a relative outputPath, requires overwrite:true to replace existing files, and explicitly discloses that no outbound network request occurs. This safely frames a destructive write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full message: the first front-loads the primary action and inputs, and the second adds the critical constraints. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description covers the key operational risks: destination, relative path, overwrite behavior, and lack of network access. It does not describe the return value or whether outputPath has a default, but the missing details are minor relative to what is provided for a moderately complex, destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for all six parameters. It does clarify url/goal/finding as alternative input sources and gives explicit constraints for outputPath and overwrite, but it leaves testName and the internal structure of the finding object unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Generate a minimal Playwright test...' and clearly names the output destination. It distinguishes itself from siblings like run_playwright_test by making clear it writes reproductions rather than executing them, and lists the three accepted input forms (scan finding, URL, plain-English goal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when the goal is to generate a reproduction from a finding, URL, or plain-English goal. It does not explicitly name alternative siblings or state when not to use it, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read page structure through outbound browser network requests and return headings, forms, buttons, links, inputs, role/name selectors, and data-testid candidates. storageStatePath may name a workspace-relative Playwright storage-state file for authenticated pages; its credentials are loaded into the throwaway browser context and never returned. Because returned page content may be private, authenticated inspection also requires acknowledgePrivateContent:true as explicit caller consent. Does not intentionally modify the target or local filesystem. allowPrivateNetwork:true is limited to deliberate loopback development targets.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| viewport | No | ||
| includeForms | No | ||
| storageStatePath | No | ||
| allowPrivateNetwork | No | ||
| includeAccessibilityTree | No | ||
| acknowledgePrivateContent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses credential handling ('loaded into the throwaway browser context and never returned'), caller consent expectations, privacy implications, the non-modification guarantee, and the loopback-only private-network restriction. These are meaningful behavioral details not available in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears first, followed by safety and consent details in logical order. Every sentence adds needed information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only inspection tool with no output schema, the description covers the essential invocation context, safety semantics, and the categories of returned elements. It does not describe the result envelope, limits, failure behavior, or the full meaning of every toggle, but the operative constraints are well established.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden for parameters. It adds real meaning for storageStatePath, acknowledgePrivateContent, and allowPrivateNetwork. The remaining parameters (url, viewport, includeForms, includeAccessibilityTree) are only conveyed by their names and type constraints, so the description does not fully compensate for the absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action and resource: 'Read page structure ... and return headings, forms, buttons, links, inputs, role/name selectors, and data-testid candidates.' This clearly identifies what the tool produces. However, it does not explicitly differentiate inspect_page from sibling tools like scan_url, so it falls short of the top rubric point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable context for the main conditional parameters: storageStatePath is for authenticated pages, acknowledgePrivateContent is required as consent because content may be private, and allowPrivateNetwork is limited to deliberate loopback development. It does not name alternatives or specify when not to use inspect_page, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute supplied local Playwright code or a local test file. This is a code-execution and artifact-writing boundary: qmax-mcp first requires an MCP human-approval elicitation bound to the exact test digest. The runner may make outbound network requests requested by the test.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| headed | No | ||
| baseUrl | No | ||
| browser | No | ||
| testPath | No | ||
| timeoutMs | No | ||
| allowedEnv | No | ||
| wallClockTimeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive, open-world, and non-idempotent. The description adds valuable beyond-annotation context: an MCP human-approval step tied to the exact test digest, artifact-writing behavior, and the possibility of outbound network requests. This meaningfully clarifies the risk profile without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each pulling weight: the first states the action, the second flags the approval boundary, and the third discloses network behavior. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 8 parameters, one nested object, no output schema, and zero parameter descriptions. The description covers execution intent and risk but omits parameter semantics and any indication of return values or artifacts, leaving important gaps for an agent deciding how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps to code and testPath via 'supplied local Playwright code or a local test file.' The other six parameters — headed, baseUrl, browser, timeoutMs, allowedEnv, and wallClockTimeoutMs — receive no elaboration, leaving the agent without semantic guidance for most inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Execute supplied local Playwright code or a local test file.' It further labels the tool as a 'code-execution and artifact-writing boundary,' which clearly separates it from read-oriented siblings like scan_url and inspect_page and from generation-focused generate_playwright_repro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for running user-supplied Playwright code or test files, but it never states when to prefer this over the sibling tools or when not to use it. No alternatives or exclusions are mentioned, so the agent must infer selection criteria from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a URL with outbound browser and HTTP network requests for console errors, links, accessibility, Core Web Vitals, SEO, security headers, cookie and tracker privacy, mixed content, and page weight. storageStatePath may name a workspace-relative Playwright storage-state file so the checks can run on an authenticated page; its credentials are loaded into the throwaway browser context and never returned. Because returned findings may reflect private content, authenticated scans also require acknowledgePrivateContent:true as explicit caller consent. This may write a local screenshot artifact when screenshot:true. Set format:"markdown" for a shareable graded report, or format:"issue" to render each finding as a self-contained ticket block (summary, steps, expected, actual, environment) ready to paste into a tracker; minSeverity filters that export. baseline takes a previous scan result, or a workspace-relative path to one, and adds a delta reporting which findings are new, fixed, and unchanged — use it to answer whether a change introduced anything rather than comparing two results by eye. allowPrivateNetwork:true is limited to deliberate loopback development targets.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| checks | No | ||
| format | No | ||
| baseline | No | ||
| maxLinks | No | ||
| viewport | No | ||
| screenshot | No | ||
| minSeverity | No | ||
| weightBudget | No | ||
| storageStatePath | No | ||
| allowPrivateNetwork | No | ||
| acknowledgePrivateContent | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects and sensitive behavior beyond the annotations: outbound network activity, auth credentials loaded into a throwaway context and never returned, explicit consent requirement, possible screenshot artifact, and loopback restriction on allowPrivateNetwork. Consistent with readOnlyHint=false, openWorldHint=true, and idempotentHint=false; no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but front-loaded and information-dense; every sentence adds operational value for a 12-parameter tool. The length is justified by the tool's complexity, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers authentication, privacy, output formats, baselines, and side effects, which is strong for a tool with no output schema. It is not flawless: three parameters are left unexplained and the default/JSON return shape is not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining format values, baseline behavior, minSeverity, storageStatePath, acknowledgePrivateContent, allowPrivateNetwork, and screenshot. However, maxLinks, viewport, and weightBudget have no explanatory text in either the schema or description, leaving a small but real gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it inspects a URL via outbound browser and HTTP requests, and enumerates the exact categories of checks. This clearly identifies it as a scanner rather than the sibling playwright repro/page-inspection tools, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete context for non-obvious options: markdown for shareable reports, issue for tracker tickets, baseline for change-introduced findings, and acknowledgePrivateContent for authenticated scans. It does not explicitly contrast scan_url with sibling tools or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.9.0inspect_page2 fields changedInput schema / properties / acknowledgePrivateContentAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Input schema / properties / storageStatePathAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}run_playwright_test2 fields changedInput schema / properties / allowedEnv / additionalProperties / maxLengthAdded value: +8192Input schema / properties / allowedEnv / propertyNames / maxLengthAdded value: +128scan_url6 fields changedInput schema / properties / acknowledgePrivateContentAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Input schema / properties / baselineAdded value: +{
+ "anyOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ }
+ ]
+}Input schema / properties / checks / items / enumAdded value: +[
+ "console",
+ "links",
+ "accessibility",
+ "performance",
+ "seo",
+ "security_headers",
+ "cookies",
+ "mixed_content",
+ "weight"
+]Input schema / properties / format / enumPrevious value: -[
- "json",
- "markdown"
-]New value: +[
+ "json",
+ "markdown",
+ "issue"
+]Input schema / properties / minSeverityAdded value: +{
+ "enum": [
+ "critical",
+ "high",
+ "medium",
+ "low",
+ "info"
+ ],
+ "type": "string"
+}Input schema / properties / storageStatePathAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}v0.4.2generate_playwright_reproinspect_pagerun_playwright_testscan_urlScored across 4 tools
scan_url and inspect_page both involve browser access but are clearly differentiated: scan_url is a full quality audit with findings and reports, while inspect_page returns structural selectors and page elements. generate_playwright_repro creates tests and run_playwright_test executes them, so overall tool boundaries are clear, though one could initially confuse scan_url with inspect_page.
All tools consistently use a verb_object snake_case pattern: scan_url, inspect_page, generate_playwright_repro, run_playwright_test. There are no vague generic verbs or mixed conventions, making the intent of each tool predictable from its name.
Four tools is well within the ideal 3-15 range and each tool represents a distinct high-level QA workflow: auditing a URL, inspecting page structure, generating a reproduction, and executing a test. The count feels appropriately scoped rather than thin or bloated.
The core QA workflow is covered: scan a URL for issues, inspect page structure, generate a Playwright reproduction, and run Playwright tests. Minor gaps exist such as managing or listing generated repro artifacts, but these do not create dead ends for the server's apparent purpose.
Read-only web QA agent: scans a site in a real browser and returns evidence-backed findings
Browser-based QA for AI-built software. Test pages with real browsers via agents.
Browser-backed QA with evidence and fix-ready reports for coding agents.
Captured web interfaces, screenshots, flows and structured evidence for AI coding agents.
