Skip to main content
Glama
trtmn

TestRail MCP Server

by trtmn

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TESTRAIL_URLYesYour TestRail instance URL (e.g., https://example.testrail.io)
TESTRAIL_API_KEYNoTestRail API key (recommended)
TESTRAIL_PASSWORDNoTestRail password (alternative to API key)
TESTRAIL_USERNAMEYesTestRail username or email

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
logging
{}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
extensions
{
  "io.modelcontextprotocol/ui": {}
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_testrail_authA

Verify the configured TestRail credentials and report a structured diagnosis.

Calls a lightweight TestRail endpoint (get_priorities, which every authenticated user can reach) and translates the outcome into an actionable result the LLM can act on. Use this when:

  • A user reports the server isn't working

  • Another tool returns a 401/403/auth error and the cause is unclear

  • Confirming setup is correct before kicking off a longer workflow

Returns a dict with at least:

  • ok: bool — True if the credential check succeeded

  • config: which URL / username / auth method the server is using (never includes the secret itself)

On success, also includes the priorities count and the username TestRail associates with the credentials. On failure, includes error_class, error, status_code (when extractable), and a human-readable hint explaining the most likely cause and remediation.

browse_testrail_apiA

Browse all available TestRail API categories and their methods.

Returns a dict mapping each category name to its description and list of available method names. Use describe_testrail_method() to get details for a specific method, then run_testrail_command() to call it.

describe_testrail_methodB

Describe a specific TestRail API method — its parameters, types, and docs.

search_test_casesA

Search for test cases by title (case-insensitive substring match).

run_testrail_commandC

Execute a TestRail API method.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: browsing API categories, verifying auth, describing methods, executing commands, and searching test cases. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case. The prefix `testrail` is used uniformly where applicable, and `search_test_cases` follows the same convention.

Tool Count4/5

With 5 tools, the count is slightly low for a full TestRail integration, but the generic API runner covers many operations. The set feels appropriately scoped for a minimal yet functional server.

Completeness4/5

While dedicated tools for common operations are missing, the `run_testrail_command` combined with `browse_testrail_api` and `describe_testrail_method` allow execution of any TestRail API method, making the surface complete in practice.

Maintenance

ActivitySlowing
ResponsivenessResponsive