list_projectsLABSCO SUMMARY
The scenario record becomes something an agent can write to.
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.
What it is
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.
What you get
- Read access to projects, including their executions and team members, and a
contextfield 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_liston executions for test type, version or bugfix metadata, accepted on create and update and returned on list and get
Requirements
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.
Setup effort
Follow the published steps
USE CASES
Turning a requirement into BDD scenarios
Create the feature, then add scenarios under it with the Given/When/Then steps, without leaving the assistant.
Recording what a test run actually did
Log an execution against the scenario with a tag for test type and version, so the history lives with the specification.
Picking up the environment details before running anything
Read the project's context field for environments, URLs and test logins instead of asking a human for them.
Reviewing coverage for a feature
List the scenarios under a feature and read each one's executions to see what has been exercised and what has not.
17 tools
Listed in project docs. Your client may show a different list.
get_projectlist_featuresget_featurecreate_featureupdate_featuredelete_featurelist_scenariosget_scenariocreate_scenarioupdate_scenariodelete_scenariolist_scenario_executionsget_scenario_executioncreate_scenario_executionupdate_scenario_executiondelete_scenario_executionBEFORE YOU INSTALL
What to know first
Tools you get
17 tools named in the project's documentation. Every tool works in the workspace tied to your API token; there is no tool to switch workspaces, so working across several means using several tokens.
Requires
- Ruby 4.0.0
- Rails 8.0
INSTALLATION
Connect your client
Server setup
Log in to your Gwirian account, go to workspace settings (or the workspace members page) and generate an API token for the workspace, then copy it
Determine the server URL — development: http://localhost:3000/mcp, production:
<YOUR_SERVER_URL>/mcpOpen Cursor Settings → Features → Model Context Protocol → Add Server (config file ~/.cursor/mcp.json) and add the mcpServers block with the Authorization: Bearer header
MCP Clients
Cursor — local
{
"mcpServers": {
"gwirian": {
"url": "http://localhost:3000/mcp",
"headers": {
"Authorization": "Bearer <YOUR_API_TOKEN>"
}
}
}
}Cursor — remote
{
"mcpServers": {
"gwirian": {
"url": "<YOUR_SERVER_URL>/mcp",
"headers": {
"Authorization": "Bearer <YOUR_API_TOKEN>"
}
}
}
}