Provides tools for managing SAP Business Technology Platform (BTP) infrastructure, including provisioning subaccounts, assigning role collections, listing users, regions, directories, entitlements, service instances, environment instances, and subscriptions, all via natural language commands.
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., "@SAP BTP MCP Server Check if my BTP session is still active using ping."
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.
A professional Model Context Protocol (MCP) server providing a robust natural language interface for SAP Business Technology Platform (BTP).
Manage your cloud infrastructure, security, and entitlements conversationally through AI agents (Claude, Gemini, etc.) using your local btp CLI session.
Conversational Infrastructure: Provision subaccounts and assign roles using simple language.
Fail-Safe Design: Built-in timeouts, non-interactive execution, and resilient output parsing.
Secure by Design:
Runs entirely locally; no external credentials or tokens are stored.
Leverages your existing BTP CLI authentication (SSO/JWT).
Proactive Error Handling: Provides clear instructions when authentication expires or inputs are invalid.
Automatic Discovery: Intelligently locates the btp binary across Windows, macOS, and Linux.
Related MCP server: SAP Business Data Cloud MCP Server
This server is designed for mission-critical AI automation:
Intelligent Timeouts: Prevents "hanging" on long SAP BTP API operations with 60s/120s thresholds.
Deep JSON Recovery: Automatically extracts valid data even if the CLI returns mixed output or warnings.
Input Validation: Pre-validates technical IDs (GUIDs) and Emails to prevent unnecessary CLI failures.
Non-Interactivity: Guaranteed non-blocking execution using CI-mode environments and null-input piping.
SAP BTP CLI: Installed and in your system PATH.
Active Session: You must be logged in. Verify with: btp list accounts/global-account
Python 3.10+: Ensure a modern Python environment.
uv (Recommended)uv tool install --from . btp-mcp-serverpippip install .Add the following to your MCP client config (e.g., claude_desktop_config.json):
uv (Fastest){
"mcpServers": {
"btp": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/BTP MCP Server",
"run",
"btp-mcp-server"
]
}
}
}{
"mcpServers": {
"btp": {
"command": "python3",
"args": ["-m", "btp_mcp_server"],
"env": { "PYTHONPATH": "/absolute/path/to/BTP MCP Server/src" }
}
}
}Category | Tool | Description |
System |
| Checks CLI health and login status. |
| Run any generic BTP CLI command. | |
Accounts |
| List all accessible subaccounts. |
| Provision a new subaccount with validation. | |
| Permanent deletion of a subaccount. | |
| List available technical regions (us10, eu10, etc). | |
| List directories in the global account. | |
Security |
| List global account users. |
| Grant roles (e.g., Admin) to a user. | |
Resources |
| Check available service plans/quotas. |
| Remove an assigned entitlement from a subaccount. | |
| List active services in a subaccount. | |
| List environments like Cloud Foundry or Kyma. | |
| List SaaS application subscriptions. |
"Check if my BTP session is still active using ping."
"Show me all subaccounts in region eu10."
"Assign the 'Subaccount Admin' role to colleague@example.com."
"Create a development subaccount named 'Internal-Alpha' in us10."
Authentication Error (❌ AUTHENTICATION ERROR) If you see this, your BTP CLI session has expired.
Clear the error in the AI chat.
Run btp login in your terminal.
Refresh the AI session.
CLI Not Found (⚠️ BTP CLI not found)
Ensure btp is in your PATH. On macOS/Linux, try ln -s /path/to/btp /usr/local/bin/btp.
The server follows a layered architecture to ensure separation of concerns and maximum stability:
Tool Layer (server.py): Uses FastMCP to register Python functions as MCP tools. Implements strict Pydantic validation and maps technical exceptions to human-readable markdown tips.
Service Layer (btp_cli.py): Orchestrates command execution. Manages the state of the CLI path, handles binary auto-discovery, and implements the "Deep JSON Recovery" algorithm.
Execution Layer (subprocess): Interacts directly with the OS. Uses hardened environments (CI=true) and standard error redirection to maintain security and non-interactivity.
Utility Layer (utils.py): Centralizes cross-cutting concerns like logging to stderr and custom domain-specific exceptions.
Request Intake: The AI client (e.g., Antigravity) sends a JSON-RPC request to a registered tool (e.g., btp_list_subaccounts).
Pre-Validation: The Tool Layer hydrates parameters and performs regex-based technical validation (IDs/GUIDs).
Execution: The Service Layer constructs a safe CLI command, injecting --format json as a global prefix.
Retry & Recovery:
If the command times out, it retries with exponential backoff.
If the output contains warnings + JSON, the "Deep Recovery" engine extracts the valid payload.
Error Mapping: If the CLI returns "Session Expired", the decorator catches it and provides the user with an exact btp login command for their specific binary path.
Structured Response: The final JSON payload is beautified and returned to the AI as a markdown-formatted string.
MIT License.
Kallol Chakraborty - @kallolchakraborty
Provision a new subaccount in the current global account. This operation is asynchronous on the platform side but the tool waits for the initial response.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is asynchronous on the platform side but the tool waits for an initial response. However, it omits details on permissions, failure behavior, and idempotency.
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 two concise sentences. The first states the action, the second clarifies the asynchronous behavior. No unnecessary words 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?
Given the complexity of provisioning a subaccount, the description is severely incomplete. It lacks return value specification, parameter details, prerequisites, and any error handling context. The agent cannot reliably use this tool based on the description alone.
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% description coverage and the description provides no information about what the 'args' and 'kwargs' parameters should contain. The agent receives no guidance on required or optional fields, making correct invocation nearly impossible.
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 'Provision a new subaccount in the current global account' clearly identifies the action (provision) and resource (subaccount). It distinguishes from sibling tools like btp_delete_subaccount and btp_list_subaccounts.
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 does not explicitly state when to use this tool versus alternatives. Usage is implied from the tool name and sibling tools (bp_list_subaccounts, btp_delete_subaccount), but no guidance on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a subaccount permanently. WARNING: This will delete all resources within the subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It warns that the action is permanent and deletes all resources, which is a critical behavioral trait. However, it lacks detail on idempotency, authorization requirements, or whether confirmation is needed. The warning adds value but is not comprehensive.
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 very concise with only two sentences and no fluff. The warning is appropriately front-loaded. However, it could briefly mention parameter usage without becoming verbose, which would improve informativeness while maintaining 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 simplicity of the tool (delete operation) and the lack of output schema, the description should at least explain how to identify which subaccount to delete via parameters. It does not, making it incomplete for agent use. The warning alone is insufficient for correct 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 parameters 'args' and 'kwargs' are completely undocumented in the description. With 0% schema coverage, the description must explain how to specify the subaccount, but it fails to do so. The agent has no clue what to input.
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 'Delete a subaccount permanently' with a specific verb and resource. It distinguishes the tool from its siblings that are for listing, getting, or creating subaccounts, making it unequivocally the delete operation.
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. The warning implies it should be used with caution and only when permanent deletion is intended, but does not provide context such as prerequisites or 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.
Generic execution engine for ANY SAP BTP CLI command. Use this if a dedicated tool is not available for a specific resource type.
Safety: This tool automatically handles JSON formatting and error detection.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions automatic JSON formatting and error detection, but does not disclose what happens on failure, return format, security/authentication requirements, or any rate limits. With no annotations, more behavioral context would be helpful.
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?
Three concise sentences, front-loaded with purpose, guidance, and a safety note. No fluff, but could be slightly more structured (e.g., bullet points) for easier scanning.
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?
Lacks explanation of return value or output format. Given the tool is a generic fallback, more details on expected output, error handling, and edge cases would be needed for complete understanding.
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?
Neither the input schema nor the description explain what 'args' and 'kwargs' mean. Both are required strings, but the agent has no guidance on how to structure them. The description does not compensate for the 0% schema description 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?
Clearly states it is a generic execution engine for ANY SAP BTP CLI command. Explicitly distinguishes from sibling tools by saying to use it only when a dedicated tool is not available.
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?
Provides explicit guidance: 'Use this if a dedicated tool is not available for a specific resource type.' This tells the agent when to invoke this tool vs its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full configuration (URL, authentication, proxy) of a specific destination.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It states the tool retrieves configuration details (URL, auth, proxy), implying a read operation, but does not clarify if it is read-only, any authentication requirements, potential side effects, or error conditions. The description is insufficient 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 only one sentence, which is concise, but it omits critical information about parameters and usage. While brevity is appreciated, the lack of detail results in under-specification, making it less helpful than it could be.
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 parameter descriptions, absence of an output schema, and minimal usage guidance, the description is incomplete. It does not explain how to identify the specific destination or what the returned configuration looks like, leaving significant gaps for 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?
The schema has 0% description coverage and the tool's description does not mention the two required parameters (args and kwargs) at all. It fails to explain how to specify the destination or how these parameters are used, leaving the agent without essential information to invoke the tool correctly.
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', the resource 'full configuration of a specific destination', and specifies the included elements (URL, authentication, proxy). It distinguishes from the sibling tool 'btp_list_destinations' which lists destinations rather than retrieving a single destination's configuration.
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 provided on when to use this tool versus alternatives like btp_list_destinations. There is no mention of prerequisites, when not to use it, or how to specify the destination. The description is minimal and lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata about the current global account context, including its name and ID.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says 'Retrieve metadata' implying a read operation. It does not disclose permissions needed, whether the operation is destructive, or any rate limits. Minimum 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 a single clear sentence with no unnecessary words. It efficiently conveys the core 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?
Given the lack of parameter explanations and no output schema, the description is incomplete. It fails to clarify what the tool returns or how to use the required parameters, leaving significant gaps for a retrieval 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?
The schema has two required parameters (args, kwargs) with 0% description coverage, and the tool description does not explain their purpose. This omission makes it difficult for an agent to invoke the tool correctly, as the parameters are vague and likely require specific input.
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 metadata about the current global account context, specifically including its name and ID. It distinguishes from sibling tools like btp_get_subaccount which targets subaccounts.
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 guidelines on when to use this tool versus alternatives are provided. The description does not mention any prerequisites, when not to use, or compare with sibling tools like btp_list_subaccounts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive details for a specific subaccount, including region, subdomain, and parent IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states what the tool does, but does not disclose behavioral traits like read-only nature, authorization requirements, or side effects. Full burden on description, which fails to add 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?
Single sentence that is front-loaded with purpose. Efficient but could benefit from additional structure or bullet points 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?
No output schema, no annotations, poor parameter description. Description does not explain return format, usage constraints, or other essential context for a tool with minimal structured metadata.
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 has args and kwargs with 0% coverage. Description does not explain these parameters or their expected formats. No added value beyond schema.
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 comprehensive details for a specific subaccount, listing region, subdomain, and parent IDs. It distinguishes from siblings like btp_list_subaccounts (list all) and btp_create_subaccount (create).
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 vs alternatives. Does not mention prerequisites, when not to use, or any context-specific advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all destinations (HTTP/RFC connections) in a subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
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. It only states the action ('list') without mentioning read-only nature, required permissions, pagination, rate limits, or any side effects. The description adds minimal behavioral context beyond the name.
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 concise (9 words) and front-loaded with the core action. However, it is too brief to be fully effective, sacrificing completeness for brevity. It fits the structure well but could benefit from a touch more 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?
Given the lack of output schema and the presence of generic parameters, the description should provide more context on how to use the tool (e.g., how to specify the subaccount). It does not address return values, error conditions, or prerequisites, leaving significant gaps for an 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?
The input schema has two parameters (args, kwargs) with 0% description coverage. The tool description does not explain what these parameters mean, how to use them, or provide any examples. The agent has no semantic information to populate these parameters correctly, making the tool effectively unusable without external knowledge.
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 lists all destinations (HTTP/RFC connections) in a subaccount. This is a specific verb+resource that distinguishes it from sibling tools like btp_list_service_instances (which lists service instances) and btp_get_destination (which gets a single destination).
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 (e.g., btp_get_destination for a specific destination). It does not specify prerequisites or context for invocation, leaving the agent to infer usage solely from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all environment instances (e.g., Cloud Foundry, Kyma) in a subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives no behavioral details such as authentication requirements, pagination, error handling, or side effects. The agent has no information beyond the basic action.
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 redundancy. However, its brevity contributes to incompleteness; the structure itself is clean.
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 annotations, no output schema, and zero parameter documentation, the description fails to provide essential context about return values, required scoping (e.g., subaccount ID specification), or behavior, making it inadequate for proper tool selection and 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 two generic string parameters (args, kwargs) with zero description coverage. The description adds no clarification on their meaning, format, or usage, leaving the agent unable to construct valid input.
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 identifies the action ('List'), the resource ('environment instances'), and the scope ('in a subaccount'), with helpful examples (Cloud Foundry, Kyma). This distinguishes it from sibling tools targeting different 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?
No guidance on when to use this tool vs. alternatives like btp_list_service_instances or btp_list_subaccounts. Lacks prerequisites or context for proper invocation among many similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all technical regions available in the global account (e.g., 'us10', 'eu10').
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It describes a read-only list operation with no side effects. This is adequate for a simple query but does not cover permissions, rate limits, or error scenarios.
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?
A single, front-loaded sentence with no filler. Every word adds value, making it highly efficient.
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 simplicity (list of regions) and no output schema, the description is minimally complete. However, it lacks details on output format or potential errors, which could be helpful for agents.
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 includes two required parameters (args, kwargs) with no descriptions, and the tool description does not explain them. Schema description coverage is 0%. The description instead suggests no parameters needed, creating ambiguity.
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 lists all technical regions in the global account, with concrete examples (e.g., 'us10', 'eu10'). This verb-resource combination is distinct from sibling tools that handle services, bindings, instances, etc.
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 listing regions, but does not explicitly state when to use this tool versus alternatives, nor provide when-not-to-use guidance. Sibling tools differ in type, so context is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List service bindings (credentials for applications) in a subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the action but omits traits like read-only nature, pagination, error handling, or permission requirements.
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, which is concise, but it lacks necessary detail to be effective.
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, no annotations, and generic parameters, the description fails to provide enough information for correct usage, such as how to specify the subaccount.
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 defines two generic string parameters 'args' and 'kwargs' with no descriptions. The tool description does not explain what these parameters accept, leaving the agent to guess. Schema coverage is 0%.
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', the resource 'service bindings', and provides a parenthetical explanation 'credentials for applications'. It distinguishes from sibling tools like btp_list_service_instances.
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. No prerequisites or context provided for invoking the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all service instances (active services) in a subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states the action. No mention of authentication, rate limits, performance, or side effects. For a read operation, 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, no filler. Front-loaded with action, but could be restructured to include parameter handling.
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?
Lacks essential details: requires subaccount context, but no mention of how to specify it via parameters. No output schema. Incomplete for a list operation with opaque arguments.
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?
Two required parameters (args, kwargs) with no schema descriptions. The description does not explain their meaning or format, leaving the agent unable to use them correctly.
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 action: list service instances in a subaccount. Verb and resource are specific, but doesn't differentiate from sibling list tools.
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 like btp_list_service_bindings or btp_list_subscriptions. Agent must infer context from tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all subaccounts in the current global account including their IDs, names, and states.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like read-only nature, rate limits, or required permissions. The description only states what it does, not side effects or constraints.
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, but it omits essential parameter information. It is not overly verbose, but the brevity sacrifices completeness.
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 output schema, the description partially covers return values but fails to explain the two required parameters. For a tool with no annotations and minimal schema guidance, the description is incomplete.
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 two required parameters (args and kwargs) with no descriptions and 0% schema coverage. The description does not explain their purpose or expected values, leaving the agent unable to construct valid invocations.
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', the resource 'subaccounts', the scope 'in the current global account', and the returned fields 'IDs, names, and states'. This distinguishes it from sibling list tools like 'btp_list_service_instances' or 'btp_list_subscriptions'.
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 'btp_get_subaccount' for a specific subaccount or other list tools. No context on prerequisites or comparisons is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List multi-tenant application subscriptions in a subaccount.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'list,' implying read-only, but does not explicitly state it is non-destructive, nor disclose authorization needs, pagination, or error handling. Minimal 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 a single, concise sentence with no fluff. However, it could be more efficient by also addressing parameters or usage without significant length increase. Slight deduction for missing information.
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 no output schema and 0% parameter coverage, the description is too brief. It fails to explain how to specify the subaccount or interpret the generic args/kwargs, leaving 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?
Schema coverage is 0%, and the description adds no meaning to the two generic parameters (args, kwargs). It does not explain their expected format or how they map to listing subscriptions, leaving the agent guessing.
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 lists 'multi-tenant application subscriptions in a subaccount,' specifying the verb (list), resource (subscriptions), and scope (subaccount). This distinguishes it from sibling tools that list other entities (e.g., service instances, bindings).
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 alternative list tools (e.g., btp_list_service_instances). There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all users who have been added to the current global account or custom IdP.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits like read-only nature, authentication requirements, pagination, or rate limits. It merely restates the action.
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 of 12 words, concise and without wasted information. However, it is too brief to be fully informative.
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 absence of annotations and output schema, and the opaque parameters, the description fails to provide adequate context for an agent to correctly invoke the tool. It lacks essential details about input format, output, and usage constraints.
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 two generic parameters (args, kwargs) with no schema descriptions (0% coverage). The description does not explain their meaning or how to use them, leaving the agent without guidance.
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 all users who have been added to the current global account or custom IdP', which specifies the verb (list) and resource (users), distinguishing it from sibling tools that list other entities.
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 provided on when to use this tool vs alternatives, such as filtering or other user-related operations. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnostic tool to verify connectivity and login status. Use this if you are unsure if the BTP CLI is configured correctly.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes its function as a diagnostics check, implying no side effects, but lacks detail on output or error cases. No annotations provided, so description carries burden but is minimal.
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?
Two concise sentences, front-loaded with purpose, no fluff.
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?
Simple tool but parameters are critical and undocumented; no output schema or annotations. Description is insufficient for proper 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?
Two parameters 'args' and 'kwargs' are vague and unexplained in description. With 0% schema coverage, the description adds no meaning, leaving agent unable to use correctly.
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 it's a diagnostic tool to verify connectivity and login status, distinguishing it from sibling tools that list or manage 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?
Explicitly tells when to use: 'if you are unsure if the BTP CLI is configured correctly', which is straightforward and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an entitlement (service plan quota) from a subaccount. Useful for freeing up global quota or cleaning up unused services.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| kwargs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should cover behavioral traits. It indicates the tool is destructive but lacks details on required permissions, side effects, or error conditions. The description is too brief.
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 two sentences, directly stating purpose and usage context. Every sentence adds value, and it is appropriately 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?
Despite low schema coverage and no annotations, the description omits critical information like subaccount identifier or required arguments. It is insufficient for a tool that removes quota, which involves state changes and constraints.
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 has 0% description coverage with generic parameters 'args' and 'kwargs'. The description adds no information about what these parameters represent or how to use them, failing to compensate for the schema gap.
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: 'Remove an entitlement (service plan quota) from a subaccount.' It identifies the specific resource and scope, and the sibling tools are mostly list or subaccount management tools, so this tool is distinct.
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 gives a usage context: 'Useful for freeing up global quota or cleaning up unused services.' However, it does not provide when-not-to-use or explicit alternatives, leaving some ambiguity.
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.
v0.1.0btp_create_subaccountbtp_delete_subaccountbtp_execute_commandbtp_get_destinationbtp_get_global_accountbtp_get_subaccountbtp_list_destinationsbtp_list_environment_instancesbtp_list_regionsbtp_list_service_bindingsbtp_list_service_instancesbtp_list_subaccountsbtp_list_subscriptionsbtp_list_usersbtp_pingbtp_remove_entitlementScored across 16 tools
Each tool targets a distinct resource type or action, with clear descriptions. The generic btp_execute_command is explicitly a fallback, reducing potential confusion with dedicated tools.
All tools start with 'btp_' and follow verb_noun pattern, though verbs vary (list, get, create, delete, remove). Minor inconsistency: 'remove_entitlement' instead of 'delete_entitlement', and 'ping'/'execute_command' lack a noun.
16 tools cover a broad yet focused domain of SAP BTP management, not too few or too many. The count is well-suited for the server's purpose.
The tool set lacks update and delete operations for most resource types (e.g., service instances, bindings, destinations, subscriptions). Only subaccounts have create and delete. The generic btp_execute_command can compensate, but the dedicated surface is significantly incomplete.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
An AI concierge that turns static forms into adaptive AI conversations. From any MCP client.
Connect, monitor, and control AI agents — tasks, approvals, schedules, and governance.
