YieldLord · 包租公

connect_my_account

Idempotent

Account status: whether this session is connected to a 包租公 · YieldLord account, which tier it is on, how many credits are left, and for Gold whether it is a trial or paid and when it ends. Call this when the user asks "am I connected" or "how many credits do I have left", and when they ask about THEIR OWN positions, portfolio, morning brief or realized history — anonymous access cannot see those, and this explains what connecting unlocks and gives the link. Called with no arguments it returns text and a URL only. Call it again with start_authorization=true once the user has an account, to begin the OAuth flow — or, if you can't receive a browser redirect, with start_link=true (a link the user approves, then pickup= gives you the token; nothing to copy back). A connected free account can also start its free Gold trial here (start_trial=true — always a two-step confirm with the user) or get the link to buy Gold. Call it again right after the user finishes signing in: for a connected account the reply lists every tool the connection unlocked (the tool list you fetched before sign-in only has the public ones — re-list tools after connecting).

Input Schema

TableJSON Schema

Name	Required	Description
`pickup`	No	The pickup from start_link. Returns pending until the user approves, then the access token (once).
`confirm`	No	The confirm_token from the previous start_trial call, sent only after the user said yes.
`agent_name`	No	With start_link: your name as the user knows you (shown on the approval page).
`start_link`	No	Easiest way to connect if you can't receive a browser redirect (you run on a server): returns a link and a code to give the user, plus a pickup for you. The user signs in and approves on that page — nothing to copy back. Then call again with pickup=<pickup> to receive the access token.
`start_trial`	No	Connected free accounts only: start the free Gold trial. Without `confirm` nothing is started — it returns a question for the user and a confirm_token. Ask the user; only after they clearly say yes, call again with start_trial=true and confirm=<confirm_token>. Never confirm on the user's behalf.
`start_authorization`	No	Begin the OAuth flow now. The call answers HTTP 401 with a WWW-Authenticate header pointing at this server's protected-resource metadata; follow it (dynamic client registration, PKCE S256, public client, no secret) and give the user the sign-in link to approve. Use it only after the user has an account — a plain link cannot open the authorize page, because that URL needs your own client_id, redirect_uri and code_challenge. If you can't receive a browser redirect (you run on a server, not on the user's computer), register this server's /api/mcp/callback page as your redirect_uri — the user copies the full URL from it back to you.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedInput schema / properties / agent_name

Added value: +{
+  "description": "With start_link: your name as the user knows you (shown on the approval page).",
+  "type": "string"
+}

addedInput schema / properties / pickup

Added value: +{
+  "description": "The pickup from start_link. Returns pending until the user approves, then the access token (once).",
+  "type": "string"
+}

addedInput schema / properties / start_link

Added value: +{
+  "description": "Easiest way to connect if you can't receive a browser redirect (you run on a server): returns a link and a code to give the user, plus a pickup for you. The user signs in and approves on that page — nothing to copy back. Then call again with pickup=<pickup> to receive the access token.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / start_authorization / description

Previous value: -"Begin the OAuth flow now. The call answers HTTP 401 with a WWW-Authenticate header pointing at this server's protected-resource metadata; follow it (dynamic client registration, PKCE S256, public client, no secret) and give the user the sign-in link to approve. Use it only after the user has an account — a plain link cannot open the authorize page, because that URL needs your own client_id, redirect_uri and code_challenge."New value: +"Begin the OAuth flow now. The call answers HTTP 401 with a WWW-Authenticate header pointing at this server's protected-resource metadata; follow it (dynamic client registration, PKCE S256, public client, no secret) and give the user the sign-in link to approve. Use it only after the user has an account — a plain link cannot open the authorize page, because that URL needs your own client_id, redirect_uri and code_challenge. If you can't receive a browser redirect (you run on a server, not on the user's computer), register this server's /api/mcp/callback page as your redirect_uri — the user copies the full URL from it back to you."

Changed2 schema fields changedSep 24, 2026

addedInput schema / properties / confirm

Added value: +{
+  "description": "The confirm_token from the previous start_trial call, sent only after the user said yes.",
+  "type": "string"
+}

addedInput schema / properties / start_trial

Added value: +{
+  "description": "Connected free accounts only: start the free Gold trial. Without `confirm` nothing is started — it returns a question for the user and a confirm_token. Ask the user; only after they clearly say yes, call again with start_trial=true and confirm=<confirm_token>. Never confirm on the user's behalf.",
+  "type": "boolean"
+}

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / start_authorization

Added value: +{
+  "description": "Begin the OAuth flow now. The call answers HTTP 401 with a WWW-Authenticate header pointing at this server's protected-resource metadata; follow it (dynamic client registration, PKCE S256, public client, no secret) and give the user the sign-in link to approve. Use it only after the user has an account — a plain link cannot open the authorize page, because that URL needs your own client_id, redirect_uri and code_challenge.",
+  "type": "boolean"
+}

First observedSep 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnly=false, idempotent=true, destructive=false, openWorld=false; the description goes well beyond that by disclosing the no-arg return shape (text and URL only), the one-shot token semantics of pickup, the mandatory user-confirmation requirement for start_trial ('Never confirm on the user's behalf'), and the OAuth mechanics (HTTP 401 + WWW-Authenticate, dynamic client registration, PKCE S256, public client, redirect_uri handling). It also tells the agent to re-list tools after connecting, which is a behavioral consequence no annotation conveys.

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 status purpose is front-loaded in the first sentence and almost every sentence carries non-redundant routing or flow information. It is nonetheless a dense single paragraph where the connection-mode instructions are stacked ('Call this when... Call it again with... Call it again right after'), which costs readability versus a mode-by-mode structure.

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 six-parameter, no-output-schema tool that spans status reporting and three distinct authorization paths, the description covers triggers, per-mode preconditions, return shapes ('returns text and a URL only', 'returns pending until the user approves, then the access token'), safety rails, and post-connect follow-up. Nothing an agent needs in order to select a mode and call it correctly appears to be missing.

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 description coverage is 100%, so the baseline is 3; the description earns above baseline by tying parameters into an execution order the schema does not spell out (start_link then pickup, start_trial then confirm, re-call after sign-in). It does not, however, add format or validation detail beyond what the per-parameter schema text already says.

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 names the exact resource and fields it reports (connection state, tier, remaining credits, Gold trial-vs-paid and end date) and separately names each action mode (start_authorization, start_link, start_trial, pickup, confirm). An agent can tell immediately that this is the account-connection/status tool and that it does not overlap with the market- or option-oriented siblings. The compound status-plus-flow nature is disambiguated by mode rather than left vague.

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?

Explicit trigger phrases are given ('am I connected', 'how many credits do I have left') plus a second condition: when the user asks about THEIR OWN positions, portfolio, morning brief or realized history, since anonymous access cannot see those. It also states preconditions for each mode ('only after the user has an account', 'connected free accounts only' for the trial) and which mode to pick when the agent cannot receive a browser redirect.

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

All YieldLord · 包租公 tools Inspect

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

Need Help?