YieldLord · 包租公

connect_my_account

Idempotent

Account status: whether this session is connected to a 包租公 · YieldLord account, which tier it is on, and how many credits are left. 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. 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
`confirm`	No	The confirm_token from the previous start_trial call, sent only after the user said yes.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

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.9/5.0

Behavior5/5

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

Annotations include readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: no-arg call returns text/URL only; start_authorization begins OAuth with specific technical details (401, WWW-Authenticate, PKCE); start_trial requires two-step confirmation. No contradiction with annotations; it supplements them thoroughly.

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 a single dense paragraph but front-loaded with the core purpose and usage triggers. Each sentence adds value, though the OAuth and trial instructions are interleaved, making it slightly harder to scan. Still, it is well-structured for the complexity it covers.

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?

No output schema exists, but the description states what is returned (text and URL) and explains post-connection behavior (tool list refresh). It covers prerequisites (user must have an account), the two-step trial confirmation, and OAuth flow. Given the tool's multi-mode complexity, nothing essential 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 100% with detailed per-parameter descriptions, but the description adds crucial flow context: confirm token usage, OAuth prerequisites (client_id, redirect_uri, code_challenge), and the rule never to confirm on the user's behalf. This goes well beyond the schema's literal field descriptions.

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 clear statement of purpose: reporting account status (connection, tier, credits). It distinguishes itself from siblings (explain_option, find_recommendations, get_market_climate) by explicitly noting it is the tool for account-related queries and personal data access. No ambiguity.

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?

Provides explicit when-to-use triggers (e.g., 'am I connected', credit queries, own positions) and when to call again (start_authorization, start_trial, after sign-in). It also clarifies that anonymous access cannot see personal data, so the tool is required in those cases. This is strong routing guidance.

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?