The TestRail MCP Server enables comprehensive management of TestRail entities directly from AI clients, covering the full test lifecycle:
Projects
List all projects and retrieve specific project details.
Test Suites
List, retrieve, create, and update test suites.
Test Cases
Full CRUD operations (get, list with filtering/pagination, create, update, delete)
Bulk update multiple cases simultaneously
Copy or move cases between sections
View case change history
Get available case types and fields
Import BDD/Gherkin .feature files and export test cases as .feature files
Sections
Retrieve, create, move, update, and delete sections (with soft delete support), with pagination.
Test Runs
List, retrieve, create, and update test runs.
Tests
List tests in a run (with pagination) and retrieve full test details.
Test Results
Retrieve results by test, case within a run, or entire run
Add results for individual or multiple test cases at once
Test Plans
List all plans, create new plans, add entries to plans, and add runs to plan entries.
Milestones
List all milestones for a project.
Shared Steps
List all shared steps for a project with filtering and pagination.
Provides comprehensive tools for managing TestRail resources, including test cases, projects, suites, runs, sections, tests, results, plans, and milestones.
Click on "Install 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 Server list the test cases for project 1"
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.
This Model Context Protocol (MCP) server provides tools for interacting with TestRail directly from Claude AI and other MCP-supported clients like Cursor. It allows you to manage test cases, projects, suites, runs, and more without leaving your conversation with the AI.
The TestRail MCP server provides the following tools:
Category | Tools |
Projects |
|
Suites |
|
Cases |
|
Sections |
|
Runs |
|
Tests |
|
Results |
|
Plans |
|
Milestones |
|
Shared Steps |
|
Related MCP server: TestRail MCP Server
You can connect this MCP server by setting like the below. This method uses npx to automatically download and run the latest version of the package, eliminating the need for local installation.
// Example configuration using npx
{
"mcpServers": {
"testrail": {
"command": "npx",
"args": ["@bun913/mcp-testrail@latest"],
"env": {
"TESTRAIL_URL": "https://your-instance.testrail.io", // Replace with your TestRail URL
"TESTRAIL_USERNAME": "your-email@example.com", // Replace with your TestRail username
"TESTRAIL_API_KEY": "YOUR_API_KEY" // Replace with your TestRail API key
}
}
}
}spawn npx ENOENT / spawn node ENOENT (commonly on macOS): your MCP host (Cursor, Claude Code, Claude Desktop, …) cannot find npx or node at process-spawn time. The chat UI usually surfaces this as a generic "MCP server doesn't work" with no useful detail; the per-server log is the diagnostic source of truth.
Why it happens on macOS: GUI apps launched from the Dock, Spotlight, or Finder inherit launchd's minimal PATH (/usr/bin:/bin:/usr/sbin:/sbin). If you installed Node via a version manager (nvm, asdf, mise, fnm, Volta) or Apple Silicon Homebrew (/opt/homebrew/bin/), npx lives outside that PATH — only your shell startup file (~/.zshrc / ~/.bashrc) adds it. Your terminal works because the shell ran the startup file; the GUI-app process never did.
Diagnose by checking the per-server log for spawn npx ENOENT:
Cursor: ~/Library/Application Support/Cursor/logs/<session>/window<N>/exthost/anysphere.cursor-mcp/MCP <server>.log
Claude Code / Claude Desktop: ~/Library/Logs/Claude/
Fix by replacing "npx" in your MCP config with its absolute path. Run which npx in your normal terminal:
/Users/you/.nvm/versions/node/v24.15.0/bin/npx # nvm
/opt/homebrew/bin/npx # Apple Silicon Homebrew
/usr/local/bin/npx # Intel Homebrew / system NodeThen update your MCP config:
{
"mcpServers": {
"testrail": {
"command": "/Users/you/.nvm/versions/node/v24.15.0/bin/npx",
"args": ["@bun913/mcp-testrail@latest"],
"env": {
"TESTRAIL_URL": "https://your-instance.testrail.io",
"TESTRAIL_USERNAME": "your-email@example.com",
"TESTRAIL_API_KEY": "YOUR_API_KEY"
}
}
}
}Restart your MCP client after the change. The same fix applies to every npx-launched MCP server — if mcp-testrail is failing for this reason, your other npx-launched servers are likely failing too.
Authentication issues: Check your TestRail API credentials.
Your conversation is too long: Use limit and offset parameters for test cases and sections to paginate results.
HTTP 400 errors when creating/updating test cases: TestRail projects have different templates, custom fields, and required fields. This MCP server passes your parameters directly to the TestRail API — it does not validate or transform them. If you encounter 400 errors, define your project's rules in CLAUDE.md or AGENTS.md so the LLM sends the correct parameters. For example:
# TestRail Rules for This Project
- Project ID: 1
- Always use template 2 (Separated Steps) when creating test cases
- Use `customStepsSeparated` (array of step objects)
- Do NOT send `customSteps` or `customExpected` with template 2
- Required custom fields: custom_automation_type (default: 0)
- Call `getCaseFields` at the start of a session to check available fieldsContributions are welcome! Please feel free to submit a Pull Request.
Imports/uploads a .feature file (Gherkin BDD scenario) into a TestRail section. Creates a new test case with BDD template (template_id=4) and populates the custom_testrail_bdd_scenario field. REQUIRED: sectionId, featureContent (raw Gherkin text including Feature:, Scenario:, Given/When/Then).
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID where the BDD case will be created | |
| featureContent | Yes | Raw Gherkin .feature file content (plain text) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses that it uses a specific template (template_id=4) and populates custom_testrail_bdd_scenario field. Could mention return value or side effects, but covers key mutation 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 sentences, highly concise, no extraneous information. Front-loaded with verb and resource, then adds specifics.
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?
Given low complexity (2 parameters, no output schema, no annotations), the description covers inputs and behavior adequately. Minor omission: no mention of return value (e.g., new case ID), but not essential due to simplicity.
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 covers both parameters with descriptions. The description adds meaning beyond schema by specifying featureContent must be raw Gherkin including Feature:, Scenario:, Given/When/Then, which is crucial for correct usage.
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?
Specifically describes the action: imports a .feature file into a TestRail section, creates a new test case with BDD template (template_id=4) and populates a specific field. Clearly distinguishes from sibling tools like addCase (generic case creation) and addSection.
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?
States required parameters (sectionId, featureContent) and the format of featureContent. While it doesn't explicitly mention when not to use or name alternatives, the context makes it clear this is for BDD imports only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new test case in TestRail. REQUIRED: sectionId, title. OPTIONAL: typeId, priorityId, templateId, customSteps, customExpected, customStepsSeparated, customFields, etc. Use getCaseTypes to find valid typeId values. NOTE: templateId=2 is required to use customStepsSeparated (array of step objects with 'content' and 'expected' fields). For simple text steps, use customSteps and customExpected instead. Use customFields for any additional custom fields (e.g., {custom_case_security_score: 'high'}).
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID | |
| title | Yes | Test case title | |
| typeId | No | Test case type ID | |
| priorityId | No | Test case priority ID | |
| estimate | No | Test case estimated time | |
| milestoneId | No | TestRail Milestone ID | |
| refs | No | Test case references | |
| templateId | No | Template ID (use 2 for custom_steps_separated support) | |
| customPrerequisites | No | Prerequisites | |
| customSteps | No | Test case steps | |
| customExpected | No | Expected results | |
| customStepsSeparated | No | Separated test steps array (requires template_id=2) | |
| customFields | No | Additional custom fields as key-value pairs (e.g., {custom_case_security_score: 'high'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes the creation action and parameter dependencies but does not disclose side effects, permissions, or error handling. Adequate but not exhaustive.
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?
Single paragraph is concise and covers key points. Could be slightly improved with bullet points or clearer separation of sections, but overall efficient.
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?
Given 13 parameters with full schema coverage and no output schema, the description adequately explains the core usage and parameter interplay. Missing return value info but acceptable.
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 100%, but description adds value by categorizing parameters as REQUIRED/OPTIONAL, clarifying the relationship between templateId and customStepsSeparated, and explaining customFields usage.
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 clearly states 'Creates a new test case in TestRail' and specifies required parameters (sectionId, title) and optional parameters. It distinguishes the tool from siblings like addBdd, addRun, etc., by focusing on test case creation.
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 guidance on using getCaseTypes for typeId values and explains the interplay between templateId and customStepsSeparated. However, it does not explicitly state when to avoid this tool or compare with alternatives like updateCase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new test plan in a TestRail project / TestRailプロジェクトに新しいテストプランを作成します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| name | Yes | Test plan name | |
| description | No | Test plan description | |
| milestoneId | No | Milestone ID | |
| entries | No | Test runs to include in the plan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits beyond creation, such as side effects, permissions, or idempotency.
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?
Description is short and front-loaded, but could include more useful information without being verbose.
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 creation tool with 5 parameters and no output schema, the description lacks return value info and behavioral context, leaving gaps for the agent.
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 100%, so baseline is 3. The description adds no additional meaning to parameters beyond the schema.
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 explicitly states that the tool creates a new test plan in a TestRail project, using a specific verb and resource. It clearly distinguishes from siblings like addPlanEntry and addRun.
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 guidance on when to use this tool versus alternatives, no prerequisites or context for use provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a new test plan entry to an existing test plan / 既存のテストプランに新しいテストプランエントリーを追加します
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | TestRail Plan ID | |
| suiteId | Yes | Test suite ID | |
| name | No | Plan entry name | |
| description | No | Plan entry description | |
| assignedtoId | No | User ID to assign to | |
| includeAll | No | Include all test cases | |
| caseIds | No | Specific case IDs to include | |
| configIds | No | Configuration IDs | |
| refs | No | References | |
| runs | No | Test run configurations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Adds' without mentioning return values, error conditions, permissions, or side effects. The agent has no insight into what happens beyond the action.
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 (one per language) that are very concise and front-loaded. No unnecessary words. The tool purpose is conveyed efficiently.
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?
Despite a complex schema with 10 parameters and no output schema, the description is extremely minimal. It does not explain what a test plan entry is, what required parameters (planId, suiteId) represent, or the expected outcome. Incomplete for an agent to fully understand usage.
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 100%, so each parameter is documented in the schema. The tool description adds no additional meaning to parameters. Baseline 3 is appropriate as the description does not improve or clarify parameter semantics beyond schema.
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 clearly states the action 'Adds a new test plan entry to an existing test plan', specifying the verb, resource, and context. It distinguishes from siblings like addPlan (adds a plan) and addRunToPlanEntry (adds a run to an entry).
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing plan) or when not to use it. With siblings like addRunToPlanEntry, confusion is possible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a test result for a specific test case in a test run / テスト実行内の特定のテストケースにテスト結果を追加します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| caseId | Yes | TestRail Case ID | |
| statusId | No | Status ID (1:Pass, 2:Blocked, 3:Untested, 4:Retest, 5:Fail) | |
| comment | No | Comment for the test result | |
| defects | No | Defects linked to the test result | |
| assignedtoId | No | User to assign the test to | |
| version | No | Version or build tested | |
| elapsed | No | Time spent testing (e.g., '30s', '2m 30s') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It implies a write operation but does not mention any requirements, side effects, or constraints, leaving the agent underinformed.
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 extremely concise—one sentence in English and Japanese—with no redundant information. It is front-loaded and efficient.
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?
Given 8 parameters, no output schema, and no annotations, the description is too minimal. It lacks information on return values, error handling, prerequisites, or validation rules, making it incomplete for effective use.
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 input schema documents all 8 parameters with descriptions (100% coverage). The tool description adds no additional parameter-specific meaning beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the action (adds a test result) and the target resource (specific test case in a test run). However, it does not differentiate from the sibling tool 'addResultsForCases' which may add multiple results.
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 no guidance on when to use this tool versus alternatives like 'addResultsForCases'. It simply states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds test results for multiple test cases in a test run / テスト実行内の複数のテストケースにテスト結果を追加します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| results | Yes | Array of test case results to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'adds results' but does not disclose idempotency, overwrite behavior, permissions, or error 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?
Two sentences (English and Japanese), no fluff. Front-loaded with key action and scope.
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?
Batch operation with nested array; no output schema or return value description. Lacks details on result creation behavior, error conditions, or limits.
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 100%, so description adds no extra meaning. Baseline 3 applies; the description repeats the schema's content without additional semantic value.
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?
Clearly states it adds test results for multiple test cases in a test run, distinguishing from singular variant addResultForCase. Verb+resource is specific.
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 guidance on when to use this tool vs alternatives like addResultForCase for single cases. Does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new test run in a TestRail project / TestRailプロジェクトに新しいテスト実行を作成します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| name | Yes | Test run name | |
| suiteId | No | Suite ID (required for multi-suite projects) | |
| description | No | Test run description | |
| milestoneId | No | Milestone ID | |
| assignedtoId | No | User ID to assign to | |
| includeAll | No | Include all test cases from the suite | |
| caseIds | No | Specific case IDs to include | |
| configIds | No | Configuration IDs to use | |
| refs | No | Reference/requirement IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states 'creates' without disclosing behavioral traits like idempotency, error handling, authentication requirements, or effects on existing data. This is insufficient for a mutation tool.
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 concise (two lines) and includes a bilingual version. It front-loads the purpose, but the Japanese translation is redundant for English-centric AI agents.
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?
Given 10 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, error scenarios, or provide example usage, leaving significant gaps for a complex 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?
All 10 parameters are covered in the input schema (100% coverage), so the description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
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 clearly states the verb ('Creates') and resource ('new test run in a TestRail project'), making the purpose explicit. However, it does not differentiate from sibling tools like addRunToPlanEntry, which also creates runs but in a different context.
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 guidance is provided on when to use this tool versus alternatives such as addRunToPlanEntry, or any prerequisites or conditions. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a new test run to an existing plan entry / 既存のプランエントリーに新しいテストランを追加します
| Name | Required | Description | Default |
|---|---|---|---|
| planId | Yes | TestRail Plan ID | |
| entryId | Yes | Plan Entry ID | |
| configIds | Yes | Configuration IDs for the test run | |
| description | No | Test run description | |
| assignedtoId | No | User ID to assign to | |
| includeAll | No | Include all test cases | |
| caseIds | No | Specific case IDs to include | |
| refs | No | References |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description simply restates the operation without disclosing behavioral traits (e.g., side effects, permissions, idempotency).
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?
Single sentence with translation, no unnecessary 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?
With 8 parameters and no output schema or annotations, the description is too minimal; it does not explain return values, constraints, or usage context.
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 100%, so the schema already documents parameters; the description adds no extra meaning beyond restating the tool's function.
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 clearly states the verb 'adds', the resource 'test run', and the target 'to an existing plan entry', distinguishing it from siblings like addRun or addPlanEntry.
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 guidance on when to use this tool vs alternatives (e.g., addRun, addPlanEntry) or prerequisites such as an existing plan and entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new section in a TestRail project / TestRailプロジェクトに新しいセクションを作成します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| name | Yes | Section name (required) | |
| description | No | Section description | |
| parentId | No | Parent section ID | |
| suiteId | No | Test Suite ID (required for multi-suite projects) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It only states 'creates', but doesn't mention side effects, permissions, idempotency, or error conditions. For a creation tool, this is insufficient.
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 a single sentence (bilingual) which is too terse for a tool with 5 parameters. It lacks structure and additional context, making it underspecified. Conciseness should not sacrifice completeness.
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?
No output schema, no description of return values, error cases, or pagination. For a tool with multiple parameters and no annotations, the description is incomplete. It fails to provide enough context for correct invocation.
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 100%, so the schema already documents parameters. However, the description adds no extra meaning beyond the schema. For example, it doesn't explain that parentId makes a subsection or that suiteId is required for multi-suite projects. Baseline 3 is appropriate.
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 explicitly states 'Creates a new section in a TestRail project', which clearly identifies the verb and resource. The sibling tools (e.g., addCase, addSuite) are distinct, so no confusion. However, it doesn't elaborate on the context or preconditions.
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 guidance on when to use this tool versus alternatives like moveSection or updateSection. No mention of prerequisites (e.g., project must exist) or when not to use it. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new test suite in the specified project / 指定されたプロジェクトに新しいテストスイートを作成します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID where the suite will be created / スイートを作成するTestRailプロジェクトID | |
| name | Yes | Name of the test suite / テストスイートの名前 | |
| description | No | Description of the test suite (optional) / テストスイートの説明（任意） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool creates a suite, but does not mention any behavioral traits such as whether the operation is destructive, idempotent, requires specific permissions, or what happens on failure. The description is too minimal to ensure an agent understands the consequences of invoking this tool.
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 very concise: two short sentences with no unnecessary words. It includes bilingual text effectively. Every sentence serves a purpose. It is front-loaded with the key action and context.
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?
Given the tool is a creation operation with no output schema, the description should at least hint at the return value (e.g., the new suite's ID) or any side effects (e.g., triggers email notifications). It does not. For a tool with three parameters, some contextual completeness is missing, making it less useful for an agent to fully understand outcomes.
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 input schema has 100% description coverage for all three parameters, with bilingual descriptions. The tool's description adds no additional parameter meaning beyond what the schema already provides. According to rules, when schema coverage is high, baseline is 3, and this description meets that baseline without adding extra value.
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 clearly states the tool creates a new test suite in a specified project. It's specific about the verb and resource, and the mention of 'specified project' adds context. However, it does not differentiate from sibling tools like addCase, which also create, but the resource type is different.
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 no guidance on when to use this tool versus alternatives, nor does it mention any preconditions or exclusions. With sibling tools like addCase and updateSuite, an agent would benefit from knowing when to create versus update a suite, but no such guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copies specified test cases to a target section while keeping the originals / 指定されたテストケースを対象のセクションにコピーし、元のケースは保持します
| Name | Required | Description | Default |
|---|---|---|---|
| caseIds | Yes | Array of TestRail Case IDs | |
| sectionId | Yes | Target TestRail Section ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description should disclose behavioral details like permissions, error handling, or side effects. It only states the basic copy action, missing any transparency beyond that.
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, concise sentence in English and Japanese. It is front-loaded and efficient, with no redundant information. However, it could be slightly more structured by including a note about similar tools.
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 simple tool with two parameters, the description covers the basic function. However, it lacks details about what the tool returns, potential errors, or ordering, making it just 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 coverage is 100%, so the schema already describes parameters. The description adds no extra meaning beyond 'specified test cases' and 'target section'. Baseline 3 is appropriate.
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 clearly states it copies test cases to a target section while preserving originals, using 'copies' as a specific verb. It implies the difference from the sibling tool moveToSection, but does not explicitly call it out. Purpose is clear and distinct.
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 guidance on when to use this tool versus alternatives like moveToSection, or any prerequisites. The description only states what it does, not when it should be used or avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a test case from TestRail / TestRailからテストケースを削除します
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | TestRail Case ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Deletes' without mentioning if the deletion is permanent, reversible, or requires permissions, nor any cascading effects on related data.
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 very concise with two sentences (bilingual). It is front-loaded with the purpose. However, it could be more informative while remaining concise.
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 simple one-parameter tool with no output schema, the description is mostly adequate but lacks behavioral context like irreversibility. It is minimally complete but could be improved.
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 only parameter 'caseId' is described in the schema as 'TestRail Case ID', and the description adds no extra meaning. With 100% schema coverage, baseline is 3.
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 clearly states it 'Deletes a test case from TestRail', using a specific verb and resource. It distinguishes from sibling tools like deleteSection by specifying 'test case'.
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 guidance on when to use this tool versus alternatives, such as updating a case instead of deleting. Missing preconditions or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a section / セクションを削除します
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID | |
| soft | No | True for soft delete (preview only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like whether the deletion is permanent, cascading, or reversible. The description only states 'Deletes a section,' ignoring the soft delete parameter and its implications. The agent gets minimal behavioral context.
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 a single, clear sentence front-loaded with the verb. It includes a Japanese translation for broader accessibility. It could be slightly expanded to mention the soft delete option, but it remains concise and efficient.
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?
The description lacks crucial context: no mention of return values, error conditions, or behavior differences (soft vs hard delete). With no output schema, the agent cannot predict the tool's response, making it incomplete for a deletion operation.
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 100% (both parameters have descriptions). The tool description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 clearly states the tool deletes a section, which is a specific verb+resource. It distinguishes itself from sibling tools like 'deleteCase' or 'moveSection' by targeting sections exclusively.
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 guidance is provided on when to use this tool versus alternatives (e.g., 'updateSection' for modifying instead of deleting), nor any prerequisites like whether the section must be empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports a BDD test case as a .feature file in Gherkin format. REQUIRED: caseId.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | TestRail Case ID to export as .feature |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It implies a read operation via 'Exports' but does not explicitly state it is non-destructive, require permissions, or handle invalid caseId. Adequate but could be more explicit about side effects.
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?
Single sentence with no redundancy. It conveys the core action, format, and required input efficiently.
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 simple export tool with one parameter and no output schema, the description covers the essential: what it does and what input is needed. Could mention that the output is a file or provide error handling hints, but sufficient.
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 100%, and the description adds minimal value beyond the schema by restating the parameter's purpose. The 'REQUIRED' emphasis is helpful but already in schema's 'required' array.
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 clearly states the tool exports a BDD test case as a .feature file in Gherkin format, with a specific verb and resource. It distinguishes from siblings like addBdd (which adds) and getCase (which retrieves case details) by focusing on export.
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 mentions the required parameter caseId but provides no guidance on when to use this tool versus alternatives (e.g., getCase for viewing, addBdd for creating). No exclusions or context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves complete details for a single test case including steps, expected results, and prerequisites. REQUIRED: caseId.
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | TestRail Case ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves (read-only) complete details, including specific fields. No contradictory or missing behavioral information for this simple retrieval tool.
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 a single sentence that front-loads the purpose and key detail (REQUIRED: caseId). No unnecessary 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?
For a simple retrieval tool with one required parameter and no output schema, the description is adequately complete. It lists the key data returned (steps, expected results, prerequisites), which is sufficient for an agent to decide to use it.
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 100% and the description in the schema already explains caseId. The tool description adds the 'REQUIRED' emphasis but no additional semantic detail beyond the schema.
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 clearly states the tool retrieves complete details for a single test case, listing specific fields like steps, expected results, and prerequisites. This distinguishes it clearly from sibling tools such as getCases or getCaseFields.
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 explicitly mentions 'REQUIRED: caseId', which is a strong usage guideline. It does not explicitly state when not to use or compare to alternatives, but the requirement is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all available test case fields in TestRail / TestRailで利用可能な全テストケースフィールドを取得します
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral disclosure beyond the action. No information about side effects, authentication, rate limits, or return format is given.
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 sentence in two languages with no extraneous text. Every word is functional.
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 fetch tool, the description adequately states the resource. However, lack of output schema means the return format is not described, which could be improved but is not critical given the tool's simplicity.
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 input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none. Baseline for 0 params is 4.
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 explicitly states the action ('retrieves') and the resource ('all available test case fields'), distinguishing it from siblings like getCase (single case) and getCaseTypes (types).
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 alternatives are provided, but the function is straightforward and its name implies it's for fetching field metadata. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the change history of a test case including updates to fields and custom fields / テストケースの変更履歴（フィールドとカスタムフィールドの更新を含む）を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | TestRail Case ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the disclosure burden. It does not mention side effects, auth requirements, rate limits, or return format. The description only states the purpose without behavioral context.
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?
Single sentence in English and Japanese is concise and front-loaded with the action. However, it lacks any structural elements like bullet points or sections.
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?
Given no output schema, the description should ideally explain the return format. The tool is simple with one param, but as a history retrieval, return details would be helpful. Currently adequate but not complete.
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 100% with one parameter 'caseId' described as 'TestRail Case ID'. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 clearly states it retrieves change history of a test case including fields and custom fields. It uses a specific verb and resource, and is distinct from sibling tools like getCase or getCases.
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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves test cases list with basic fields only (excludes steps/expected results for performance). REQUIRED: projectId, suiteId. OPTIONAL: createdBy, filter, limit (default 50), milestoneId, offset (default 0), priorityId, refs, sectionId, templateId, typeId, updatedBy, labelId. Use getCase for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| suiteId | Yes | TestRail Suite ID | |
| createdBy | No | A comma-separated list of creators (user IDs) to filter by | |
| filter | No | Only return cases with matching filter string in the case title | |
| limit | No | The number of test cases the response should return (The response size is 50 by default) —requires TestRail 6.7 or later | |
| milestoneId | No | A comma-separated list of milestone IDs to filter by (not available if the milestone field is disabled for the project) | |
| offset | No | Where to start counting the tests cases from (the offset)—requires TestRail 6.7 or later | |
| priorityId | No | A comma-separated list of priority IDs to filter by | |
| refs | No | A single Reference ID (e.g. TR-1, 4291, etc.) —requires TestRail 6.5.2 or later | |
| sectionId | No | The ID of a test case section | |
| templateId | No | A comma-separated list of template IDs to filter by —requires TestRail 5.2 or later | |
| typeId | No | A comma-separated list of case type IDs to filter by | |
| updatedBy | No | A comma-separated list of user IDs who updated test cases to filter by | |
| labelId | No | A comma-separated list of label IDs to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that only basic fields are returned for performance and provides default values for limit and offset. However, it does not mention error handling or version requirements for some parameters (though those are in schema). Without annotations, this is fairly transparent.
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 concise sentences plus a clear list. Front-loaded with the most important information. No superfluous content.
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?
Given no output schema, description explains the output is basic fields for performance, but does not specify which fields are included or mention pagination structure. Still fairly complete for a list retrieval 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?
Schema coverage is 100%, so baseline is 3. Description groups parameters into REQUIRED/OPTIONAL but adds little detail beyond schema descriptions. It does provide a high-level overview of parameter roles.
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?
Description uses specific verb 'Retrieves' and resource 'test cases list', and distinguishes from sibling getCase by noting it excludes steps/expected results for performance.
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?
Clearly states REQUIRED parameters (projectId, suiteId) and lists OPTIONAL parameters. Provides explicit alternative: 'Use getCase for full details' for when full details are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all available test case types in TestRail / TestRailで利用可能な全テストケースタイプを取得します
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only indicates a read operation without mentioning safety, authentication needs, or rate limits. For a tool with zero annotations, additional behavioral context is needed.
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?
Single sentence that front-loads the action. The Japanese translation adds minimal extra length but does not detract from conciseness. Every word is necessary and 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 simple retrieval tool with no parameters and no output schema, the description is mostly adequate but lacks details about what constitutes a 'test case type' and the expected return format. Given the many sibling tools, more context could help differentiate.
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 has zero parameters, and schema coverage is 100%, so a baseline of 4 applies. However, the description adds no semantic detail beyond 'all available test case types', such as the nature of the return values (e.g., list of IDs and names). It does not significantly enrich understanding of the output.
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?
Description clearly states the tool retrieves all available test case types in TestRail, using a specific verb ('retrieves') and resource ('test case types'). However, it does not distinguish from similar sibling tools like getCaseFields, which also retrieves case fields, but the purpose is still clear.
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 guidance on when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, exclusions, or comparison to related tools like getCases or getCaseFields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all milestones for a specified TestRail project / 指定されたTestRailプロジェクトの全マイルストーンを取得します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits, but it only states the basic action. It does not mention potential pagination, authentication requirements, rate limits, or other side effects beyond 'retrieves'.
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 a single, front-loaded sentence (bilingual) that efficiently communicates the tool's purpose with 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?
For a simple 1-parameter tool with no output schema, the description is adequate but lacks details about the return format, sorting, or any limitations. It covers the essential function but leaves some ambiguity.
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 100%, so the baseline is 3. The tool description adds no additional meaning beyond what the schema provides for the 'projectId' parameter.
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 uses a specific verb ('Retrieves') and resource ('all milestones for a specified TestRail project'), clearly stating the tool's function. It distinguishes itself from sibling tools like 'getCases' or 'getRuns' by explicitly focusing on milestones.
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 guidance is provided on when to use this tool versus alternatives. The description lacks context such as prerequisites, when to avoid it, or suggested use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all test plans for a specified TestRail project / 指定されたTestRailプロジェクトの全テストプランを取得します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a read operation but fails to mention pagination, error handling, or authentication needs.
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 a single, efficient sentence with no extraneous words. It is front-loaded and bilingual, effectively communicating the purpose.
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?
Given the simple one-parameter input and no output schema, the description should provide some detail on the return format. It lacks any information about the structure of the retrieved plans.
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 100% with a clear parameter description ('TestRail Project ID'). The description adds no further meaning beyond restating the parameter 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?
The description clearly states the tool retrieves all test plans for a specified project, with a clear verb and resource. It effectively distinguishes itself from siblings like addPlan (creation) and other get 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?
No guidance is provided on when to use this tool versus alternatives such as getRuns or getCases. The description lacks any context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details of a specific TestRail project by ID / 特定のTestRailプロジェクトの詳細をIDで取得します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID to retrieve / 取得するTestRailプロジェクトID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It does not disclose any behavioral traits beyond basic retrieval (e.g., permissions, rate limits, or side effects). For a simple read operation this is minimal.
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?
Single sentence in two languages, no wasted words. Could be slightly more informative but appropriately concise.
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 simple retrieval by ID, the description is adequate. No output schema exists, but return value is implicit. Sibling tools provide relevant context.
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 100% (single parameter with description). The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
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 clearly states the verb 'Retrieves', the resource 'TestRail project details', and the method 'by ID'. It distinguishes from sibling tools like getProjects (list) and getCase (different entity).
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 guidance on when to use this tool versus alternatives (e.g., getProjects for listing, getCase for cases). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all TestRail projects / すべてのTestRailプロジェクトを取得します
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a read operation, but gives no details on pagination, rate limits, empty results, or response format. This is minimal disclosure for a parameterless tool.
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 a single clear sentence plus a redundant Japanese translation, with no extraneous information. Every word is earned for such a simple tool.
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 simple parameterless tool, the description covers the basic purpose. However, without an output schema, it would benefit from mentioning what the response contains (e.g., list of project IDs and names). The lack of this info limits completeness.
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?
There are no parameters, so the baseline score is 4 per instructions. The schema coverage is 100% (vacuously), and the description correctly indicates the tool does not require 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 clearly states 'Retrieves all TestRail projects' (verb+resource), and the Japanese translation reinforces the meaning. It distinguishes itself from the sibling getProject (which retrieves a single project) and other 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?
Usage is implied as retrieving all projects when a list is needed, but there is no explicit guidance on when to use vs. alternatives (e.g., getProject for a specific project) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves test results for a specific test / 特定のテストのテスト結果を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| testId | Yes | TestRail Test ID | |
| limit | No | The number of results to return per page | |
| offset | No | The offset to start returning results | |
| statusId | No | Filter by status IDs (comma-separated) | |
| defectsFilter | No | Filter by defect ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function, missing details about pagination, filtering, error conditions, or that it is a read 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?
The description is short but includes a duplicate Japanese sentence that adds no value for an English-speaking agent. It could be more informative without the redundancy.
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 tool with 5 parameters and no output schema, the description omits crucial context about pagination, filtering behavior, and return structure, leaving the agent to infer from parameter names alone.
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 100% with all parameters described. The description adds no additional parameter meaning, so baseline 3 is appropriate.
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 clearly states the action and resource: 'Retrieves test results for a specific test'. However, it does not differentiate from sibling tools like getResultsForCase and getResultsForRun, which could cause confusion.
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 usage context or alternatives are mentioned. The agent has no guidance on when to use this tool over similar siblings, such as getResultsForCase or getResultsForRun.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves test results for a specific test case in a test run / テスト実行内の特定のテストケースのテスト結果を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| caseId | Yes | TestRail Case ID | |
| limit | No | The number of results to return per page | |
| offset | No | The offset to start returning results | |
| statusId | No | Filter by status IDs (comma-separated) | |
| defectsFilter | No | Filter by defect ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but fails to do so. It does not mention read-only behavior, authentication requirements, rate limits, or what the response contains. The description is purely functional.
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 very concise (a single bilingual sentence), but it omits important context. It is front-loaded with purpose but lacks necessary details, earning an adequate score.
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?
Given the lack of annotations and output schema, the description is insufficient. It does not explain the relationship between parameters, pagination, or return format, making it incomplete for an agent to use effectively.
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 input schema has 100% description coverage for all 6 parameters, so the baseline is 3. The description adds no additional meaning beyond what is already in the schema.
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 clearly states it retrieves test results for a specific test case in a test run, distinguishing it from broader tools like getResultsForRun or getResults. The bilingual wording reinforces the purpose without ambiguity.
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 guidance is provided on when to use this tool versus siblings such as getResultsForRun or getResults. The description does not specify that it is for a specific case within a run, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all test results for a test run / テスト実行の全テスト結果を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| limit | No | The number of results to return per page | |
| offset | No | The offset to start returning results | |
| statusId | No | Filter by status IDs (comma-separated) | |
| defectsFilter | No | Filter by defect ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that results are retrieved, but omits important details like pagination, filtering behavior, or any side effects. The tool is a read operation, but the description doesn't confirm it's safe or idempotent.
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 extremely concise with two short sentences. The bilingual repetition is slightly redundant but not damaging. It is well-structured and 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?
Despite full schema coverage, the description lacks details on output format, pagination limits, and any rate limits. For a retrieval tool with no output schema and no annotations, the description is incomplete.
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 100%, so the input schema already documents all parameters. The description adds no extra meaning beyond the tool's purpose. Baseline score of 3 is appropriate.
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 uses the verb 'Retrieves' and specifies the resource 'all test results for a test run'. It clearly distinguishes from sibling tools like getResultsForCase by scoping to a test run. The bilingual text does not introduce ambiguity.
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 no guidance on when to use this tool versus alternatives like getResults or getResultsForCase. It does not mention any prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details of a specific test run by ID / 特定のテスト実行の詳細をIDで取得します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states 'retrieves details' without mentioning that it is a read-only operation, any missing behavior like error handling, or what constitutes 'details'. This falls short for a mutation-free tool.
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 extremely concise, consisting of one bilingual sentence that communicates the core action. It is front-loaded and efficient, though the bilingual repetition could be seen as redundant but not detrimental.
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?
The description is minimal but adequate for a simple retrieval tool with only one parameter. However, it lacks details on what 'details' include (e.g., fields returned, error handling) and does not leverage the opportunity to differentiate from similar sibling tools. Given no output schema, more context would be 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?
The input schema already describes the single parameter 'runId' with a clear description ('TestRail Run ID'), achieving 100% coverage. The description does not add further meaning beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the verb 'Retrieves' and the resource 'details of a specific test run by ID', providing a specific action and resource. It distinguishes from sibling tools like 'getRuns' (plural) and 'getTests' by focusing on a single run by ID.
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 guidance is provided on when to use this tool versus alternatives, such as when to use 'getRun' versus 'getRuns' or 'getTests'. There is no mention of prerequisites, exclusions, or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all test runs for a specified TestRail project / 指定されたTestRailプロジェクトの全テスト実行を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| createdAfter | No | Only return runs created after this timestamp | |
| createdBefore | No | Only return runs created before this timestamp | |
| createdBy | No | Only return runs created by these user IDs | |
| milestoneId | No | Only return runs for this milestone | |
| suiteId | No | Only return runs for this test suite | |
| limit | No | The number of runs to return per page | |
| offset | No | The offset to start returning runs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It only says 'Retrieves all test runs' but omits details like pagination, filtering behavior, or whether default limits apply. The presence of optional filters is not mentioned in the description.
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?
Single line in English and Japanese is concise, but for an 8-parameter tool, it lacks structure. Could be more informative without being verbose.
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?
Given 8 optional parameters and no output schema, the description is insufficient. It does not explain return values, pagination, or how filters narrow results. Sibling tools like getRun and getResults are not addressed.
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 100% (all parameters described). The description adds no additional meaning beyond the schema. Baseline is 3.
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 clearly states the verb 'Retrieves' and resource 'all test runs for a specified TestRail project'. It distinguishes from siblings like getRun (singular) and addRun, though no explicit differentiation is provided.
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 guidance on when to use this tool versus alternatives like getRun (for single run) or getTests. No context on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details of a specific section by ID / 特定のセクションの詳細をIDで取得します
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it 'retrieves details' without disclosing side effects, permissions, or response structure. It is a simple read operation but lacks depth on behavioral 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?
The description is very concise, with one line each in English and Japanese. It is front-loaded and contains no unnecessary words, though it is minimal.
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?
Given the single parameter and no output schema, the description is adequate but lacks details on what fields are returned in the section details. Could be more informative.
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 description does not add meaning beyond the input schema, which already fully documents sectionId as a number. Schema coverage is 100%, so baseline 3 applies.
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 clearly states that it retrieves details of a specific section by ID, making the purpose explicit. It distinguishes itself from sibling tools like getSections (list) and addSection (create).
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 usage when a specific section ID is known but does not explicitly state when to use over alternatives like getSections for lists. No guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves sections for a specified project and suite. Supports pagination via limit and offset parameters (default: limit=250, offset=0). Use _links.next to determine if more pages are available. / 指定されたプロジェクトとスイートのセクションを取得します。limitとoffsetパラメータでページネーションをサポートします。
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| suiteId | No | TestRail Suite ID (optional for single suite projects) | |
| limit | No | Maximum number of sections to return (default 250, max 250) | |
| offset | No | Number of sections to skip (default 0, for pagination) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses pagination behavior (defaults, next link) but no information about destructive actions, authentication, or rate limits. Adequate but limited.
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 concise sentences in English plus Japanese translation. Every sentence is meaningful, no redundancy. Front-loaded with purpose.
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?
With 4 parameters, no output schema, and no annotations, description covers purpose and pagination but lacks details on return format, error conditions, or suite optionality. Adequate but with gaps.
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 100%, but description adds value by specifying default values (limit=250, offset=0) and explaining pagination flow (use _links.next). Goes beyond schema alone.
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?
Description clearly states 'Retrieves sections for a specified project and suite', using specific verb ('retrieves') and resource ('sections'). Differentiates from sibling tools like getSection (singular) and addSection (create).
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 pagination usage details (limit, offset, next link) but no explicit guidance on when to use this tool versus alternatives like getSection or addSection. Usage is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves details of a specific test suite by ID / 特定のテストスイートの詳細をIDで取得します
| Name | Required | Description | Default |
|---|---|---|---|
| suiteId | Yes | TestRail Suite ID to retrieve / 取得するTestRailスイートID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions retrieval, with no details on permissions, rate limits, or side effects. The lack of behavioral context is a gap for a read 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?
Single sentence, front-loaded with action and resource, no redundant words. Excellent conciseness.
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?
Given the simple retrieval nature, single parameter, and no output schema, the description is mostly complete. It could mention what fields are returned or provide more context, but it's 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 coverage is 100% with one parameter (suiteId) described. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the tool retrieves a specific test suite by ID, using a specific verb and resource. It distinguishes from siblings like getSuites (list all) and addSuite/updateSuite (modifications).
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 guidance on when to use this tool versus alternatives, such as getSuites for listing or getCase for test cases. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all test suites for a specified TestRail project / 指定されたTestRailプロジェクトの全テストスイートを取得します
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID to get suites from / スイート一覧を取得するTestRailプロジェクトID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'retrieves' implies a read-only, non-destructive operation, which is adequate for a tool with no annotations. However, it does not explicitly state safety, idempotency, authentication requirements, or potential side effects, leaving some ambiguity.
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 short, front-loaded, and bilingual, but the repetition of identical information in two languages slightly reduces conciseness. Every sentence earns its place, though a single language version would be more efficient.
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?
Given the absence of an output schema, the description should at least hint at the return format (e.g., list of suite objects). It also fails to mention any prerequisites, pagination, or limit considerations, leaving the agent with incomplete context.
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 schema provides 100% coverage for the single parameter (projectId) with clear descriptions in English and Japanese. The description adds no additional meaning or constraints beyond the schema, meeting the baseline.
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 clearly states the tool retrieves all test suites for a specified TestRail project, using a specific verb ('Retrieves') and resource ('all test suites'). This distinguishes it from sibling tools like getSuite (singular) and addSuite.
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 guidance is provided on when to use this tool versus alternatives (e.g., getSuite for a single suite). The description implies usage when needing all suites for a project, but lacks exclusions or context-specific advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves complete details for a single test, including all fields such as status, type, and results / 単一のテストの完全な詳細（ステータス、タイプ、結果などのすべてのフィールドを含む）を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| testId | Yes | TestRail Test ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves 'complete details' but does not disclose any behavioral traits like authentication needs, rate limits, or side effects. The description adds minimal value beyond the schema.
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 a single sentence in English and Japanese, which is concise and front-loaded. However, the bilingual content adds length without additional value for English-only contexts.
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 simple retrieval tool with no output schema, the description should explain the return format or structure. It only says 'complete details' and lists example fields, but does not specify how results are returned or pagination. Incomplete for an agent to fully understand the output.
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 100% with testId described as 'TestRail Test ID'. The description does not add additional meaning for the parameter; it only mentions result fields (status, type, results) which are not part of the input schema. Baseline 3 is appropriate.
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 clearly states 'Retrieves complete details for a single test', specifying the verb and resource. It distinguishes from sibling tools like getTests (plural) and getResults by focusing on a single test's full details.
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 guidance on when to use this tool versus alternatives such as getCase or getResults. The description implies usage for retrieving a single test, but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a list of tests for a test run / テスト実行に含まれるテスト一覧を取得します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| limit | No | Number of tests to return per page. If you cannot get all tests, try separating the request into multiple calls | |
| offset | No | Offset for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose pagination behavior, return format, or ordering. The schema describes pagination but the description adds no behavioral context beyond the bare 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?
The description is a single sentence with Japanese translation, front-loading the core action efficiently. It is concise and to the point, with no unnecessary 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?
Despite low complexity, the description lacks completeness: no output schema, no mention of what fields are returned, no pagination behavior explained. Agent cannot infer the response structure or handle pagination effectively.
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 100%, so the schema already documents all parameters. The description adds no additional parameter meaning beyond what's in the schema, meeting the baseline.
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 clearly states the verb 'Retrieves' and the resource 'tests for a test run'. It distinguishes from sibling tools like getTest (single test) and getResultsForRun (results, not tests).
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 guidance on when to use this tool versus alternatives like getResultsForRun or getTest. Does not mention prerequisites or limitations, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves a section to a new position in the test hierarchy / テスト階層内の新しい位置にセクションを移動します
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID | |
| parentId | Yes | Parent section ID (null for root) | |
| afterId | No | ID of the section to position after |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as impact on related data, permissions required, or whether the operation is reversible. Only states the basic action.
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?
Description is concise with two short sentences (English and Japanese), no unnecessary words. However, it could benefit from slightly more structured detail.
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?
Given the tool's simplicity and complete schema, the description is adequate but lacks context on usage patterns (e.g., that parentId can be null for root, or that afterId is optional). No output schema exists, so description could elaborate on return value.
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 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters.
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?
Description clearly states the action 'Moves' and resource 'section', specifying 'to a new position in the test hierarchy'. This distinguishes it from sibling tools like addSection, deleteSection, and updateSection, though not explicitly differentiating from moveToSection, which likely operates on test cases.
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 guidance on when to use this tool versus alternatives (e.g., moveToSection, updateSection). No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moves specified test cases to a target section / 指定されたテストケースを対象のセクションに移動します
| Name | Required | Description | Default |
|---|---|---|---|
| caseIds | Yes | Array of TestRail Case IDs | |
| sectionId | Yes | Target TestRail Section ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Moves' without disclosing side effects (e.g., whether original records are removed, if links break, or any authorization needs).
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 two concise sentences (English and Japanese), front-loading the key information without unnecessary fluff.
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 simple 2-parameter tool with no output schema, the description is minimally complete. However, it lacks indication of return value or error cases, and with no annotations, more behavioral context would help.
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 100% with descriptions for both parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the action ('Moves specified test cases') and the target resource ('target section'), distinguishing it from sibling tools like 'moveSection' and 'copyToSection'.
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 guidance is provided on when to use this tool versus alternatives like 'copyToSection' or when moving cases requires certain permissions. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing test case. REQUIRED: caseId. OPTIONAL: title, typeId, priorityId, templateId, customSteps, customExpected, customStepsSeparated, customFields, etc. Only specified fields will be updated. NOTE: templateId=2 is required to use customStepsSeparated (array of step objects with 'content' and 'expected' fields). For simple text steps, use customSteps and customExpected instead. Use customFields for any additional custom fields (e.g., {custom_case_security_score: 'high'}).
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | TestRail Case ID | |
| title | No | Test case title | |
| typeId | No | Test case type ID | |
| priorityId | No | Test case priority ID | |
| estimate | No | Test case estimated time | |
| milestoneId | No | TestRail Milestone ID | |
| refs | No | Test case references | |
| templateId | No | Template ID (use 2 for custom_steps_separated support) | |
| customPrerequisites | No | Prerequisites | |
| customSteps | No | Test case steps | |
| customExpected | No | Expected results | |
| customStepsSeparated | No | Separated test steps array (requires template_id=2) | |
| customFields | No | Additional custom fields as key-value pairs (e.g., {custom_case_security_score: 'high'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses partial update behavior ('Only specified fields will be updated') and a dependency (templateId=2 for customStepsSeparated). However, it omits details about error handling if caseId doesn't exist, return value, authentication needs, or rate limits. For a mutation tool without annotations, this is adequate but not thorough.
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 concise with clear labeling (REQUIRED, OPTIONAL, NOTE) and front-loaded key information. Every sentence adds value 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?
Given the 13 parameters and nested objects, the description covers the essential usage patterns and dependencies. However, it lacks information about return values, error handling, and permissions. With no output schema, some more completeness would improve it, but it is still fairly comprehensive for a mutation 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?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the relationship between templateId=2 and customStepsSeparated, providing an example for customFields, and clarifying when to use customSteps/customExpected vs customStepsSeparated. This goes beyond the 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 description clearly states the tool updates an existing test case, lists required and optional parameters, and distinguishes itself from sibling tools like addCase (which adds) and deleteCase (which deletes). The verb 'Updates' with resource 'test case' is specific and unambiguous.
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 clearly states which parameters are required (caseId) and optional, and provides a note about templateId=2 for customStepsSeparated. However, it does not explicitly address when to use this tool versus alternatives like addCase or deleteCase, nor does it provide exclusions or alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates multiple test cases simultaneously with the same field values / 複数のテストケースを同じフィールド値で一括更新します. NOTE: templateId=2 is required to use customStepsSeparated (array of step objects with 'content' and 'expected' fields). For simple text steps, use customSteps and customExpected instead. Use customFields for any additional custom fields (e.g., {custom_case_security_score: 'high'}).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | TestRail Project ID | |
| suiteId | Yes | TestRail Suite ID | |
| caseIds | Yes | Array of TestRail Case IDs | |
| title | No | Test case title | |
| typeId | No | Test case type ID | |
| priorityId | No | Test case priority ID | |
| estimate | No | Test case estimated time | |
| milestoneId | No | TestRail Milestone ID | |
| refs | No | Test case references | |
| templateId | No | Template ID (use 2 for custom_steps_separated support) | |
| customPrerequisites | No | Prerequisites | |
| customSteps | No | Test case steps | |
| customExpected | No | Expected results | |
| customStepsSeparated | No | Separated test steps array (requires template_id=2) | |
| customFields | No | Additional custom fields as key-value pairs (e.g., {custom_case_security_score: 'high'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions batch update with same field values but does not disclose whether fields are overwritten or merged, required permissions, or rate limits. For a mutation tool, this is insufficient.
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 concise, with a main sentence and a brief NOTE. It includes bilingual text (English and Japanese) which is slightly redundant but acceptable. All sentences are relevant and provide necessary details.
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?
Given 15 parameters, no output schema, and no annotations, the description covers the batch update nature and specific template requirements. However, it does not explain return values or error behavior, which is a gap for completeness.
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 100%, so baseline is 3. The description adds value by explaining the requirement of templateId=2 for customStepsSeparated, and the format of customFields. It also clarifies the use of customSteps and customExpected for simple text steps, going beyond the schema.
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 clearly states 'Updates multiple test cases simultaneously with the same field values', specifying the action (updates), resource (multiple test cases), and scope (same values). It distinguishes from sibling tools like updateCase (singular) and addCase (creation).
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 includes a NOTE about templateId=2 and the distinction between customStepsSeparated and customSteps/customExpected. However, it does not explicitly mention when to use this tool versus alternatives like updateCase for single cases, or clarify that it is for batch updates only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing test run / 既存のテスト実行を更新します
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | TestRail Run ID | |
| name | No | Test run name | |
| description | No | Test run description | |
| milestoneId | No | Milestone ID | |
| assignedtoId | No | User ID to assign to | |
| includeAll | No | Include all test cases from the suite | |
| caseIds | No | Specific case IDs to include | |
| refs | No | Reference/requirement IDs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions 'updates' but does not specify if the operation is idempotent, what fields are required versus optional, any side effects, or permissions needed. This is insufficient for safe invocation.
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 very short, with two sentences (English and Japanese). It is front-loaded and concise, but could be considered too minimal for a tool with 8 parameters. Still, it wastes no 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?
Given the complexity (8 parameters, no output schema, no annotations), the description is incomplete. It does not clarify the update semantics, success conditions, or response format. With many sibling tools, more context is needed for proper selection.
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 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, merely repeating the tool's title. It does not explain parameter relationships, defaults, or constraints.
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 clearly states 'Updates an existing test run', which is a specific verb and resource. However, it does not differentiate from sibling tools like addRun or getRun, which share similar context.
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 guidance on when to use this tool versus alternatives like addRun, updateCase, or other update tools. The description implies usage only by stating the action, without context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing section / 既存のセクションを更新します
| Name | Required | Description | Default |
|---|---|---|---|
| sectionId | Yes | TestRail Section ID | |
| name | No | Section name | |
| description | No | Section description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose behavioral traits such as whether the update is partial or full replacement, what happens if the sectionId does not exist, or if there are permissions required. The description is too terse to guide an agent on side effects.
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?
Very concise with two sentences (English and Japanese). No unnecessary text, but additional critical details could be added without sacrificing conciseness.
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?
Given the tool updates a section in a test management system, the description lacks details on prerequisites (existing section), return value, and mutability behavior. With no output schema or annotations, the description should provide more context for a safe invocation.
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 100%, providing descriptions for all parameters. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
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?
Clearly states 'Updates an existing section', specifying both the verb (updates) and resource (section). This distinguishes it from sibling tools like addSection (create) and deleteSection (delete).
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 guidance on when to use this tool versus alternatives. Usage is implied as modifying an existing section, but no exclusions or criteria for choosing over other tools like moveSection or updateSuite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing test suite / 既存のテストスイートを更新します
| Name | Required | Description | Default |
|---|---|---|---|
| suiteId | Yes | TestRail Suite ID to update / 更新するTestRailスイートID | |
| name | No | New name for the test suite (optional) / テストスイートの新しい名前（任意） | |
| description | No | New description for the test suite (optional) / テストスイートの新しい説明（任意） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states 'updates' without disclosing behavioral details such as whether it merges or overwrites fields, required permissions, or side effects.
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 a single sentence with bilingual text, no unnecessary words. It is concise and front-loaded, though it could benefit from more structure.
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?
Given no output schema and no annotations, the description is minimally complete. It covers the core action but omits return values, permissions, and behavioral nuances, leaving gaps for an AI agent.
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 100%, so the description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameters adequately.
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 'Updates an existing test suite' clearly states the verb (updates) and resource (test suite), and it is distinct from sibling tools like addSuite (create) and getSuite (read).
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 lacks explicit guidance on when to use this tool versus alternatives. It only implies usage through the verb 'updates' without specifying prerequisites or exclusions.
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. Dates show when Glama detected each change.
v0.19.6addBddaddCaseaddPlanaddPlanEntryaddResultForCaseaddResultsForCasesaddRunaddRunToPlanEntryaddSectionaddSuitecopyToSectiondeleteCasedeleteSectiongetBddgetCasegetCaseFieldsgetCaseHistorygetCasesgetCaseTypesgetMilestonesgetPlansgetProjectgetProjectsgetResultsgetResultsForCasegetResultsForRungetRungetRunsgetSectiongetSectionsgetSharedStepsgetSuitegetSuitesgetTestgetTestsmoveSectionmoveToSectionupdateCaseupdateCasesupdateRunupdateSectionupdateSuitev0.12.1addBddaddCaseaddPlanaddPlanEntryaddResultForCaseaddResultsForCasesaddRunaddRunToPlanEntryaddSectionaddSuitecopyToSectiondeleteCasedeleteSectiongetBddgetCasegetCaseFieldsgetCaseHistorygetCasesgetCaseTypesgetMilestonesgetPlansgetProjectgetProjectsgetResultsgetResultsForCasegetResultsForRungetRungetRunsgetSectiongetSectionsgetSharedStepsgetSuitegetSuitesgetTestgetTestsmoveSectionmoveToSectionupdateCaseupdateCasesupdateRunupdateSectionupdateSuitev0.19.2addBddaddCaseaddPlanaddPlanEntryaddResultForCaseaddResultsForCasesaddRunaddRunToPlanEntryaddSectionaddSuitecopyToSectiondeleteCasedeleteSectiongetBddgetCasegetCaseFieldsgetCaseHistorygetCasesgetCaseTypesgetMilestonesgetPlansgetProjectgetProjectsgetResultsgetResultsForCasegetResultsForRungetRungetRunsgetSectiongetSectionsgetSharedStepsgetSuitegetSuitesgetTestgetTestsmoveSectionmoveToSectionupdateCaseupdateCasesupdateRunupdateSectionupdateSuiteEach tool targets a distinct entity or operation, with clear differentiation between similar tools (e.g., copyToSection vs moveToSection, getResultsForCase vs getResultsForRun). Descriptions explicitly state required and optional parameters, reducing ambiguity.
All tool names follow a consistent camelCase verb_noun pattern (e.g., addCase, getCases, deleteSection). Even compound operations like copyToSection and moveToSection follow a predictable structure. No mixing of conventions.
42 tools is on the higher end but appropriate for a comprehensive TestRail API wrapper covering CRUD for cases, sections, suites, runs, plans, results, and metadata. The count could be slightly trimmed (e.g., merging some getters), but it remains manageable for the domain.
The tool surface covers most core CRUD operations for projects, suites, sections, cases, runs, and plans. However, notable gaps exist: missing delete for suites, plans, and runs, and no update for plans. Also absent are tools for milestones (get only), users, and attachments.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides access to Testiny projects, test cases and test runs
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Manage test suites, run tests, view results, and automate QA workflows via AI with testRigor.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bun913/mcp-testrail'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
