Manage server-side Google Tag Manager containers, Conversions API gateways, custom domains, and power-ups via Stape.io.
Click on "Deploy 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., "@WAS Stape MCP List all my sGTM containers"
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.
Production-quality shareable Model Context Protocol (MCP) server for Stape.io — standard stdio transport, zero-server setup, interactive credential CLI, cross-platform support.
Exposes 10 tools to AI assistants (Claude, Cursor, Antigravity, VS Code, Zed) for automating server-side Google Tag Manager (sGTM) containers, Conversions API (CAPI) Gateways, custom domains, and power-ups.
Node.js 18+
A Stape.io account (https://stape.io)
Stape Account API Key (Account settings -> API Keys)
Related MCP server: Google Webmaster MCP
Log into your Stape.io account.
Click your account name at the top right -> Account settings.
Go to API Keys -> click Create API key.
Copy your key securely.
Run the interactive setup command:
npx -y github:was-member-keramat/was-stape-mcp authCredentials are validated against Stape.io and stored locally at ~/.was-stape-mcp/config.json with secure file permissions (0600).
Add the following to your AI client's MCP configuration (mcpServers section):
claude_desktop_config.json or mcp_config.json){
"mcpServers": {
"WAS Stape MCP": {
"command": "npx",
"args": ["-y", "github:was-member-keramat/was-stape-mcp"]
}
}
}Here are example prompts you can use with your AI coding assistant:
Discovery: "List all my sGTM containers on Stape."
Inspection: "Show details for container ID cnt_12345."
Domains: "What custom domains are configured for my container?"
Provisioning: "Create a new sGTM container named my-ecommerce-sgtm in the us region."
Logs & Traffic: "Show me request statistics and bandwidth usage for the past 7 days."
Power-ups: "Which power-ups are currently enabled for container cnt_12345?"
Raw API: "Run a GET call to /v1/container using stape_api."
Category | Tool Name | Description |
Account |
| Get account details, subscription plan, and usage stats |
Containers |
| List sGTM and CAPI Gateway containers |
Containers |
| Get details for a specific container by ID |
Containers |
| Create a new sGTM or CAPI container |
Containers |
| Delete or cancel a container by ID |
Domains |
| List custom domains configured for a container |
Domains |
| Add a custom domain to an sGTM container |
Analytics & Logs |
| Get request statistics and traffic bandwidth |
Power-ups |
| List power-ups enabled on a container |
Universal |
| Raw API caller escape hatch ( |
Command | Usage |
| Start the MCP server (used by AI tools via stdio) |
| Connect / re-connect Stape API Key |
| Display saved config location and timestamp |
| Delete saved local credentials |
| Show CLI help text |
You can override local config with environment variables (STAPE_API_KEY, STAPE_BASE_URL). This enables configuring multiple Stape accounts in your AI client:
{
"mcpServers": {
"Stape Main": {
"command": "npx",
"args": ["-y", "github:was-member-keramat/was-stape-mcp"],
"env": {
"STAPE_API_KEY": "key_main_account_token"
}
},
"Stape Client B": {
"command": "npx",
"args": ["-y", "github:was-member-keramat/was-stape-mcp"],
"env": {
"STAPE_API_KEY": "key_client_b_token"
}
}
}
}If PowerShell blocks script execution:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSignednpx Cache IssuesIf updates aren't pulled automatically on Windows:
Remove-Item -Recurse -Force "$env:LOCALAPPDATA\npm-cache" -ErrorAction SilentlyContinue
npm cache clean --forceEnsure you created an Account API Key (Account settings -> API Keys) and not a restricted single-container key unless you are targeting specific container scope.
MIT License. Free to share, remix, redistribute. Author: was-member-keramat.
Add a new custom domain to an sGTM container.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Custom domain hostname (e.g., sgtm.example.com) | |
| containerId | Yes | Stape Container ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. Only states 'Add', but does not mention idempotency, overwrite behavior, DNS verification requirements, or error handling for duplicates.
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?
Single sentence, no unnecessary words, directly states the 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?
No output schema, no return value description, no side effects. For a mutation tool, more context about results or postconditions is needed.
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 coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond the schema, so 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?
Description clearly states the tool adds a new custom domain to an sGTM container, using specific verb-resource pairing. It easily distinguishes from siblings like stape_list_domains or stape_create_container.
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 guidance on when to use this tool versus alternatives (e.g., check existing domains first). No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal escape-hatch tool to invoke any Stape API endpoint directly.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Request payload object for POST/PUT/PATCH | |
| path | Yes | API endpoint path (e.g. /v1/container or /v1/user) | |
| method | No | HTTP method: GET, POST, PUT, DELETE, PATCH | GET |
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 only says 'invoke any endpoint' without disclosing important behaviors like authentication requirements, rate limiting, error handling, or whether it might bypass tool-constructed logic. This is a significant gap for a raw HTTP 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 concise sentence. However, it is so minimal that it may be under-specified for a tool of this nature; still, it is efficient and front-loaded. The conciseness earns a 4.
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 catch-all for raw API calls with no output schema and multiple sibling tools covering specific use cases, the description lacks important context: it does not mention that users need prior knowledge of the Stape API, that it bypasses built-in tool logic, or any potential risks. It is incomplete for safely using this tool.
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 each parameter having a description. The description adds no additional meaning beyond the schema. Baseline 3 applies as the schema already documents parameters adequately.
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 it's a 'universal escape-hatch tool to invoke any Stape API endpoint directly,' which distinctly distinguishes it from sibling tools that target specific endpoints. The verb 'invoke' and resource 'Stape API endpoint' are specific and unambiguous.
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 it is for cases not covered by sibling tools via 'escape-hatch', but lacks explicit guidance on when to use it versus alternatives, nor does it state when not to use it. There is no mention of prerequisites or invocation context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new server-side GTM (sGTM) or CAPI Gateway container.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the container | |
| plan | No | Subscription plan (e.g., "free", "pro", "business") | free |
| type | No | Container type: "sgtm" (default) or "capi" | sgtm |
| region | No | Hosting region (e.g., "us", "eu", "global") | us |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states creation without clarifying side effects, idempotency, permission requirements, or response details. The term 'create' implies mutation, but safety or error conditions are unmentioned.
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 conveys the core purpose. It is front-loaded and compact, though slightly more detail on return value or defaults would not hurt.
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 output schema and 4 parameters, the description is incomplete. It does not mention the response format (e.g., container ID), defaults beyond what's in the schema, or any prerequisites. A creation tool benefits from explaining what is returned.
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 no semantic value beyond the schema; it does not elaborate on parameter meanings or constraints.
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 container, specifying two types (server-side GTM or CAPI Gateway), which distinguishes it from sibling tools that read, list, delete, or update containers.
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 guidance on when to use this tool versus alternatives (e.g., stape_update_container) or when not to use it. The context signals show sibling tools for other actions, but the description does not differentiate usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete or cancel a Stape container by container ID.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Container ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states the action but not consequences (e.g., permanent deletion, required permissions, reversibility). Minimal disclosure for a destructive 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?
One sentence, ten words, no redundant information. Front-loaded and efficient, every word earns its place.
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?
Adequate for a simple delete tool with one parameter. Lacks details on return format, error handling, or authentication requirements. Could be improved with brief notes on expected response or prerequisites.
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 coverage is 100%; the description adds no additional meaning beyond the schema's 'Container ID to delete'. Baseline score applies as no extra semantic value provided.
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/cancel) and the resource (Stape container) with method (by container ID). Minor ambiguity from 'or cancel' but overall clear. Distinguishes from sibling tools like stape_create_container.
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 or prerequisites. Does not mention scenarios where delete vs cancel applies, nor what conditions must be met before deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Stape account details, subscription plan, and usage statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a read-only behavior (get details, plan, stats) with no side effects. However, it lacks details on authentication requirements, rate limits, or exactly what fields are returned. Basic transparency but not rich.
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 sentence with no unnecessary words. It is front-loaded with the verb and clearly states the three main outputs. Efficient and structured well.
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 has no parameters, no output schema, and performs a simple retrieval, the description adequately covers what the tool does. No additional context is needed for an AI agent to invoke it correctly.
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?
There are zero parameters, so the schema coverage is 100%. The description adds no parameter information, but per rubric, baseline for 0 params is 4. No additional semantic value needed.
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 retrieves Stape account details, subscription plan, and usage statistics. It uses a specific verb ('Get') and resource ('account details, subscription plan, usage statistics'), and distinguishes from sibling tools that focus on containers, domains, and powerups.
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 for retrieving account-level information, but does not explicitly state when to use this tool versus alternatives (e.g., container-specific tools). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a specific container by container ID or API key.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Stape Container ID or Identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'get' suggesting read-only but doesn't detail authentication needs, side effects, or what 'detailed information' encompasses. Carries full burden but offers minimal disclosure.
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?
Single sentence, 13 words, directly states purpose and key parameter usage. No redundancy or unnecessary detail.
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?
Adequate for a simple get operation with one parameter, but lacks description of return format or what 'detailed information' includes. No output schema to compensate, leaving some ambiguity.
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 describes containerId as 'Stape Container ID or Identifier', but description adds that it can be an API key, providing extra meaning beyond schema. Schema coverage is 100% but description adds useful context.
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?
Clearly states the verb 'get', the resource 'detailed information for a specific container', and the parameter (by container ID or API key). Distinguishes from siblings like stape_list_containers (which lists all containers).
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?
Implied usage: use this tool when you have a container ID or API key to retrieve details. No explicit when-not-to-use or comparison to alternatives (e.g., stape_list_containers for bulk listing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get request logs, bandwidth usage, and traffic stats for a container.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of past days to retrieve stats for | |
| containerId | Yes | Stape Container ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully convey behavioral traits. It does not state whether the tool is read-only, safe, or destructive, nor does it mention rate limits, data retention limits, or output format. This is a significant gap for a data-fetching 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 containing the core purpose. No wasted words.
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 output schema and no annotations, the description should at least hint at the response structure or any limits. It does not. The tool's complexity is low, but missing output details makes it hard for an agent to rely on it.
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 coverage is 100%, and both parameters have clear descriptions (e.g., 'Number of past days to retrieve stats for'). The description adds no additional semantic value beyond what the schema already provides, earning a baseline 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?
Description clearly states the tool retrieves logs, bandwidth, and traffic stats for a container. While specific, it does not differentiate from sibling tools like stape_get_container (which likely retrieves container settings), so a 4 is appropriate.
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 guidance on when to use this tool versus alternatives (e.g., stape_get_container). No exclusions or context about prerequisites or typical use cases provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sGTM and CAPI Gateway containers in your Stape account.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination | |
| type | No | Filter by container type: "sgtm" or "capi" | |
| limit | No | Number of containers per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks any behavioral details beyond the action itself. Does not disclose rate limits, safety, or response characteristics for a list 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?
Single sentence with no redundant information. Efficient, but could be better structured to include additional context without sacrificing 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?
With no output schema, the description should clarify return format or pagination behavior. It does not, making it incomplete for a tool with 3 parameters and no output schema.
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 baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters page, type, and limit.
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 it lists all sGTM and CAPI Gateway containers, with specific verb 'List' and resource 'containers'. This distinguishes it from siblings like 'get_container' and 'delete_container'.
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. Usage is implied as a generic list operation, but no when-not-to or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List custom domains configured for a specific container.
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Stape Container ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'list...' without mentioning read-only nature, pagination, or what data is returned. This is insufficient for a tool with no annotations.
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 sentence, concise and front-loaded. It is efficient but could include more useful details without becoming verbose.
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 output schema and a simple listing operation, the description is adequate but does not explain return values or pagination. It could be more complete by describing the response format.
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% for the single parameter 'containerId' with a brief description. The tool description adds no extra meaning beyond the schema. 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 'List custom domains configured for a specific container,' which includes a specific verb (list), resource (custom domains), and context (for a specific container). This distinguishes it from sibling tools like stape_add_domain or stape_list_containers.
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 explicit guidance on when to use this tool versus alternatives. While it is implied to be for listing domains, there is no mention of when-not or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List power-ups enabled or available for a container (e.g. Cookie Keeper, Anonymizer).
| Name | Required | Description | Default |
|---|---|---|---|
| containerId | Yes | Stape Container ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It correctly implies a read-only operation ('list'), but does not disclose if any permissions are required, pagination behavior, or whether 'enabled' vs 'available' affects the response format.
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?
Single sentence with no fluff. Essential elements (action, resource, examples) are 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 simple list tool with one parameter and no output schema, the description covers the primary purpose and scope. It could mention the return type (array) or that it lists both enabled and available power-ups, but is largely adequate.
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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for 'containerId'—it only provides examples of power-ups, not parameter specifics.
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 the resource 'power-ups for a container', with concrete examples (Cookie Keeper, Anonymizer) that distinguish it from sibling list tools like stape_list_containers or stape_list_domains.
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 guidance is given on when to use this tool, when not to, or how it differs from siblings. The agent must infer context from the name and examples 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.
v1.0.0stape_add_domainstape_apistape_create_containerstape_delete_containerstape_get_accountstape_get_containerstape_get_container_logsstape_list_containersstape_list_domainsstape_list_powerupsScored across 10 tools
Most tools have distinct purposes (account, containers, domains, logs, powerups). However, the generic stape_api tool blurs boundaries, potentially causing misselection when a specific tool exists.
All tools follow the stape_<verb>_<noun> pattern except for stape_api, which breaks the convention. The rest are consistent and predictable.
10 tools cover the main aspects of Stape account and container management without being overwhelming. Each tool serves a clear purpose.
The set covers basic CRUD for containers and domain listing but lacks update/delete for domains, manage powerups, or update containers. The generic stape_api can fill gaps but the official tool surface has notable omissions.
Let AI manage your Google Tag Manager containers — tags, triggers, variables, and more.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Give your AI agents the tools to build, manage, and run automation workflows.
60+ Meta Ads tools for AI agents: audits, campaign management, audiences and CAPI tracking.
