The octomind-mcp server enables developers to integrate Octomind's end-to-end (e2e) testing platform into their local development environment for creating, executing, and managing automated tests.
Key capabilities include:
Search Documentation: Query Octomind's documentation
Test Management: Create, retrieve, and execute test cases
Environment Control: List, create, update, or delete test environments
Test Reporting: Access test execution reports
Test Target Administration: Create, update, or delete test targets (projects/applications)
Private Locations: Configure testing behind firewalls or VPNs
Server Configuration: Get server version, configure session storage (in-memory/Redis), and adjust logging settings
Integration Support: Provides configuration examples for various clients
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., "@octomind-mcp execute tests for our checkout flow on staging"
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.
Octomind provides a whole e2e platform for test creation, execution and management including auto-fix. With this MCP server you can use Octomind tools and resources in your local development environment and enable it to create new e2e tests, execute them and more. see https://octomind.dev/ and https://octomind.dev/docs/mcp/install-octomind-mcp for more details.
Related MCP server: wopee-mcp
The server uses the following environment variables:
APIKEY - The API key for Octomind API (required)
OCTOMIND_API_URL - Base URL for the API endpoint to use (defaults to https://app.octomind.dev/api)
REDIS_URL - Redis connection URL for session storage (optional, format: redis://host:port)
SESSION_EXPIRATION_SECONDS - Time in seconds after which sessions expire (optional, Redis only)
The server supports the following command line options:
-s, --sse - Enable SSE transport mode
-t, --stream - Enable Streamable HTTP transport mode
-c, --clients - Show client configuration examples
-p, --port <port> - Port to listen on (default: 3000)
-r, --redis-url <url> - Redis URL for session storage
-e, --session-expiration <seconds> - Session expiration time in seconds
The server supports two types of session storage:
In-memory storage (default) - Sessions are stored in memory and will be lost when the server restarts
Redis storage - Sessions are stored in Redis and can persist across server restarts
For production deployments, it's recommended to use Redis storage with an appropriate session expiration time. The Redis storage option also enables horizontal scaling with multiple server instances.
LOG_FILENAME - The file to write logs to (only for debugging). If not set, logging is disabled
LOG_LEVEL - The log level to use (defaults to info)
The following tools are implemented in this MCP server:
search - Search the Octomind documentation for a given query
getTestCase - Retrieve a test case for a given test target and test case ID
executeTests - Trigger test execution for a given test target on a specified URL
getEnvironments - List environments for a test target
createEnvironment - Create a new environment for a test target
updateEnvironment - Update an existing environment
deleteEnvironment - Delete an environment
getTestReports - Retrieve test reports for a test target
getTestReport - Get a specific test report by ID
discovery - Create a test case with a description or prompt
getPrivateLocations - List all private locations configured for the organization
getVersion - Get the current version of the Octomind MCP server
You can get configuration snippets for different clients by running:
npx @octomind/octomind-mcp --clientsThis will output configuration examples for Claude Desktop, Cursor, and Windsurf. Here are the configuration files for most clients:
To install octomind-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @OctoMind-dev/octomind-mcp --client claude{
"mcpServers": {
"octomind-mcp": {
"name": "Octomind MCP Server",
"command": "npx",
"args": [
"-y",
"@octomind/octomind-mcp@latest"
],
"env": {
"APIKEY": "your-api-key-here"
}
}
}
}{
"mcpServers": {
"octomind-mcp": {
"name": "Octomind MCP Server",
"command": "npx",
"args": [
"-y",
"@octomind/octomind-mcp@latest"
],
"env": {
"APIKEY": "your-api-key-here"
}
}
}
}{
"mcpServers": {
"octomind-mcp": {
"name": "Octomind MCP Server",
"command": "npx",
"args": [
"-y",
"@octomind/octomind-mcp@latest"
],
"environment": {
"APIKEY": "your-api-key-here"
}
}
}
}Note: Replace your-api-key-here with your actual API key.
To get an APIKEY see here https://octomind.dev/docs/get-started/execution-without-ci#create-an-api-key
Certified by MCPHub
the createEnvironment tool can create an environment for a given test target. an environment represents a specific setup or deployments for a test target. It include a test account when necsesary to login, a header configuration, a discovery url and a set of variables.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the environment | |
| basicAuth | No | Optional basic authentication credentials, if discovery needs authentication | |
| testAccount | No | Optional test account credentials, if discovery needs authentication | |
| discoveryUrl | Yes | URL used for test discovery | |
| testTargetId | Yes | Unique identifier of the test target | |
| privateLocationName | No | Optional name of the private location, if discovery needs to discover in a private location e.g. behind a firewall or VPN | US Proxy |
| additionalHeaderFields | No | Optional additional HTTP header fields, if discovery needs additional headers to be set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions components like test account and headers but does not describe important behaviors such as idempotency, side effects, or prerequisites (e.g., must the test target already exist?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) but contains typos ('necsesary') and awkward phrasing ('It include'). It front-loads the main action but wastes space on incomplete component listing. Could be more polished.
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 conveys the core purpose and main components, but given the complexity (7 params, nested objects, no output schema, no annotations), it lacks depth on parameter relationships, expected behavior, and output. Missing information about the 'variables' concept.
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 covers all 7 parameters with descriptions, achieving 100% coverage. The description adds minimal value beyond the schema, mentioning 'set of variables' which does not correspond to any parameter, causing slight confusion. 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 that the tool creates an environment for a test target and explains what an environment represents (setup, deployments, test account, etc.). However, it does not explicitly differentiate this tool from sibling tools like createTestTarget or updateEnvironment.
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., updateEnvironment, discovery). The description only states what the tool does, without any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the createTestTarget tool can create a new test target or project. A test target represents an application or service that can be tested using Octomind.
| Name | Required | Description | Default |
|---|---|---|---|
| app | Yes | The app name or project name of the test target | |
| discoveryUrl | Yes | The discovery URL of the test target | |
| skipAutomaticTestCreation | No | Skip automatic test creation right after the test target is created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the tool's purpose without disclosing behavioral traits such as idempotency, side effects, or required permissions. For a creation tool, this is a significant gap.
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, no wasted words. The first sentence states the action, the second provides definition. Efficient and clear.
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?
Adequate for a straightforward creation tool with fully documented parameters, but lacks details on duplication behavior or prerequisites. With 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?
Schema coverage is 100%, so baseline is 3. The description adds context that a test target represents an application or service for testing, but does not clarify parameter meaning 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 it creates a test target or project, using the verb 'create' and specifying the resource. It distinguishes from siblings like 'createEnvironment' and 'deleteTestTarget' by the name and context, though it could explicitly differentiate.
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., createEnvironment, discover). The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deleteEnvironment tool can delete an environment for a given test target. The environment id is unique to the test target. The call is not reversible. an environment represents a specific setup or deployments for a test target. It include a test account when necsesary to login, a header configuration, a discovery url and a set of variables.
| Name | Required | Description | Default |
|---|---|---|---|
| testTargetId | Yes | Unique identifier of the test target | |
| environmentId | Yes | Unique identifier of the environment to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of transparency. It explicitly states the delete is 'not reversible', which is crucial behavioral info. However, it omits other important aspects like permissions, side effects, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the primary action. Each sentence adds value, though some wordiness in the definition of environment could be tightened.
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 cover return values or effects. It notes irreversibility but fails to explain what happens on success or failure (e.g., does it cascade?). The explanation of environment composition is helpful but not directly relevant to deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds context (environment ID unique to test target) that clarifies the relationship between parameters, but does not significantly deepen understanding 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 action ('delete an environment') and the resource ('for a given test target'), making the purpose unambiguous. It also defines what an environment is, distinguishing it from other resources like test targets.
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 does not provide guidance on when to use this tool versus alternatives like deleteTestTarget or updateEnvironment. It lacks explicit conditions, prerequisites, or examples of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the deleteTestTarget tool can delete an existing test target. This operation cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| testTargetId | Yes | Unique identifier of the test target to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the operation is irreversible, which is critical. However, it does not mention authentication needs, rate limits, or what happens to dependent 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?
Two sentences, zero waste. The description is front-loaded with purpose and followed by an important warning.
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 delete tool with no output schema, the description is adequate but incomplete. It lacks details on return values, side effects on related entities, and prerequisites (e.g., that the target must exist).
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 no additional meaning beyond what the schema already provides for the single parameter (testTargetId). It meets the baseline for high schema coverage.
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 specific verb 'delete' and clearly identifies the resource as 'test target', distinguishing it from sibling tools like deleteEnvironment. It is 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?
No guidance on when to use this tool over alternatives or any conditions for use. The only context is that it cannot be undone, which is a warning but not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the discovery tool can create a test case on a given test target with a test case description or prompt. One can either start from the predefined url for that test case or provide a new entry point url.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the test case to create | |
| prompt | Yes | Description or prompt used for test case generation | |
| tagNames | No | Optional list of tag names to assign to the newly discovered test case | |
| externalId | No | Optional external identifier. E.g. a ticket number or test rail id | |
| folderName | No | Optional folder name that the newly discovered test case will be added to | |
| testTargetId | Yes | Unique identifier of the test target | |
| prerequisiteName | No | Optional prerequisite test case name. If set all steps of the prerequisite will be executed before the test case discovery starts | |
| entryPointUrlPath | No | Optional entry point URL path, if not provided the predefined url of the test target will be used |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the tool creates a test case, but does not mention important traits such as whether it is destructive, required permissions, or side effects (e.g., duplicate handling). This lack of detail leaves the agent uninformed about operational impacts.
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 two sentences, directly stating the purpose and a key usage option. It is well-structured and front-loaded, though there is no wasted text.
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 has 8 parameters and no output schema, the description covers the core functionality but omits details like the meaning of prerequisiteName or the return value. For a creation tool with moderate complexity, it provides a basic understanding but lacks completeness for confident 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?
With 100% schema description coverage, all parameters are documented in the schema. The description adds limited extra meaning by relating the entryPointUrlPath parameter to the two usage options, but it does not provide substantial additional context 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 creates a test case on a given test target using a prompt. It uses a specific verb ('create') and resource ('test case'), which distinguishes it from sibling tools like createEnvironment or createTestTarget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it creates a test case and offers two options for the entry point (predefined url or new url). However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks, missing some guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the executeTests tool can trigger a set of tests for a given test target. The test target id is unique to the test target. The tests are executed on the provided url. The context object is used to provide information about the source of the test execution.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL where the tests will be executed | |
| tags | No | List of tags used for filtering the tests to execute | |
| description | No | Optional description of the test execution | |
| testTargetId | Yes | Unique identifier of the test target | |
| environmentName | No | Name of the environment to use for test execution | default |
| variablesToOverwrite | No | Optional variables to override during test execution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions execution on a URL but does not disclose whether it is destructive, synchronous vs async, or any side effects. Lacks behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, but somewhat repetitive ('test target' mentioned twice). Could be more concise without losing meaning. Not outright verbose but not tight.
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, yet description does not explain return values or how to retrieve results. Missing context about async execution, report generation, or how errors are handled. Incomplete for a tool that triggers actions.
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 minimal value. It repeats that testTargetId is unique and url is where tests run, but does not clarify ambiguous parameters like tags or variablesToOverwrite beyond 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?
Description clearly states the tool triggers tests for a given test target, specifying verb and resources. However, it lacks differentiation from sibling tools like search or getTestReports, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getEnvironments tool can retrieve environments for a given test target. an environment represents a specific setup or deployments for a test target. It include a test account when necsesary to login, a header configuration, a discovery url and a set of variables.
| Name | Required | Description | Default |
|---|---|---|---|
| testTargetId | Yes | Unique identifier of the test target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('retrieve') but does not explicitly state idempotency, permissions required, error behavior, or output format. With no annotations, more detail 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?
The description is concise with two sentences. The first sentence states the purpose, and the second adds context about the resource. A minor typo exists, 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 the tool's simplicity (one param, no output schema), the description covers the basic purpose and resource structure but does not clarify whether the return is a list or single environment, nor mention pagination or edge cases.
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 single parameter testTargetId is fully described in the schema with type and format. The description adds minimal value by mentioning 'given test target', but schema coverage is 100%, so baseline score 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 environments for a given test target, using a specific verb and resource. It distinguishes from sibling CRUD tools by its retrieval operation.
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 search or getTestTargets. It does not mention exclusions or specific contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getPrivateLocations tool can retrieve all private locations configured for that org. A private location is a server that can be used to access a test target behind a firewall or VPN.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says it retrieves data. It does not mention side effects, auth needs, or other 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?
Two concise sentences with front-loaded purpose and a definition, 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?
Adequate for a simple list tool with no parameters and no output schema; could optionally specify return format but not required.
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?
No parameters exist; schema coverage is 100%. The description adds value by explaining what private locations are, 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 the tool retrieves all private locations for an org and defines what a private location is, distinguishing it from sibling tools like getEnvironments or getTestTargets.
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; lacks context about prerequisites or situations where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getTestCase tool can retrieve a test case for a given test target and test case id. A test case id is unique to the test target. The test case includes a set of interactions and assertions. it is the result of a discovery or a manual creation.
| Name | Required | Description | Default |
|---|---|---|---|
| testCaseId | Yes | Unique identifier of the test case | |
| testTargetId | Yes | Unique identifier of the test target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a retrieval and describes the result structure (interactions and assertions), but lacks details on error handling, permissions, or behavior if the test case is not found.
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 three sentences with no wasted words, starting with the main purpose. It is efficient but could be slightly more precise.
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 explains the test case content (interactions and assertions) but omits return structure details, error scenarios, or pagination. It is adequate for a simple retrieval but not fully comprehensive.
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 (UUID format). The description adds context about the uniqueness of testCaseId per test target, but does not significantly enhance the meaning 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 a test case for a given test target and test case ID, explains the uniqueness of test case ID per target, and describes the test case content (interactions and assertions). This distinguishes it from siblings like getTestTargets or getTestReport.
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 you have testTargetId and testCaseId, but it does not explicitly state when to use this tool versus alternatives (e.g., getTestReport) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getTestReport tool can retrieve a test report for a given test target and test report id. A test report id is generated when a set of test are executed on a test target. The test report id is unique to the test target.
| Name | Required | Description | Default |
|---|---|---|---|
| testReportId | Yes | Unique identifier of the test report | |
| testTargetId | Yes | Unique identifier of the test target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states retrieval and explains ID generation, but does not disclose behavioral traits like read-only nature, required permissions, or potential errors.
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 with no unnecessary filler, though the first sentence could be more direct ('Retrieves a test report...' vs 'the getTestReport tool can retrieve'). Still well-structured.
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 without output schema, the description is fairly complete but lacks explanation of what exactly is returned (e.g., report fields, status). More detail would improve 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?
The input schema covers 100% of parameters with descriptions (both UUIDs). The description adds no extra meaning beyond restating the parameters, 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 retrieves a test report for a given test target and test report ID. It distinguishes from sibling 'getTestReports' which likely lists reports, and 'getTestCase' which is different. Specific verb and resource.
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 mentioned, but the description implies usage after test execution to obtain the report ID, providing some context. However, it lacks guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getTestReports tool can retrieve test reports for a given test target. Test reports are generated when set of tests are executed. The test report id is unique to the test target.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Optional key for filtering test reports | |
| filter | No | Optional filters for test reports | |
| testTargetId | Yes | Unique identifier of the test target |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions retrieval but omits details like pagination, ordering, error behavior, or what happens if no reports exist. The note about report ID uniqueness adds minimal behavioral insight.
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 sentences and reasonably concise. The first sentence could be more direct (e.g., 'Retrieves test reports for a test target'), but overall it is not 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 three parameters including nested objects, no output schema, and no annotations, the description is incomplete. It does not explain the filter parameter, the key parameter's purpose, or how to interpret the results, and it fails to differentiate from the sibling getTestReport 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 no extra meaning beyond the schema; it does not explain how filter or key parameters work or how they relate to the retrieval.
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 test reports for a given test target, which is a specific verb+resource. However, it fails to distinguish from the sibling tool 'getTestReport' (singular), leaving ambiguity about whether this returns a single report or multiple.
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 getTestReport. The description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the getTestTargets tool can retrieve all test targets or projects. Test targets represent applications or services that can be tested using Octomind.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the tool 'retrieve all test targets', implying read-only, but does not explicitly confirm no side effects, permissions, or rate limits. The lack of transparency could lead to misuse.
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 sentences and front-loaded with the action. It is concise, though the second sentence adds context about what test targets represent. 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?
Given zero parameters and no output schema, the description should explain the return format, pagination, or filtering capabilities. It merely states what is retrieved, leaving the agent without crucial context for processing results.
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 description coverage is 100%. The description adds no parameter-specific meaning, but with no parameters, it is not required. Baseline 4 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 identifies the tool's purpose: retrieving all test targets or projects. The verb 'retrieve' is appropriate, and the resource is specified. However, the phrasing 'or projects' introduces slight ambiguity if they are distinct entities.
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 getEnvironments or search. Sibling tools suggest CRUD operations, but no exclusions or contexts are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current version of the Octomind MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly identifies the tool as a read-only operation returning version info. While it does not specify error handling or server dependencies, the simplicity of the operation makes it sufficiently 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?
The description is a single, concise sentence that is front-loaded with the action ('Returns'). Every word is necessary, with no waste.
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 (no parameters, no output schema), the description provides all necessary context. It explains what the tool returns and is complete for its purpose.
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 the description does not need to add parameter information. According to the guidelines, 0 parameters results in a baseline score of 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 clearly states the tool returns the current version of the Octomind MCP server. It uses a specific verb and resource, and it is easily distinguishable from sibling tools like createEnvironment or deleteTestTarget.
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 version information is needed, but it lacks explicit guidance on when to use this tool versus alternatives or any exclusions. No 'when-not' or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the search tool can be used to search the octomind documentation for a given query. The search results are returned as a list of links to the documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that results are a list of links but does not detail any limitations, pagination, ranking, or query syntax. Basic behavior is described, but further context is missing.
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 sentences with no redundant information, front-loaded with the main purpose. Every word 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?
Given the tool's simplicity (one parameter, no output schema), the description fully covers its purpose and output. No additional context is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond the schema's 'Search query' description. Baseline score of 3 is appropriate as the description does not enhance parameter understanding.
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 searches Octomind documentation and returns links, with a specific verb and resource. It is easily distinguishable from sibling tools which focus on managing environments and 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?
The description indicates the tool is for searching documentation but does not provide explicit guidance on when to use it versus alternatives, nor does it mention when not to use it. The context is clear by contrast with siblings but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the updateEnvironment tool can update an environment for a given test target. an environment represents a specific setup or deployments for a test target. It include a test account when necsesary to login, a header configuration, a discovery url and a set of variables.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional new name for the environment | |
| basicAuth | No | Optional basic authentication credentials, if discovery needs authentication | |
| testAccount | No | Optional test account credentials, if discovery needs authentication | |
| discoveryUrl | No | Optional new discovery URL | |
| testTargetId | Yes | Unique identifier of the test target | |
| environmentId | Yes | Unique identifier of the environment | |
| privateLocationName | No | Optional name of the private location, if discovery needs to discover in a private location e.g. behind a firewall or VPN | |
| additionalHeaderFields | No | Optional additional HTTP header fields, if discovery needs additional headers to be set |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as idempotency, destructive nature, or what happens if inputs are invalid. The description merely states 'can update' without elaboration.
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 reasonably concise but includes a redundant definition of environment and a typo ('necsesary'). It could be more streamlined.
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 adequate but leaves gaps. It does not explain return values, error handling, or relationships between required and optional fields.
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 adds some context about environment components (test account, header configuration, etc.) but does not provide deeper semantics beyond 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?
Description clearly states it updates an environment for a test target and defines what an environment includes. However, it does not differentiate from sibling tools like createEnvironment or deleteEnvironment.
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. Lacks context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
the updateTestTarget tool can update an existing test target. A test target represents an application or service that can be tested using Octomind.
| Name | Required | Description | Default |
|---|---|---|---|
| app | No | The app name or project name of the test target | |
| discoveryUrl | No | The discovery URL of the test target | |
| testTargetId | Yes | Unique identifier of the test target to update | |
| timeoutPerStep | No | The timeout per step in milliseconds | |
| testIdAttribute | No | The attribute name of the test ID | |
| testRailIntegration | No | TestRail integration configuration | |
| skipAutomaticTestCreation | No | Skip automatic test creation right after the test target is created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool 'updates' but does not disclose side effects, required permissions, reversibility, or whether updates are partial or full replacements. This lack of behavioral context is a significant gap 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 concisely composed of two sentences, front-loading the purpose and a brief definition. There is no extraneous text, though it could be slightly more structured by ordering essential information.
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 (7 parameters, nested objects, no output schema), the description is incomplete. It does not explain what the tool returns, whether updates are additive, or how to handle partial updates. Without output schema, the agent has no guidance on expected response or success/failure signals.
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 each parameter having a description. The tool description adds no extra information beyond the schema, such as parameter relationships or update semantics. Baseline of 3 is appropriate as the schema already documents 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?
The description clearly states that the tool updates an existing test target and defines what a test target is. However, it does not differentiate from sibling tools like createTestTarget or deleteTestTarget, relying solely on the verb 'update'.
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 create a new target vs. updating an existing one. There is no mention of 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.
v1.0.0createEnvironmentcreateTestTargetdeleteEnvironmentdeleteTestTargetdiscoveryexecuteTestsgetEnvironmentsgetPrivateLocationsgetTestCasegetTestReportgetTestReportsgetTestTargetsgetVersionsearchupdateEnvironmentupdateTestTargetEach tool has a clearly distinct purpose: CRUD for environments and test targets, test execution, reporting, search, and version info. No overlap or ambiguity.
All tool names use camelCase consistently, with a verb+noun pattern for most (e.g., createEnvironment, deleteTestTarget). Two single-word names ('discovery', 'search') deviate slightly but remain in the same style.
16 tools cover the domain thoroughly without being excessive. The scope (managing test targets, environments, test cases, reports, execution, and configuration) justifies the count.
Core CRUD operations exist for environments and test targets. Missing operations include updating/deleting test cases and deleting reports, but the main workflows are covered.
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
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/OctoMind-dev/octomind-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
