GASSAPI MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| health_checkA | Check if the MCP server is running properly |
| get_project_contextB | Get project context including environments and folders. Validates MCP token and returns enriched project data. |
| list_environmentsC | List all environments for current project |
| get_environment_detailsC | Get detailed environment information including variables |
| create_environmentC | Create a new environment with variables |
| update_environment_variablesC | Update environment variables (add/update/remove variables) |
| set_default_environmentC | Set an environment as the default for the project |
| delete_environmentC | Delete an environment |
| list_foldersC | List all folders for current project with optional tree view |
| create_folderC | Create a new folder in the project |
| update_folderC | Update folder name, description, or parent |
| delete_folderC | Delete a folder and all its contents |
| get_folder_detailsC | Get detailed information about a specific folder |
| list_endpointsB | List all endpoints with optional filtering by folder |
| get_endpoint_detailsC | Get detailed endpoint configuration with folder information |
| create_endpointC | Create a new endpoint in a folder |
| update_endpointC | Update existing endpoint configuration |
| test_endpointC | Test a single endpoint with optional environment variables |
| execute_flowC | Execute a flow with sequential or parallel endpoint testing |
| create_flowA | Create a new flow in the project using Steps format for API automation Example format: { "name": "User Registration Flow", "description": "Complete user registration with email verification", "folderId": "fld_456", "flow_data": { "version": "1.0", "steps": [ { "id": "register_user", "name": "Register New User", "method": "POST", "url": "{{baseUrl}}/api/users/register", "headers": {"Content-Type": "application/json"}, "body": "{"name": "{{userName}}", "email": "{{userEmail}}", "password": "{{password}}"}", "outputs": {"userId": "response.body.id", "activationToken": "response.body.token"} }, { "id": "verify_email", "name": "Verify Email Address", "method": "POST", "url": "{{baseUrl}}/api/auth/verify", "headers": {"Content-Type": "application/json"}, "body": "{"token": "{{register_user.activationToken}}"}", "outputs": {"verificationStatus": "response.body.status"} } ], "config": {"delay": 1000, "retryCount": 2, "parallel": false} }, "flow_inputs": [ {"name": "baseUrl", "type": "string", "required": true, "description": "Base API URL"}, {"name": "userName", "type": "string", "required": true, "description": "User full name"}, {"name": "userEmail", "type": "email", "required": true, "description": "User email"}, {"name": "password", "type": "password", "required": true, "description": "User password"} ] } 2-step API Testing Example: { "name": "API Integration Test", "description": "Test user creation and retrieval", "flow_data": { "version": "1.0", "steps": [ { "id": "create_user", "name": "Create User", "method": "POST", "url": "https://api.example.com/users", "headers": {"Authorization": "Bearer {{apiKey}}"}, "body": "{"name": "Test User", "email": "test@example.com"}", "expectedStatus": 201, "outputs": {"newUserId": "response.body.id"} }, { "id": "get_user", "name": "Retrieve Created User", "method": "GET", "url": "https://api.example.com/users/{{create_user.newUserId}}", "headers": {"Authorization": "Bearer {{apiKey}}"}, "expectedStatus": 200, "outputs": {"userData": "response.body"} } ] } } Common mistakes:
|
| get_flow_detailsC | Get detailed information about a specific flow |
| list_flowsC | List flows in the current project |
| delete_flowC | Delete a flow |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Every tool has a clearly distinct purpose targeting specific resources and actions, with no apparent overlap. For example, create_endpoint, get_endpoint_details, update_endpoint, and test_endpoint all operate on endpoints but with distinct CRUD operations, while tools like execute_flow and test_endpoint serve different testing scopes.
All tools follow a consistent verb_noun pattern using snake_case, such as create_endpoint, list_environments, update_folder, and delete_flow. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 23 tools, the count is slightly high but reasonable for a comprehensive API automation and testing server covering endpoints, environments, flows, and folders. It includes CRUD operations, listing, testing, and project management, which justifies the breadth, though it might feel heavy for some use cases.
The tool set provides complete CRUD and lifecycle coverage for the domain of API automation, including endpoints, environments, flows, and folders. It covers creation, retrieval, updating, deletion, listing, testing, and execution, with no obvious gaps that would hinder agent workflows, such as health_check for server status and get_project_context for project management.