stockbit-mcp

login

Idempotent

Open a browser window to authenticate with Stockbit, unblocking all other tools. Ask the user first, then confirm and check status.

Instructions

Open a browser window so the user can sign in to Stockbit. Nothing else here works until they have. ASK THE USER FIRST, then call with confirm: true. This opens a real, visible window on their machine; where the client supports elicitation they are also asked directly. It returns in about a second, BEFORE the login finishes — a person takes minutes and every client has a tool-call timeout. Tell them to sign in in the window that opened, then call status to see whether it worked. Do not call this again while status says a login is in progress. The captured token goes straight to the keychain (or the encrypted file store off macOS). It is never returned here and never shown to you. If the browser is ALREADY signed in to Stockbit, it no longer waits fifteen minutes for a form that will never appear: it reads the credential out of the browser's own session and finishes in seconds, and if there is nothing usable there it signs that profile out and re-opens the login page. A credential read out of the browser that way is PROVEN against Stockbit before status calls it captured — nothing logged in, so its expiry says nothing about whether it works. That proof rotates the token, which stales the browser session the chartbit tools drive; a login that showed a real form is trusted without it. switch_account: true is for signing in as a DIFFERENT account — it clears the browser's Stockbit session first and never reuses what was there. Ask the user before using it; it signs them out of Stockbit in that browser profile. Refuses when STOCKBIT_NO_BROWSER is set (to anything but 0/false/no/off), and names the terminal command instead. It also refuses if a session is already stored, unless force: true (which switch_account implies). This does NOT log in to the trading account: that needs a 6-digit PIN typed at the user's own terminal via stockbit-auth trading-login, and no tool here accepts a PIN.

Input Schema

TableJSON Schema

Name	Required	Description
`force`	No	Log in again even though a session is already stored.
`confirm`	Yes	Must be true, and only after asking the user in words.
`reap_orphans`	No	If the browser exits immediately because something already holds the saved profile, end those processes and retry once. For the case where a previous login left browser processes behind and every login since has failed to open a window. ASK THE USER FIRST. It cannot tell an abandoned process from a working one — a browser that is fine answers the debugging port it was started with, not the new one this checks — so it ends EVERY process holding that profile, including a chart window the chartbit tools left open and are still using.
`fresh_profile`	No	Use a throwaway browser profile instead of the saved one — nothing carried over, so the user re-enters password and OTP. For a profile that is corrupt or held open by another process. To sign in as a different account, use switch_account instead. IT DOES NOT FIX THE CHART TOOLS: the throwaway profile is discarded, so the API session starts working while the saved profile the chartbit tools actually drive stays signed out — every chartbit tool keeps failing until a login runs WITHOUT this. Prefer reap_orphans for a profile merely held open.
`switch_account`	No	Sign the current Stockbit account OUT of the browser profile first, then show a real login form. For logging in as someone else. Implies force.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.3.0Sep 1, 2026

changedInput schema / properties / fresh_profile / description

Previous value: -"Use a throwaway browser profile instead of the saved one — nothing carried over, so the user re-enters password and OTP. For a profile that is corrupt or held open by another process. To sign in as a different account, use switch_account instead."New value: +"Use a throwaway browser profile instead of the saved one — nothing carried over, so the user re-enters password and OTP. For a profile that is corrupt or held open by another process. To sign in as a different account, use switch_account instead. IT DOES NOT FIX THE CHART TOOLS: the throwaway profile is discarded, so the API session starts working while the saved profile the chartbit tools actually drive stays signed out — every chartbit tool keeps failing until a login runs WITHOUT this. Prefer reap_orphans for a profile merely held open."

addedInput schema / properties / reap_orphans

Added value: +{
+  "description": "If the browser exits immediately because something already holds the saved profile, end those processes and retry once. For the case where a previous login left browser processes behind and every login since has failed to open a window.\nASK THE USER FIRST. It cannot tell an abandoned process from a working one — a browser that is fine answers the debugging port it was started with, not the new one this checks — so it ends EVERY process holding that profile, including a chart window the chartbit tools left open and are still using.",
+  "type": "boolean"
+}

Addedv1.2.2Aug 30, 2026

TDQS

A4.2/5.0

Behavior1/5

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

Although the description discloses timing, token storage, browser-session behavior, proof/rotation, and process termination, it contradicts the annotations. The annotations state destructiveHint=false, yet the description says the tool can sign the profile out, clear the browser's Stockbit session, and with reap_orphans end every process holding the profile, including chart windows still in use. Per the rubric, a direct annotation contradiction forces a score of 1 regardless of otherwise rich disclosure.

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?

The description is long but every sentence carries necessary safety, sequencing, or side-effect information. It is front-loaded with the core action and the mandatory 'ASK THE USER FIRST' instruction. Despite its length, there is no filler or repetition; the density is justified by the tool's complexity.

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?

Given the tool's complexity, multiple boolean parameters, external browser side effects, and no output schema, the description is complete. It covers the async return timing, the token destination, the status check follow-up, environment-variable refusal, non-trading PIN exclusion, and all parameter edge cases. Nothing needed for safe invocation is missing.

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

Parameters5/5

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

Schema coverage is already 100%, and the description adds substantial meaning beyond the schema: confirm must be user-approved in words, force bypasses an existing stored session, switch_account implies force and signs the user out, fresh_profile does not fix chart tools, and reap_orphans can kill healthy processes. This goes well beyond baseline parameter documentation.

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?

The description opens with a specific action and resource: 'Open a browser window so the user can sign in to Stockbit.' It also clearly separates this from the trading-account login by stating no tool accepts a PIN, which distinguishes it from trading-related siblings. This is unambiguous and immediately usable.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use and when-not-to-use guidance: ask the user first and pass confirm: true, call status afterward, do not call again while a login is in progress, use switch_account for a different account, and use the terminal command for the trading PIN. It also names refusal conditions and the force/switch_account interaction. This is comprehensive alternative-handling.

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

login

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools