@pired/sap-fiori-mcp-server

Sign in to SAP BTP in a browser

btp_login

Perform one-time SAP BTP login for a destination, storing the refresh token so later calls renew automatically. Use when a destination's token is expired or missing.

Instructions

Opens a browser for the one-time SAP BTP login of a destination and stores the refresh token it returns, so later calls renew themselves. Use it when a destination fails with an expired or missing refresh token. The destination must carry a serviceKeyPath. Signing in takes longer than an MCP client waits for a tool call, so this returns 'pending' with the URL once the browser is open: finish the login there and call it again for the same destination to collect the outcome. Set noBrowser to get the URL back instead, for a machine with no browser of its own.

Input Schema

TableJSON Schema

Name	Required	Description
`noBrowser`	No	Do not open a browser; return the URL to open by hand (over SSH, or in a container)
`destination`	Yes	Name of the destination to sign in for, as list_btp_destinations reports it
`waitSeconds`	No	Seconds to hold this call waiting for a fast login before answering 'pending'. An MCP client abandons a tool call after 60 s, so this never goes near that.
`timeoutSeconds`	No	How long the login itself stays open in the background, waiting for the browser callback

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	Authorize URL that was opened, or the one to open by hand when noBrowser was set
`detail`	Yes
`sealed`	Yes	How the refresh token was stored: 'dpapi' on Windows, 'plain' elsewhere
`pending`	Yes	True when the browser is open and the login has not come back yet; call the tool again to collect the outcome
`signedIn`	Yes
`sealError`	No	Set when sealing failed and the token was stored in the clear
`destination`	Yes
`identityProvider`	No	Host that actually asked for the credentials, when it could be resolved

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.26.1Sep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the two-phase async behavior (returns 'pending' with the URL, requires a second call to collect the outcome), explains why it outlasts MCP client timeouts, and notes the side effect of storing a refresh token. This goes well beyond the annotations' bare mutation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A dense four-sentence description with no filler. Purpose, trigger condition, async timeout behavior, and the noBrowser fallback each earn their place without excessive length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with asynchronous side effects and a two-call workflow, the description covers the full invocation contract: when to use, precondition, pending response, repeat-call semantics, and headless fallback. The output schema handles return-value details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already documents all 4 parameters (100% coverage), but the description adds genuine context: ties waitSeconds to the MCP 60s call limit, explains noBrowser for headless machines, and links destination to the serviceKeyPath requirement. This is additive, not redundant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: opens a browser for the one-time SAP BTP login of a destination and stores the refresh token it returns. It clearly distinguishes itself from sibling list/get/execute tools by focus on authentication and token renewal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use it when a destination fails with an expired or missing refresh token' and adds a precondition (the destination must carry a serviceKeyPath). It stops short of naming when-not-to-use or alternative sibling tools, so it loses a point for not having explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.