Skip to main content
Glama

schwab-mcp

by io.github.lonniev
OverviewDiscussionsAdmin

schwab_begin_oauth

Start the OAuth2 authorization flow.

Returns an authorization URL. Open it in a browser to log in and authorize. Then call check_oauth_status with the same npub to complete. Free. Proof of npub ownership is required so an observer cannot DOS your account by initiating OAuth flows in your name.

Do NOT call this pre-emptively. If a session may still be valid, attempt the live tool call first and only begin OAuth when it fails with upstream_auth_refresh_needed. A 'pending' check_oauth_status is not evidence that an existing session has lapsed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
npubYesYour DPYC patron npub (npub1...).
dpop_tokenYesRaw JSON of a kind-27235 Nostr event signed by npub — not base64, not NIP-98 'Authorization: Nostr <b64>' framing. Its `u` tag must hold THIS tool's exact name (from tools/list), not the endpoint URL; content:"", created_at within 60s of now, and a random `nonce` tag recommended. Or a cached dpop_token phrase.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dpop_token / description
      Previous value: -"A kind-27235 Nostr event signed by npub for this tool."New value: +"Raw JSON of a kind-27235 Nostr event signed by npub —\nnot base64, not NIP-98 'Authorization: Nostr <b64>' framing.\nIts `u` tag must hold THIS tool's exact name (from\ntools/list), not the endpoint URL; content:\"\", created_at\nwithin 60s of now, and a random `nonce` tag recommended. Or a\ncached dpop_token phrase."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description fully covers behavioral traits: it initiates the OAuth flow, requires proof of npub ownership, mentions DOS prevention, and explains the dpop_token constraints. It transparently describes the return value and required subsequent step.

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

Conciseness4/5

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

The description is well-structured with clear paragraphs and the main action front-loaded. While it is detailed, every sentence adds necessary context, making it appropriately concise for the 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 OAuth flow complexity, the presence of sibling tools, and the absence of output schema, the description is complete. It explains when to use, prerequisites, return value, and the next step (check_oauth_status). Also addresses security (DOS prevention).

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 coverage is 100%, so baseline is 3. The description adds significant meaning beyond the schema, especially for dpop_token detailing format, constraints, and use of 'u' tag. For npub, it adds usage context ('Your DPYC patron npub').

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 clearly states the tool starts the OAuth2 authorization flow and returns an authorization URL. It distinguishes from sibling tool 'check_oauth_status' by specifying it as the completion step.

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?

Explicitly instructs not to call pre-emptively and to first attempt a live tool call, only initiating OAuth when 'upstream_auth_refresh_needed' occurs. Also directs to call 'check_oauth_status' to complete the flow.

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

All schwab-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources