Skip to main content
Glama
uarlouski

TestRail MCP Server

add_results_for_cases

Add test results to a test run using case IDs instead of test IDs. Each result requires a status and can include comments and defects.

Instructions

Add one or more test results to a test run using case IDs instead of test IDs

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
run_idYesThe ID of the test run
resultsYesArray of results to add. Each result must have case_id and status_id

Implementation Reference

  • The handler/definition of the 'add_results_for_cases' tool. It defines the tool name, description, Zod parameters schema, and the async handler that calls client.addResultsForCases() and returns the parsed results.
    export const addResultsForCasesTool: ToolDefinition<typeof parameters, TestRailClient> = {
        name: "add_results_for_cases",
        description: "Add one or more test results to a test run using case IDs instead of test IDs",
        parameters,
        handler: async ({ run_id, results }, client: TestRailClient) => {
            const response = await client.addResultsForCases(run_id, results);
            return {
                success: true,
                added_count: response.length,
                results: response.map(r => ResultSchema.parse(r)),
            };
        },
    };
  • The Zod schema for the tool's input parameters: run_id (number) and results (array of objects with case_id, status_id, optional comment, optional defects).
    const parameters = {
        run_id: z.number().describe("The ID of the test run"),
        results: z.array(z.object({
            case_id: z.number().describe("The ID of the test case. Use get_cases with a project_id to retrieve available case IDs"),
            status_id: z.number().describe("The ID of the test status (e.g. Passed, Failed). Use get_statuses to retrieve available status IDs"),
            comment: z.string().optional().describe("Optional comment/description for the result"),
            defects: z.string().optional().describe("Optional comma-separated list of defect IDs"),
        })).describe("Array of results to add. Each result must have case_id and status_id"),
    }
  • The ResultSchema Zod schema used to parse/validate each result returned from the API.
    export const ResultSchema = z.object({
        id: z.number(),
        test_id: z.number(),
        status_id: z.number(),
        comment: z.string().nullable(),
        defects: z.string().nullable(),
    });
  • src/index.ts:22-22 (registration)
    Import of the addResultsForCasesTool in the main index.ts entry point.
    import { addResultsForCasesTool } from "./tools/add_results_for_cases.js";
  • src/index.ts:73-73 (registration)
    Registration of addResultsForCasesTool in the tools array that gets registered via server.registerTool() on line 88.
    addResultsForCasesTool,
  • The TestRailClient.addResultsForCases() method that makes the actual POST API call to TestRail's add_results_for_cases endpoint.
    async addResultsForCases(runId: number, results: Array<Record<string, any>>): Promise<Result[]> {
        return this.post<Result[]>(`${API_BASE_V2}/add_results_for_cases/${runId}`, { results });
    }
Behavior3/5

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

No annotations provided; description only states it adds results without detailing permissions, side effects, or whether results are appended or overwritten.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence communicates essential differentiating functionality with no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has simple parameters and no output schema; description and schema together provide adequate context for a mutation operation, though success/failure behavior is not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions; description adds minimal new information beyond the schema, such as the case IDs angle.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states adding test results to a test run using case IDs, and distinguishes from sibling add_results which likely uses test IDs.

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

Usage Guidelines4/5

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

Implies usage when case IDs are available instead of test IDs, but does not explicitly list when not to use or provide alternative tool names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uarlouski/testrail-mcp-server'

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