Enables uploading and managing test cases in TestRail: checking credentials and configured defaults, listing projects, suites, sections (as a tree, with text search), and existing cases, inspecting custom case fields and their required dropdown options, and creating cases with titles, preconditions, references, step-by-step actions and expected results. Also supports uploading saved case-pack JSON files with embedded base64 images attached to steps, with dry-run previews before anything is created.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@testrail-mcp add test cases for CSV export with steps to the Reports > Export section"
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.
An MCP server that lets Claude upload test cases to TestRail.
You describe the feature to Claude in a chat; Claude writes the test cases there. This server's only job is to talk to TestRail: find the right section, check required fields, and create the cases (with step-by-step actions and expected results). No user-story form, no screenshot area, no AI key — the chat is the interface.
Python, one dependency (mcp); HTTP calls use the standard library.
Your TestRail URL, email and API key are read only from environment variables set in your MCP client's config. Nothing personal is stored in this repository.
Tool | What it does |
| Confirms the credentials work and shows the configured defaults |
| Active projects |
| Suites in a project |
| Sections as a tree ( |
| Existing cases in a section, to avoid duplicates |
| Custom case fields for your template, with dropdown options and which are required |
| Creates cases: title, preconditions, refs, steps ( |
| Uploads a saved |
testrail_add_cases and testrail_upload_case_file accept dry_run: true to preview exactly what
would be sent without creating anything. Dropdown fields accept the option label
(e.g. "Not Automated") or its numeric id.
Related MCP server: QA Studio MCP Server
Requires Python 3.10+ and uv (or plain pip).
git clone https://github.com/<your-github-user>/testrail-mcp.git
cd testrail-mcp
uv sync # or: pip install -e .Open Settings → Developer → Edit Config in Claude Desktop and add a server entry
(full example: examples/claude_desktop_config.json):
{
"mcpServers": {
"testrail": {
"command": "uv",
"args": ["--directory", "C:\\path\\to\\testrail-mcp", "run", "testrail-mcp"],
"env": {
"TESTRAIL_URL": "https://yourcompany.testrail.io",
"TESTRAIL_USER": "you@company.com",
"TESTRAIL_API_KEY": "your-api-key",
"TESTRAIL_PROJECT_ID": "1"
}
}
}
}Restart Claude Desktop. The tools then appear in your chats.
The config file lives only on your computer, so your key never goes into git. Use a TestRail API key (TestRail → My Settings → API Keys), not your password, so you can revoke it any time.
Variable | Required | Meaning |
| yes | e.g. |
| yes | Email you sign in to TestRail with |
| yes | TestRail → My Settings → API Keys |
| recommended | Default project |
| no | Default suite (multi-suite projects) |
| no | Default section for new cases |
| no | Case template, default |
| no | JSON of custom field values applied to every new case, e.g. |
| no | Default |
| no | Default |
If TestRail says a field "is a required field", ask Claude to run testrail_get_fields and then either
pass the value per upload or put it in TESTRAIL_DEFAULT_FIELDS.
Example prompts:
Write test cases for the CSV export story below, then add them to the "Reports > Export" section with refs PROJ-123.
Upload
C:\Users\me\Downloads\export-cases.jsonto section 42.
Claude will look up the section, check required fields, show you the cases, and create them. Each result links to the new case in TestRail.
testrail_upload_case_file reads this JSON shape (images are optional and embedded as base64):
{
"format": "testrail-case-pack",
"version": 1,
"refs": "PROJ-123",
"section_id": null,
"fields": {"custom_automation_type": "Not Automated"},
"image_placement": "expected",
"notes": ["anything to double-check before uploading"],
"cases": [
{
"title": "Verify CSV export downloads a file",
"preconditions": "User is signed in",
"steps": [
{"content": "Open Reports and click Export CSV", "expected": "A .csv file downloads", "images": ["img1"]}
]
}
],
"images": {"img1": {"name": "export.png", "mime": "image/png", "data": "<base64>"}}
}section_id and fields in the call override the file; the file overrides the environment defaults.
uv sync --extra dev
uv run pytestTests run against an in-memory fake TestRail (tests/fake_testrail.py), so they never touch a real
instance.
MIT
Create test cases in a TestRail section.
cases: [{"title": "Verify ...", "preconditions": "...", "refs": "optional per-case refs", "steps": [{"content": "one action", "expected": "one expected result"}]}] section_id: defaults to TESTRAIL_SECTION_ID. refs: references applied to every case (e.g. a story key), unless a case sets its own. fields: custom field values for every case, e.g. {"custom_automation_type": "Not Automated"}. Dropdowns accept the option id or its label. Merged over TESTRAIL_DEFAULT_FIELDS. dry_run: return the payloads that would be sent, without creating anything.
| Name | Required | Description | Default |
|---|---|---|---|
| refs | No | ||
| cases | Yes | ||
| fields | No | ||
| dry_run | No | ||
| project_id | No | ||
| section_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose meaningful traits: dry_run returns payloads without creating anything, refs/fields semantics, and environment-variable defaults. But it says nothing about permissions, rate limits, duplicate handling, or failure modes for a 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?
Purpose is front-loaded in one sentence, followed by tight per-parameter annotations with a compact JSON example for cases. No filler sentences, though the dense param block is slightly terse rather than maximally scannable.
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 6-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, this is close to complete — payload shape, defaults, and dry-run behavior are all covered. The gap is project_id and any error/permission context, which keeps it from a 5.
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 does the heavy lifting and largely succeeds: it documents cases (with a full nested example), section_id, refs, fields (including dropdown id-or-label handling), and dry_run. Only project_id is left completely undocumented in both schema and description, which caps this below 5.
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 gives a specific verb and resource ('Create test cases in a TestRail section'), which is clearly distinct from siblings like testrail_list_cases or testrail_upload_case_file. It stops short of naming an alternative explicitly, so it earns a solid 4 rather than a 5.
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 supplies useful operational context — section_id falls back to TESTRAIL_SECTION_ID, fields merge over TESTRAIL_DEFAULT_FIELDS, and dry_run lets you preview without writing. However it never says when to prefer this tool over a sibling (e.g. testrail_upload_case_file) or what prerequisites exist, leaving usage only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the TestRail credentials work and show the configured defaults (project, suite, section, fields).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden alone. It does disclose that the call returns configured defaults, which is real behavioral information, but it says nothing about what happens on failure (error versus partial result), whether it makes any state change, or what auth/config must already exist.
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?
A single front-loaded sentence that states the action and the return payload with no filler. Every clause earns its place.
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 zero-param diagnostic with no output schema, the description covers the essentials: what it verifies and what it returns. It would be stronger if it hinted at the failure path an agent should expect, but nothing needed to invoke it correctly is missing.
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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is no schema surface to document and the description correctly adds no redundant parameter talk.
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 gives a specific verb (check) and resource (TestRail credentials) and even previews the payload (configured defaults: project, suite, section, fields). That is enough to separate it from siblings like testrail_list_projects or testrail_list_suites, though it never explicitly contrasts itself with them.
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?
There is no statement of when to run this versus the other testrail_* tools, no mention of prerequisites, and no exclusions. The verification intent is inferable from 'check the credentials work', but the description stops short of telling an agent to use it as a preflight step or in what failure situations to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Custom case fields for the configured template: name, label, type, required, and dropdown options.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | ||
| required_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at return content but says nothing about read-only safety, authentication, rate limits, pagination, or whether the template is resolved implicitly.
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?
A single compact clause with no filler; the returned fields are front-loaded. However, the fragmentary style with no verb makes it less useful than a complete sentence would be at the same length.
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?
An output schema exists, so return values need not be explained, but the description still leaves both undocumented parameters and the tool's usage context unresolved. For a two-parameter tool with 0% schema coverage, more is needed.
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% and neither project_id nor required_only is mentioned in the description. The phrase 'configured template' weakly implies project scoping, but the filtering behavior of required_only is entirely undocumented, so the description does not compensate for the coverage 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?
The description names the resource (custom case fields for the configured template) and enumerates the returned attributes (name, label, type, required, dropdown options), but it is a noun phrase with no verb and never states the action is a retrieval. It does not differentiate this from sibling list tools like testrail_list_cases or testrail_list_suites.
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?
There is no guidance on when to call this tool, what a 'configured template' means, or how it relates to alternatives such as listing cases or suites. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List existing cases (id, title, refs) in a section, e.g. to avoid creating duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| suite_id | No | ||
| project_id | No | ||
| section_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'List existing' implies a read-only operation, but it does not explicitly state no side effects, permission requirements, or pagination behavior; the output schema covers return shape but not operational traits.
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?
A single sentence that front-loads the action and resource, then adds a compact parenthetical return summary and use case. Every part earns its place with no wasted wording.
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 simple list tool and an output schema exists, so return details need not be explained. However, with no annotations and 0% parameter description coverage, the description omits context for the optional IDs and does not state that the operation is safe/read-only, making it only minimally adequate.
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% with 3 parameters. The description ties the operation to a 'section', which corresponds to the required section_id, but it says nothing about the optional suite_id and project_id, leaving 2 of 3 parameters without semantic context.
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 ('List'), resource ('existing cases'), scope ('in a section'), and returned fields ('id, title, refs'). This clearly distinguishes it from sibling tools like testrail_add_cases and the various list_* metadata tools.
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?
Provides a concrete usage context: 'e.g. to avoid creating duplicates,' which implies calling this before testrail_add_cases. It does not explicitly state exclusions or name alternative list tools, but the main when-to-use guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active TestRail projects (id, name, suite_mode).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does add one behavioral fact beyond the schema — that only active projects are returned, implying archived ones are excluded — but says nothing about authentication requirements, pagination, or result volume for what may be a long list.
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?
A single front-loaded sentence with no filler; every clause earns its place.
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 zero-parameter read-only listing with an output schema present, the description covers what the agent needs to select and call it. The missing piece is routing guidance relative to its many list_* siblings.
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?
The tool takes zero parameters, so the baseline is 4. The parenthetical field list is return-value information rather than parameter guidance, so it does not raise the score further.
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 (List) and resource (active TestRail projects) plus the returned fields, so the purpose is unambiguous. It does not, however, distinguish itself from sibling list tools such as testrail_list_suites or testrail_list_sections, which the agent must infer from the resource name alone.
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?
There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The word 'active' hints at a filter but the description never explains when an agent should reach for this tool over the other list_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sections as a tree with full paths ("Parent > Child"). search filters by text in the path.
project_id / suite_id default to TESTRAIL_PROJECT_ID / TESTRAIL_SUITE_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| suite_id | No | ||
| project_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return structure (tree with full paths) and default parameter resolution from env vars, which is useful, but says nothing about read-only safety, pagination, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core purpose and format front-loaded, followed by the parameter behavior. No wasted words.
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?
An output schema exists, so return values need not be explained, and the description still notes the tree format. For a read-only list tool with optional params, this is nearly complete, though sibling differentiation is absent.
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 must compensate and it largely does: it explains `search` ('filters by text in the path') and the default resolution for `project_id`/`suite_id` from TESTRAIL_PROJECT_ID/TESTRAIL_SUITE_ID. It still doesn't describe what a suite vs project id selects, so not a 5.
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+resource ('List sections') and adds the output shape ('as a tree with full paths'). It does not explicitly differentiate from sibling testrail_list_suites, so it stops short of a 5.
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?
No explicit when-to-use or when-not guidance versus siblings like testrail_list_suites or testrail_list_cases. Usage is only implied by the resource name and the mention of defaults.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the test suites in a project. project_id defaults to TESTRAIL_PROJECT_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose one useful behavioral trait the schema does not: project_id falls back to the TESTRAIL_PROJECT_ID environment variable when omitted (the schema merely shows default null). However, it says nothing about read-only nature, pagination, ordering, or scope of returned suites.
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 short sentences, zero filler, with the core action front-loaded and the parameter default immediately following. Nothing needs trimming.
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?
An output schema exists, so return values need not be described, and the single optional parameter's fallback behavior is explained. Given the low complexity, the description is nearly sufficient, lacking only read-only/scope context that an agent would find helpful.
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% and the schema's default of null is uninformative, so the description's note that project_id defaults to TESTRAIL_PROJECT_ID adds real meaning beyond the schema. With only one optional parameter, this single clarification largely covers the semantic 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 ("List") and resource ("test suites") scoped to a project, which naturally distinguishes it from siblings like testrail_list_sections and testrail_list_cases. It does not, however, explicitly reference any sibling or state what makes this list different from the others.
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?
There is no when-to-use or when-not-to-use guidance, and no mention of the sibling tools that also list project-scoped resources. The agent must infer from the name alone that this is the suites variant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a saved testrail-case-pack .json file from this computer (full path). Embedded images in the file are attached to their steps. section_id overrides the file's section_id, which overrides TESTRAIL_SECTION_ID.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| fields | No | ||
| dry_run | No | ||
| project_id | No | ||
| section_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two useful traits: embedded images are attached to their steps, and section targeting follows an override precedence. It omits the important operational behaviors for a write tool, such as whether cases are created vs overwritten, what dry_run returns, permission/auth requirements, and error/conflict handling.
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 compact sentences, front-loaded with the core action, and the precedence rule is stated tersely without wasted words. Slightly dense grammar in the final sentence, but no 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 5-parameter mutation tool with no annotations, no output schema, and no parameter documentation in the schema, the description leaves too much unspecified: dry_run semantics, fields contents, project_id role, and expected results are all absent.
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% across 5 parameters, so the description must compensate. It clarifies only 'path' (full path on this computer) and touches 'section_id' via the precedence rule; 'fields', 'dry_run', and 'project_id' receive no explanation anywhere.
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: uploading a saved 'testrail-case-pack .json' file from a local path. That is clearly distinct from sibling testrail_add_cases, though the description never explicitly contrasts the two, so the differentiation is inferred rather than stated.
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?
Usage is implied by the file-pack framing and the section_id precedence chain (section_id > file's section_id > TESTRAIL_SECTION_ID), which tells the agent how targeting resolves. However, there is no explicit when-to-use versus testrail_add_cases or when to prefer dry_run, leaving the choice to inference.
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.1.0testrail_add_casestestrail_check_connectiontestrail_get_fieldstestrail_list_casestestrail_list_projectstestrail_list_sectionstestrail_list_suitestestrail_upload_case_fileScored across 8 tools
Tools mostly target distinct resources and actions (list sections, list cases, get fields, add cases, etc.). The only mild overlap is between testrail_add_cases and testrail_upload_case_file, both of which create cases, but their descriptions clearly differentiate structured input from file upload.
All tools use the consistent testrail_ prefix followed by a verb_noun pattern (testrail_list_sections, testrail_add_cases, testrail_get_fields), written uniformly in snake_case.
Eight tools are well-scoped for a TestRail case-authoring integration, covering listing hierarchy, checking connectivity, inspecting fields, and adding cases without unnecessary bloat.
The surface covers listing and creating test cases, but lacks update and delete operations and single-case retrieval, which are notable gaps for typical TestRail case management workflows.
Create and manage test cases, test runs and results in Testiny from your AI assistant.
Direct access to Cypress tests results and accessibility reports in your AI workflow.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Writes adversarial test suites for AI-built code. Your agent's test engineer.
