The interesting half is executions: an agent that has just run a test can record the result, tag it, and leave the trail attached to the scenario rather than in a chat log. Projects stay read-only, which is a sensible line — an agent can read the environment and test-account context it needs without being able to restructure the project.
The MCP surface of Gwirian, a BDD feature-management platform where teams keep features, Given/When/Then scenarios, and the record of which scenarios have been run. The server authenticates with a workspace-scoped API token, and every operation runs inside that token's workspace — a different workspace means a different token.
- Read access to projects, including their executions and team members, and a `context` field carrying test context such as environments, URLs and test accounts — `list_projects`, `get_project`
- Full CRUD on features: `list_features`, `get_feature`, `create_feature`, `update_feature`, `delete_feature`
- Full CRUD on the scenarios under a feature: `list_scenarios`, `get_scenario`, `create_scenario`, `update_scenario`, `delete_scenario`
- Full CRUD on scenario executions, so an agent can record what it ran and what happened — `list_scenario_executions`, `get_scenario_execution`, `create_scenario_execution`, `update_scenario_execution`, `delete_scenario_execution`
- A `tag_list` on executions for test type, version or bugfix metadata, accepted on create and update and returned on list and get
A Gwirian workspace and an API token generated from its workspace settings. The token goes in an `Authorization: Bearer` header on the server URL — `http://localhost:3000/mcp` in development, your own domain in production — and it determines which workspace every call touches. Tokens are workspace-scoped, so covering several workspaces means configuring several servers. The platform itself is a Rails application you run; the repository ships Docker and Kamal deployment guides.