testit-mcp-server

create_configuration

Creates an environment configuration, such as browser or OS, for a TestIT project with optional parameters, description, and default setting.

Instructions

Create a configuration (environment such as browser/OS). Extra ConfigurationPostModel fields can go into "payload".

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_configuration"
  }
}

Input Schema

Name	Required	Description
`name`	Yes
`payload`	No
`isDefault`	No	Make it the project's default (default false).
`projectId`	No	Project UUID (defaults to TESTIT_PROJECT_ID).
`parameters`	No	Key/value parameters, e.g. {"browser": "firefox", "os": "linux"}.
`description`	No
`projectName`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 14, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds no behavioral context beyond that: no note on whether duplicate names are rejected or merged, no mention of permissions, and no statement of what is returned on success. The one addition, that 'payload' accepts extra ConfigurationPostModel fields, is useful but is a parameter detail rather than runtime behavior.

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

Conciseness4/5

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

Two short sentences, front-loaded with the core action and domain definition, with the payload clarification following. No filler, though the parenthetical definition could have been folded more tightly into the first clause.

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

Completeness2/5

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

For a create tool with 7 parameters, a nested passthrough object, and no output schema, the description is thin. It says nothing about the required 'name' field's uniqueness or constraints, how project scoping resolves, or what a successful call returns, leaving the agent to infer behavior from a partially described schema.

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?

With schema coverage at 43% and 7 parameters, the description does real work by explaining that 'payload' is a passthrough for additional ConfigurationPostModel fields, which the bare 'object/additionalProperties: true' schema does not convey. However, it leaves 'name' (the sole required field), 'projectName', and the relationship between 'projectId' and 'projectName' undocumented, so it only partially compensates for the coverage gap.

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

Purpose4/5

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

States a specific verb and resource ('Create a configuration') and immediately defines the domain concept as 'environment such as browser/OS', which disambiguates it from create_configuration_parameter and set_configuration without naming them. It stops short of explicitly contrasting with the closely related parameter tools.

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

Usage Guidelines2/5

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

The description never says when to use this tool rather than create_configuration_parameter, set_configuration, or update_configuration, nor does it state any prerequisites such as an existing project. The only guidance offered is about where to place extra fields, which is parameter mechanics rather than usage routing.

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

Deploy Server