The GASSAPI MCP Server enables AI assistants to manage and document API projects through semantic context and comprehensive testing tools.
Core Capabilities:
Project & Health: Check server status (health_check) and retrieve project context with environments and folder structures (get_project_context). Validate MCP tokens and access project data.
Environment Management: Create, list, update, and delete environments with variables. Set default environments, filter by active/inactive status, and perform merge or replace operations on variables.
Folder Organization: Create hierarchical folder structures to organize endpoints and flows. Update, move, delete folders, and view them in tree format.
Endpoint Documentation: Create and update API endpoints with semantic context including purpose, request parameters, response schemas, and header documentation. Support for all HTTP methods (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS). List and filter endpoints by folder or method.
API Testing: Test individual endpoints with environment variables and custom configurations. Configure timeouts, retries, error handling, and dry-run mode for validation.
Flow Automation: Create and execute multi-step API workflows with sequential or parallel execution, variable chaining between steps, dynamic inputs, output mapping, and conditional logic. List, filter, and delete flows.
AI Integration: Provide semantic context for AI understanding of API purposes, automated documentation for frontend code generation, and integration with Claude Code and Cursor AI assistants.
Provides examples for testing API endpoints and backend connectivity using curl commands
Built on Node.js runtime for executing the MCP server and managing API integrations
Distributed and installed through npm package manager for easy deployment
Integrates with PHP backend APIs for endpoint documentation and testing
Enables AI-powered generation of React components based on documented API endpoints
Provides TypeScript examples for endpoint creation and API integration workflows
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., "@GASSAPI MCP Server create a new environment called 'staging' with variables for our API"
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.
Model Context Protocol (MCP) server untuk integrasi GASSAPI dengan AI assistants.
Node.js >= 16.0.0
npm atau yarn
Akses ke GASSAPI backend
Related MCP server: API Registry MCP Server
# Install from NPM registry
npm install -g gassapi-mcp2
# Test installation
gassapi-mcp2 --help
# Add to Claude Code
claude mcp add --transport stdio gassapi-mcp2 gassapi-mcp2Login ke backend GASSAPI untuk mendapatkan access token:
curl -X POST "http://mapi.gass.web.id/?act=login" \
-H "Content-Type: application/json" \
-d '{"email": "your-email@example.com", "password": "YourPassword"}'List projects untuk mendapatkan project ID:
curl -X GET "http://mapi.gass.web.id/?act=projects" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN"Buat file gassapi.json di working directory Anda dengan template:
{
"project": {
"id": "YOUR_PROJECT_ID_HERE",
"name": "Your Project Name",
"description": "Your project description"
},
"mcpClient": {
"token": "YOUR_TOKEN_HERE"
}
}Ganti dengan:
YOUR_PROJECT_ID_HERE → Project ID dari Step 2
YOUR_TOKEN_HERE → Token dari Step 1
Note: Base URL sudah hardcoded ke http://mapi.gass.web.id - tidak perlu konfigurasi API URL.
# Test help command
gassapi-mcp2 --help
# Test version
gassapi-mcp2 --version
# Test status
gassapi-mcp2 --status# List MCP servers
claude mcp list
# Test connection
# Restart Claude Code dan coba gunakan GASSAPI tools# Clone repository
git clone <repository-url>
cd gassapi-mcp2
# Install dependencies
npm install
# Build
npm run build
# Development mode
npm run dev
# Type checking
npm run typecheck{
"project": {
"id": "proj_abc123def456",
"name": "Project Name",
"description": "Project description"
},
"mcpClient": {
"token": "plain_text_mcp_token_here"
}
}Note: Base URL sudah hardcoded ke http://mapi.gass.web.id - tidak perlu api_base_url configuration.
MCP server akan otomatis mencari gassapi.json di:
Current working directory
Parent directories (hingga 5 levels up)
get_project_context - Get project info with environments and folders
health_check - Check MCP server status
list_environments - List all environments
get_environment_details - Get detailed environment info
create_environment - Create new environment
update_environment_variables - Update environment variables
set_default_environment - Set default environment
delete_environment - Delete environment
list_folders - List project folders
create_folder - Create new folder
update_folder - Update folder details
move_folder - Move folder to different parent
delete_folder - Delete folder
get_folder_details - Get folder details
list_endpoints - List all endpoints
get_endpoint_details - Get detailed endpoint configuration
create_endpoint - Create endpoint with semantic context
update_endpoint - Update endpoint configuration
create_flow - Create automation flow
execute_flow - Execute flow
get_flow_details - Get flow details
list_flows - List all flows
delete_flow - Delete flow
test_endpoint - Test single endpoint
test_multiple_endpoints - Test multiple endpoints
create_test_suite - Create test suite
list_test_suites - List test suites
create_endpoint(
name: "User Registration",
method: "POST",
url: "/api/auth/register",
folder_id: "folder_authentication",
description: "Endpoint untuk registrasi user baru dengan email verification",
purpose: "Public user registration dengan email verification required",
headers: {
"Content-Type": "application/json"
},
body: '{"name": "{{userName}}", "email": "{{userEmail}}", "password": "{{password}}"}',
request_params: {
"name": "Full name untuk display",
"email": "Email address untuk login dan communication",
"password": "User password (min 8 chars, include uppercase, lowercase, numbers)"
},
response_schema: {
"user_id": "Unique user identifier",
"name": "User display name",
"email": "User email address",
"status": "Account status (active|inactive|suspended)",
"verification_required": "Whether email verification needed"
}
)1. Backend Developer:
// Di PHP code (sudah ada)
public function register() {
// Logic untuk registrasi user
// Return user data atau error
}2. Documentation Team:
// Gunakan MCP tools untuk catat
create_endpoint(
name: "User Registration",
method: "POST",
url: "/api/auth/register",
// ... semantic context untuk AI understanding
)3. AI Frontend Team:
// AI dapat endpoint info dan generate UI
get_endpoint_details(endpoint_id: "ep_user_reg")
// AI understands purpose dan generate appropriate React componentscreate_endpoint(
name: "User Registration",
method: "POST",
url: "/api/auth/register",
folder_id: "folder_authentication",
description: "Public user registration endpoint dengan email verification",
purpose: "New user account creation dengan email verification untuk security",
// Request parameters documentation
request_params: {
"name": "User's full name for display purposes",
"email": "User's email address for login and communication",
"password": "Password with security requirements (8+ chars, mixed case, numbers)",
"confirm_password": "Password confirmation untuk prevent typos"
},
// Response schema documentation
response_schema: {
"user_id": "Unique system identifier untuk user record",
"name": "User display name untuk UI",
"email": "User email address untuk authentication",
"status": "Account status: active|inactive|suspended|pending_verification",
"email_verified": "Email verification status flag",
"verification_token": "Email verification token (if required)",
"created_at": "Account creation timestamp"
},
// Important implementation notes
header_docs: {
"Content-Type": "Application/JSON untuk request body",
"Accept": "Application/JSON untuk response format"
}
)Field | Type | Purpose | Example | AI Benefit |
| string | Business purpose (max 250 chars) | "User registration with email verification" | AI understands use case and generates appropriate UI flow |
| object | Parameter documentation |
| AI generates correct form fields with validation |
| object | Response field documentation |
| AI handles response data correctly in frontend code |
| object | Header documentation |
| AI includes proper headers in API calls |
# Build project
npm run build
# Run development server
npm run dev
# Run production server
npm start
# Type checking
npm run typecheck
# Clean build
npm run clean# Run basic test
npm test
# Run all tests
node test/runners/run-all-tests.js
# Run specific category
node test/runners/run-category-tests.js endpoints
# Run semantic fields tests
node test/unit/endpoints/semantic-test-runner.js{
"project": {
"id": "proj_abc123def456",
"name": "Project Name",
"description": "Project description"
},
"mcpClient": {
"token": "plain_text_mcp_token_here"
}
}Note: Base URL sudah hardcoded ke http://mapi.gass.web.id - tidak perlu api_base_url configuration.
MCP server akan otomatis mencari gassapi.json di:
Current working directory
Parent directories (hingga 5 levels up)
1. "No configuration found"
Pastikan gassapi.json ada di working directory atau parent directory
Cek format JSON valid
2. "Invalid token"
Login kembali ke backend untuk dapat token baru
Pastikan token belum expired
3. "Backend unavailable"
Pastikan backend server sudah berjalan di http://mapi.gass.web.id
Check koneksi internet dan firewall settings
4. MCP server not found
Install globally: npm install -g gassapi-mcp2
Atau gunakan npx: npx gassapi-mcp2
# Check MCP server status
gassapi-mcp2 --status
# Test help
gassapi-mcp2 --help
# Test version
gassapi-mcp2 --version
# Test backend connectivity
curl "http://mapi.gass.web.id/?act=health"User: "Show my project"
AI: Uses get_project_context tool
User: "Create endpoint for user registration"
AI: create_endpoint dengan semantic fields
User: "Test this endpoint"
AI: test_endpoint dengan environment variablesUser: "Create flow untuk user registration dengan email verification"
AI: create_flow dengan multiple steps dan validation
User: "List semua endpoints di folder Authentication"
AI: list_endpoints dengan filter folder_idFork repository
Create feature branch
Run tests: npm test
Submit pull request
MIT License
🎯 Key Benefits:
✅ Semantic context untuk AI understanding
✅ Real-time endpoint management
✅ Automated flow creation
✅ Comprehensive testing tools
✅ Easy integration dengan Claude Code/Cursor
Create a new endpoint in a folder
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Endpoint name (required) | |
| method | Yes | HTTP method (required) | |
| url | Yes | Endpoint URL (required) | |
| folder_id | Yes | Folder ID to create endpoint in (required) | |
| description | No | Endpoint description (optional) | |
| headers | No | Request headers as key-value pairs | |
| body | No | Request body (JSON string) | |
| purpose | No | Business purpose - what this endpoint does (optional) | |
| request_params | No | Parameter documentation: {param_name: "description"} | |
| response_schema | No | Response field documentation: {field_name: "description"} | |
| header_docs | No | Header documentation: {header_name: "description"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Create a new endpoint' implies a write/mutation operation, but the description doesn't mention permissions required, whether creation is idempotent, what happens on duplicate names, or what the response contains (success/failure indicators, created endpoint ID). For a mutation tool with 11 parameters and no annotation coverage, this is a significant gap in behavioral context.
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, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information. Every word earns its place, making it easy to parse quickly.
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 (11 parameters, mutation operation, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what an 'endpoint' represents in this system, what happens after creation, error conditions, or relationship to other tools. For a creation tool with many parameters and no structured output documentation, the description should provide more contextual guidance about the operation's scope and outcomes.
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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions, enums, and required/optional status. The description adds no parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('Create') and resource ('new endpoint in a folder'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar creation tools like create_environment or create_flow, which would require mentioning what specifically makes an endpoint distinct from those other resources.
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 no guidance on when to use this tool versus alternatives. With sibling tools like create_folder, update_endpoint, and list_endpoints available, there's no indication of prerequisites (e.g., folder must exist), sequencing (create folder first), or when to choose create_endpoint over other endpoint-related tools. The description is purely functional without contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new environment with variables
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Environment name | |
| description | No | Environment description | |
| variables | No | Environment variables (JSON string, object, or comma-separated key=value pairs) | |
| isDefault | No | Set as default environment | |
| projectId | No | Project ID (optional, will use current project if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Create') but doesn't describe what happens on success/failure, permissions required, whether the environment is immediately usable, or any side effects. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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 a single, efficient sentence that front-loads the core action ('Create a new environment with variables'). There is no wasted text, and it directly communicates the essential purpose without unnecessary elaboration.
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 of creating an environment (a mutation with 5 parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, success criteria, or return values, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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 description mentions 'variables' but doesn't elaborate beyond what the schema provides. With 100% schema description coverage, the schema already documents all 5 parameters thoroughly (e.g., 'variables' as JSON string/object/comma-separated). The description adds no additional parameter context, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb 'Create' and the resource 'new environment with variables', making the purpose immediately understandable. It distinguishes from siblings like 'delete_environment' or 'update_environment_variables' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools like 'create_endpoint' or 'create_flow' beyond the resource type.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project), exclusions, or comparisons to siblings like 'set_default_environment' or 'update_environment_variables'. Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
❌ Empty steps array
❌ Missing required step fields (id, name, method, url)
❌ Invalid step references (must use {{step.output}})
✅ Use {{input.var}} for flow inputs
✅ Use {{step.output}} for chaining steps
✅ Define outputs to pass data between steps
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the flow (required) | |
| description | No | Description of the flow (optional) | |
| folderId | No | Folder ID to organize the flow (optional) | |
| flow_data | No | Flow data following backend Steps format | |
| flow_inputs | No | Dynamic input definitions for variable interpolation | |
| is_active | No | Flow active status (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining the Steps format, providing detailed examples, and listing common mistakes. It clarifies the mutation nature (creation), expected input structure, and validation requirements, though it doesn't mention permissions, rate limits, or creation side effects.
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 excessively long (over 500 words) with two full JSON examples and extensive formatting details. While informative, it's not front-loaded - the core purpose is buried among examples. Many details could be moved to documentation rather than crammed into the tool description.
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 complex creation tool with 6 parameters, nested objects, and no output schema, the description provides substantial context through examples and common mistakes. However, it lacks information about what happens after creation (e.g., flow ID returned, activation status) and doesn't mention error handling or system limitations.
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 description coverage is 100%, so the baseline is 3. The description adds value through examples showing how parameters like 'flow_data.steps' and 'flow_inputs' should be structured, but doesn't provide additional semantic meaning beyond what's already documented in the comprehensive 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?
The description clearly states the tool creates a new flow using Steps format for API automation, specifying both the action ('create') and resource ('flow in the project'). It distinguishes from siblings like 'execute_flow' (runs flows) and 'delete_flow' (removes flows) by focusing on creation with specific formatting requirements.
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 through examples and common mistakes, suggesting it's for creating API automation flows, but doesn't explicitly state when to use this versus alternatives like 'create_endpoint' or 'create_environment'. It provides practical guidance on formatting but lacks explicit contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new folder in the project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Folder name | |
| description | No | Folder description | |
| parentId | No | Parent folder ID (optional, creates root-level folder if not provided) | |
| projectId | No | Project ID (optional, will use current project if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a creation tool, implying a write operation, but doesn't cover permissions, error conditions, rate limits, or what happens on success (e.g., returns a folder ID). This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 is a mutation (folder creation) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, potential side effects, or error handling, which are critical for an agent to use it effectively in a project context.
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 100% description coverage, clearly documenting all four parameters. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 without compensating value.
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 ('Create') and resource ('new folder in the project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_flow' or 'create_environment' beyond the resource type, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project), exclusions (e.g., when not to create folders), or comparisons to related tools like 'update_folder' or 'delete_folder', leaving the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an environment
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete an environment' implies a destructive, irreversible mutation, but the description doesn't mention: what happens to associated resources, whether this requires special permissions, if there are confirmation prompts, what the success/failure responses look like, or any rate limits. For a destructive operation with zero annotation coverage, this is inadequate.
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 maximally concise - a single three-word phrase that gets straight to the point. There's zero wasted language or unnecessary elaboration. While it may be too brief for completeness, as a standalone statement it's perfectly structured and front-loaded.
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 destructive deletion tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context: what 'deleting an environment' entails (does it cascade to child resources?), what permissions are required, what the return value is, or error conditions. Given the complexity of environment management and the lack of structured safety hints, the description should provide more operational context.
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 description coverage is 100% (the single parameter 'environmentId' has a clear description), so the baseline is 3. The tool description adds no additional parameter information beyond what the schema already provides - it doesn't explain where to find environment IDs, what format they use, or provide examples. The description doesn't compensate for schema gaps because there are none to compensate for.
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 'Delete an environment' clearly states the verb ('Delete') and resource ('environment'), making the basic purpose understandable. However, it doesn't differentiate from sibling tools like 'delete_flow' or 'delete_folder' - it's a generic statement that could apply to any deletion tool. The purpose is clear but lacks sibling distinction.
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 no guidance on when to use this tool versus alternatives. There are multiple sibling tools (create_environment, set_default_environment, update_environment_variables, list_environments, get_environment_details) that work with environments, but the description offers no context about when deletion is appropriate versus modification or querying. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a flow
| Name | Required | Description | Default |
|---|---|---|---|
| flowId | Yes | ID of the flow to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, irreversible mutation, but the description doesn't specify permissions required, whether deletion is permanent, error handling (e.g., if flow doesn't exist), or side effects. For a destructive tool with zero annotation coverage, this is inadequate.
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 extremely concise with a single sentence ('Delete a flow'), which is front-loaded and wastes no words. For a simple tool with one parameter, this brevity is efficient and appropriate, earning full marks for conciseness.
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 destructive nature, lack of annotations, and no output schema, the description is incomplete. It fails to address critical aspects like confirmation needs, return values, or error cases. With siblings offering related operations (e.g., 'get_flow_details'), more context is needed for safe and effective 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?
Schema description coverage is 100%, with the single parameter 'flowId' fully documented in the schema. The description adds no additional parameter details beyond what the schema provides, such as format examples or sourcing instructions. Baseline 3 is appropriate when the schema handles all parameter documentation.
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') and resource ('a flow'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_environment' or 'delete_folder' by specifying the resource type. However, it doesn't specify what constitutes a 'flow' or the scope of deletion, keeping it from a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing flow details first), consequences of deletion, or comparisons to tools like 'get_flow_details' for verification. With siblings including 'create_flow' and 'execute_flow', this lack of context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a folder and all its contents
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | Folder ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a folder and all contents, implying a destructive, irreversible operation, but lacks details on permissions needed, error handling (e.g., non-existent folders), or confirmation prompts. This 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 a single, efficient sentence with zero wasted words, front-loading the core action and resource. It's appropriately sized for a simple tool with one parameter.
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 destructive tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, reversibility, or response format, which are critical for safe agent invocation given the tool's complexity.
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 100% description coverage, with 'folderId' clearly documented. The description adds no parameter-specific information beyond implying deletion scope, so it meets the baseline of 3 where the schema does the heavy lifting.
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') and resource ('a folder and all its contents'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'delete_environment' or 'delete_flow' beyond the resource type, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., folder existence), exclusions (e.g., system folders), or comparisons with siblings like 'update_folder', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a flow with sequential or parallel endpoint testing
| Name | Required | Description | Default |
|---|---|---|---|
| flowId | Yes | ID of the flow to execute | |
| variables | No | Variables for flow interpolation (JSON string or object, or comma-separated key=value pairs) | |
| mode | No | Execution mode (sequential or parallel) | |
| timeout | No | Flow timeout in milliseconds | |
| stopOnError | No | Stop execution on first error | |
| maxConcurrency | No | Maximum concurrent steps for parallel execution | |
| dryRun | No | Run in dry-run mode (no actual HTTP requests) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'sequential or parallel endpoint testing' which hints at execution behavior, but fails to describe critical aspects like whether this is a read-only or mutating operation, what permissions are required, error handling beyond 'stopOnError' parameter, or what the output looks like. For a tool with 7 parameters and no annotations, this is insufficient.
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, efficient sentence that gets straight to the point without unnecessary words. Every part of the sentence contributes to understanding the tool's purpose, making it perfectly concise and 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 tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'flow' is in this context, what 'endpoint testing' entails, what happens during execution, or what the tool returns. The description leaves too many questions unanswered for proper agent usage.
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 description doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It mentions 'sequential or parallel' which relates to the 'mode' parameter, but this is already covered by the schema's enum and description. With high schema coverage, the 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 the action ('execute') and resource ('a flow') with additional context about 'sequential or parallel endpoint testing', which helps understand the tool's function. However, it doesn't explicitly differentiate from sibling tools like 'test_endpoint' or 'create_flow', which would have been needed for a perfect score.
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 no guidance on when to use this tool versus alternatives like 'test_endpoint' or 'create_flow', nor does it mention prerequisites or typical use cases. It simply states what the tool does without context about appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed endpoint configuration with folder information
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Endpoint ID to get details for (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get' implies a read operation but doesn't disclose behavioral traits like whether it requires authentication, rate limits, error handling, or what 'detailed' entails beyond folder info. This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed endpoint configuration' includes, how folder information is structured, or the return format. For a tool that likely returns complex data, this leaves too much unspecified.
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 100% description coverage, with 'endpoint_id' clearly documented as required. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so 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 clearly states the verb ('Get') and resource ('detailed endpoint configuration with folder information'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_environment_details' or 'get_folder_details' beyond mentioning 'folder information', which is a minor gap.
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 no guidance on when to use this tool versus alternatives like 'list_endpoints' or other 'get_' tools. It lacks context about prerequisites, such as needing an endpoint ID from listing operations, or exclusions for 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.
Get detailed environment information including variables
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment ID to get details for | |
| includeVariables | No | Include environment variables in response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a read-only operation ('Get') but doesn't specify permissions, rate limits, response format, or error handling. This is inadequate for a tool with potential complexity in environment details.
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, efficient sentence with zero wasted words. It front-loads the core purpose ('Get detailed environment information') and includes a key detail ('including variables') without unnecessary elaboration.
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 lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what 'detailed environment information' entails beyond variables, how results are structured, or potential limitations. For a tool that might return complex data, this leaves significant gaps.
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 schema description coverage is 100%, so the input schema fully documents both parameters. The description adds no additional meaning beyond implying that 'environment variables' are part of the details, which aligns with the schema's 'includeVariables' parameter. This 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 clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed environment information including variables'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_endpoint_details' or 'get_flow_details' beyond the resource type, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after creating an environment), or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific flow
| Name | Required | Description | Default |
|---|---|---|---|
| flowId | Yes | ID of the flow | |
| includeSteps | No | Include flow steps in response (default: true) | |
| includeConfig | No | Include flow configuration in response (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error handling, or what the response format includes beyond 'detailed information'. This leaves significant gaps for an agent to understand the tool's behavior fully.
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, efficient sentence that front-loads the core action and resource. There's no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' entails, how to handle errors, or provide usage context, leaving the agent with insufficient guidance for effective tool invocation in a broader workflow.
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 100% description coverage, with clear documentation for all parameters (flowId, includeSteps, includeConfig). The description adds no additional semantic context beyond implying a 'flow' context, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.
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 verb 'Get' and resource 'detailed information about a specific flow', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_environment_details' or 'get_folder_details' beyond specifying 'flow' as the resource type, which is why it doesn't reach a perfect score.
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 no guidance on when to use this tool versus alternatives like 'list_flows' for browsing or 'execute_flow' for running flows. It lacks context about prerequisites, such as needing a flow ID, and doesn't mention any exclusions or specific scenarios for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific folder
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | Folder ID to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's likely safe, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what 'detailed information' entails (e.g., metadata, permissions). This leaves significant gaps for a tool with no annotation support.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse for an AI agent.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., structure, return format), behavioral traits, or usage context. For a read tool with no structured support, this leaves the agent under-informed about critical operational aspects.
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 description coverage is 100%, with the single parameter 'folderId' well-documented in the schema. The description adds no additional parameter semantics beyond implying it targets a 'specific folder', which aligns with the schema but doesn't provide extra value. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb ('Get') and resource ('detailed information about a specific folder'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_flow_details' or 'get_environment_details' beyond the resource name, which prevents a perfect score.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid folder ID), exclusions, or comparisons to siblings like 'list_folders' for broader queries, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get project context including environments and folders. Validates MCP token and returns enriched project data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions token validation and returns enriched data, which adds useful context beyond basic functionality. However, it lacks details on error handling, rate limits, or what 'enriched' entails, leaving gaps in behavioral understanding.
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, efficient sentence that front-loads the core purpose. It avoids unnecessary words, though it could be slightly more structured by separating the token validation aspect into a second sentence for clarity.
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 annotations, no output schema, and 0 parameters, the description is minimally adequate. It covers the purpose and some behavioral aspects but lacks details on output format or error cases, which could be important for a tool that validates tokens and returns data.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by implying token validation as part of the process, which isn't captured in the schema, justifying a score above the baseline of 3.
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 ('Get') and the resource ('project context including environments and folders'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_environment_details' or 'get_folder_details', which might retrieve similar data but for specific resources rather than the broader project context.
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 no guidance on when to use this tool versus alternatives. With many sibling tools like 'get_environment_details' and 'get_folder_details' that might retrieve overlapping or more specific data, there's no indication of whether this tool is for a high-level overview or when other tools are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the MCP server is running properly
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior as a diagnostic check, which is useful, but lacks details like what 'properly' entails (e.g., connectivity, status codes), response format, or error handling. This is a minimal but adequate disclosure for a simple 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 a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple, no-parameter tool and earns its place by clearly stating the action and target.
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 low complexity (0 params, no output schema, no annotations), the description is complete enough for basic use. However, it could benefit from slightly more context on what 'running properly' means or expected outputs, but it's largely adequate for this simple diagnostic function.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here, but it could hint at implicit inputs (e.g., server context). Baseline is 4 for zero params, as it doesn't compensate but doesn't need to.
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 specific action ('Check') and resource ('MCP server') with the explicit purpose of verifying if it's 'running properly'. It distinguishes itself from all sibling tools, which are focused on CRUD operations for endpoints, environments, flows, folders, and project context, making this a unique diagnostic tool.
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 context—when you need to verify server health—but doesn't explicitly state when not to use it or name alternatives. Given that all siblings are unrelated (e.g., create_endpoint, execute_flow), the context is clear, but no exclusions or direct comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all endpoints with optional filtering by folder
| Name | Required | Description | Default |
|---|---|---|---|
| folder_id | No | Optional folder ID to filter endpoints | |
| method | No | Optional HTTP method filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists endpoints with optional filtering, which implies a read-only operation, but doesn't specify whether it's safe, whether it requires authentication, what the output format is (e.g., pagination, error handling), or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose ('List all endpoints') and adds essential context ('with optional filtering by folder'). There is no wasted verbiage, and it directly communicates the tool's function without redundancy or unnecessary details.
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 low complexity (2 optional parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and hints at filtering, but lacks details on behavioral aspects like output format, error conditions, or authentication needs. Without annotations or an output schema, the description should do more to compensate, but it falls short of being fully complete for safe and effective 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?
The input schema has 100% description coverage, with clear documentation for both parameters ('folder_id' and 'method'), including an enum for 'method'. The description adds minimal value beyond the schema by mentioning 'optional filtering by folder', which aligns with the 'folder_id' parameter but doesn't provide additional context like format examples or usage tips. Given the high schema coverage, a 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 the verb ('List') and resource ('endpoints'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_endpoint_details' by focusing on listing multiple items rather than retrieving details of a single endpoint. However, it doesn't explicitly differentiate from other list tools like 'list_environments' or 'list_flows' beyond the resource type.
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 by mentioning 'optional filtering by folder', suggesting it can be used to narrow down results. However, it provides no explicit guidance on when to use this tool versus alternatives like 'list_folders' or 'get_endpoint_details', nor does it mention prerequisites or exclusions. The usage context is somewhat implied but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all environments for current project
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID (optional, will use current project if not provided) | |
| activeOnly | No | Show only active environments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't mention whether it's paginated, what format the results come in, permission requirements, rate limits, or error conditions. 'List all environments' implies a read-only operation but lacks crucial behavioral details.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and gets straight to the point.
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 list operation with no annotations and no output schema, the description is insufficient. It doesn't explain what an 'environment' is in this context, what information is returned, or how results are structured. Given the lack of structured metadata, the description should provide more context about the operation's behavior and 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 100% description coverage, so parameters are well-documented in the schema. The description adds no additional parameter information beyond what's in the schema, which is acceptable given the comprehensive schema coverage. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 verb ('List') and resource ('all environments for current project'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'list_endpoints' or 'list_flows', but the resource specificity is adequate for basic understanding.
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 no guidance on when to use this tool versus alternatives like 'get_environment_details' or 'list_endpoints'. It mentions 'current project' but doesn't explain how that's determined or what happens if no project is set, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List flows in the current project
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | No | Filter by folder ID | |
| activeOnly | No | Show only active flows | |
| limit | No | Maximum number of flows to return | |
| offset | No | Number of flows to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It implies a read-only operation by using 'List', but doesn't specify whether this requires authentication, how results are ordered, if pagination is handled via 'limit' and 'offset', or what happens on errors. For a tool with 4 parameters and no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It uses minimal space to convey the essential action and scope, making it easy to parse quickly. Every part of the sentence earns its place by specifying both the verb and the resource context.
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 of a listing tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'flow' is in this context, how results are structured, or behavioral aspects like default sorting or error handling. While the schema covers parameters well, the overall context for effective tool use by an AI agent remains underspecified.
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 100% description coverage, providing clear documentation for all 4 parameters ('folderId', 'activeOnly', 'limit', 'offset'). The description adds no additional parameter semantics beyond implying filtering by 'current project', which isn't a parameter. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('List') and resource ('flows in the current project'), making the purpose immediately understandable. It distinguishes from siblings like 'get_flow_details' (which retrieves a specific flow) and 'list_folders' (which lists a different resource). However, it doesn't specify what constitutes a 'flow' or differentiate from 'list_endpoints' or 'list_environments' beyond the resource name.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'list_flows' over 'get_flow_details' for specific flows, or how it relates to 'list_folders' for organizational context. There's no indication of prerequisites, such as needing an active project, or exclusions for when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all folders for current project with optional tree view
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | No | Project ID (optional, will use current project if not provided) | |
| parentId | No | Parent folder ID to filter subfolders | |
| includeTree | No | Include hierarchical tree view | |
| activeOnly | No | Show only active folders |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all folders') but lacks details on permissions required, pagination behavior, rate limits, error conditions, or what 'tree view' entails structurally. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that front-loads the core purpose ('List all folders for current project') and adds a key optional feature ('with optional tree view'). There is no wasted wording, and it's appropriately sized for the tool's complexity.
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 annotations, no output schema, and a read operation with four parameters, the description is incomplete. It doesn't explain the return format (e.g., list structure, tree view output), error handling, or behavioral constraints like permissions. For a tool with moderate complexity and no structured support, more context is needed to guide effective 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?
Schema description coverage is 100%, with all parameters well-documented in the input schema (e.g., projectId as optional with fallback, includeTree for hierarchical view). The description adds minimal value beyond the schema by mentioning 'optional tree view,' which aligns with the includeTree parameter. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('List') and resource ('folders'), specifying scope ('for current project') and an optional feature ('with optional tree view'). It distinguishes from siblings like get_folder_details (which retrieves details of a specific folder) but doesn't explicitly differentiate from other list_* tools (e.g., list_endpoints, list_flows).
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to use list_folders versus get_folder_details (for specific folder details) or create_folder (for creating new folders), nor does it specify prerequisites or exclusions. The only contextual hint is 'for current project,' which is covered in the parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set an environment as the default for the project
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment ID to set as default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a mutation action ('Set'), implying changes to project settings, but doesn't disclose behavioral traits like required permissions, whether the change is reversible, or potential side effects. This leaves significant gaps for a tool that modifies defaults.
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, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded and appropriately sized for the tool's complexity, with zero 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 mutation nature and lack of annotations or output schema, the description is incomplete. It doesn't address what happens after setting the default (e.g., confirmation, error handling, or impact on other operations), leaving the agent with insufficient context for reliable 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?
The input schema has 100% description coverage, with the single parameter 'environmentId' documented as 'Environment ID to set as default'. The description adds no additional meaning beyond this, so it meets the baseline for high schema coverage without compensating further.
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 ('Set') and the target ('an environment as the default for the project'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'update_environment_variables' or 'create_environment', which could be ambiguous in context.
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 no guidance on when to use this tool versus alternatives, such as whether it should be used after creating an environment or instead of other update operations. Without any context on prerequisites or exclusions, usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test a single endpoint with optional environment variables
| Name | Required | Description | Default |
|---|---|---|---|
| endpointId | Yes | Endpoint ID to test | |
| environmentId | No | Environment ID for variables (optional) | |
| variables | No | Variables for interpolation (JSON string, object, or comma-separated key=value pairs) | |
| timeout | No | Request timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'tests' an endpoint but doesn't explain what this entails—whether it makes HTTP requests, validates configurations, returns results, or has side effects. This leaves critical behavioral traits undefined for a tool that likely performs network operations.
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, efficient sentence that front-loads the core purpose ('Test a single endpoint') and mentions the key optional feature ('with optional environment variables'). There is no wasted verbiage, making it highly concise and 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?
Given the complexity of testing endpoints (likely involving network requests and variable interpolation), no annotations, and no output schema, the description is inadequate. It fails to explain what the tool returns, how errors are handled, or prerequisites, leaving significant gaps for effective agent 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by noting that environment variables are 'optional', which is already implied by the schema's optional fields. It doesn't provide additional context like how variables are interpolated or typical timeout values.
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 ('Test') and resource ('a single endpoint'), which is specific and distinguishes it from siblings like 'execute_flow' or 'health_check'. However, it doesn't explicitly differentiate from similar tools like 'get_endpoint_details', leaving some ambiguity about what 'testing' entails versus inspection.
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 no guidance on when to use this tool versus alternatives. It mentions optional environment variables but doesn't specify scenarios where testing is appropriate (e.g., validation, debugging) or when to choose other tools like 'execute_flow' or 'health_check' for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update existing endpoint configuration
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Endpoint ID to update (required) | |
| name | No | Updated endpoint name (optional) | |
| method | No | Updated HTTP method (optional) | |
| url | No | Updated endpoint URL (optional) | |
| description | No | Updated endpoint description (optional) | |
| headers | No | Updated request headers as key-value pairs | |
| body | No | Updated request body (JSON string) | |
| purpose | No | Updated business purpose (optional) | |
| request_params | No | Updated parameter documentation: {param_name: "description"} | |
| response_schema | No | Updated response field documentation: {field_name: "description"} | |
| header_docs | No | Updated header documentation: {header_name: "description"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update existing endpoint configuration' implies a mutation operation but reveals nothing about permissions required, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. For a complex configuration tool with 11 parameters, this is a significant transparency 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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('update') and target ('existing endpoint configuration'), making it immediately scannable. Every word earns its place in this minimal but complete statement of purpose.
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 complex mutation tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like side effects, error handling, or response format. While the schema covers parameter details, the description fails to provide the contextual understanding needed for safe and effective tool invocation.
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 100% description coverage, providing detailed documentation for all 11 parameters including required/optional status, data types, and enum values. The description adds no parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb 'update' and resource 'existing endpoint configuration', making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'update_environment_variables' or 'update_folder', which also perform updates on different resources. The description is specific about what's being updated but lacks sibling distinction.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing endpoint), when not to use it, or how it differs from related tools like 'create_endpoint' or 'test_endpoint'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update environment variables (add/update/remove variables)
| Name | Required | Description | Default |
|---|---|---|---|
| environmentId | Yes | Environment ID to update variables for | |
| variables | Yes | Variables object with key-value pairs (JSON string, object, or comma-separated key=value pairs) | |
| operation | No | Operation type: "merge" (default) to combine with existing, "replace" to overwrite all | merge |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the tool can 'add/update/remove variables' but doesn't disclose critical traits like required permissions, whether changes are reversible, potential side effects on dependent flows, or error handling. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core action ('update environment variables') with clarifying scope ('add/update/remove variables'). There's no wasted text, though it could be slightly more structured by separating operations or adding brief context. It earns its place but isn't perfectly optimized.
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 a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on return values, error cases, permissions needed, or how variables interact with existing configurations. While schema coverage is high, the behavioral and contextual gaps make it inadequate for safe and effective use by an AI agent.
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 description coverage is 100%, so the schema fully documents all three parameters (environmentId, variables, operation). The description adds no additional meaning beyond what's in the schema—it doesn't explain variable format examples, operation implications, or environmentId sourcing. Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 verb ('update') and resource ('environment variables'), specifying it handles add/update/remove operations. It distinguishes from siblings like 'create_environment' or 'get_environment_details' by focusing on variable management rather than environment lifecycle or read-only access. However, it doesn't explicitly differentiate from 'set_default_environment' which might involve variable settings.
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 is provided. The description doesn't mention prerequisites (e.g., environment must exist), when to choose 'merge' vs 'replace' operations, or how it differs from sibling tools like 'update_endpoint' or 'set_default_environment'. Usage is implied through the action but lacks contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update folder name, description, or parent
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | Folder ID to update | |
| name | No | New folder name | |
| description | No | New folder description | |
| parentId | No | New parent folder ID (null to move to root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool updates folder attributes, implying mutation, but doesn't disclose behavioral traits like permission requirements, whether updates are reversible, rate limits, or what happens to child items. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise—a single sentence with no wasted words. It front-loads the core action ('update folder') and efficiently lists the modifiable attributes. Every element earns its place, making it easy for an agent to parse quickly.
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 complexity (mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error conditions, response format, or side effects. For a folder update operation, more context is needed to guide safe and effective usage.
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 description coverage is 100%, so the schema already documents all four parameters (folderId, name, description, parentId) with clear descriptions. The description adds minimal value by listing updatable fields but doesn't provide additional semantics beyond what's in the schema, such as format constraints or examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb 'update' and resource 'folder', specifying what fields can be modified (name, description, parent). It distinguishes from sibling tools like 'create_folder' and 'delete_folder' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update tools like 'update_endpoint' or 'update_environment_variables' beyond the resource type.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing folder ID), exclusions (e.g., what cannot be updated), or comparisons with similar tools like 'update_endpoint'. The agent must infer usage from the tool name and parameters alone.
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.0create_endpointcreate_environmentcreate_flowcreate_folderdelete_environmentdelete_flowdelete_folderexecute_flowget_endpoint_detailsget_environment_detailsget_flow_detailsget_folder_detailsget_project_contexthealth_checklist_endpointslist_environmentslist_flowslist_foldersset_default_environmenttest_endpointupdate_endpointupdate_environment_variablesupdate_folderEvery 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Turn any task into the right API calls: discover, evaluate, and integrate public APIs.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martin-1103/mcp2'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
