YieldLord · 包租公

Server Details

RENT-ranked covered-call, CSP & wheel income ideas, your positions & Greeks. Never places orders.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 22.8% over 40 days
OAuth: Works in Glama
Last Tested: 2026-09-26 20:41
Transport: Streamable HTTP · MCP 2024-11-05
URL

TDQS

A4.4/5.0

Scored 2026-09-26 20:35 across 4 tools

Disambiguation5/5

Each tool serves a clearly distinct purpose: account connection, market climate, finding recommendation candidates, and explaining a specific option contract. There is no overlap between the four tools, and even the resemblance between find_recommendations and explain_option is explicitly differentiated in the descriptions.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: connect_my_account, explain_option, find_recommendations, get_market_climate. The naming style is uniform and predictable across the set.

Tool Count5/5

Four tools is a well-scoped count for a focused option-income analysis server. Each tool earns its place and covers a core user need without bloat or redundancy.

Completeness4/5

The public tool surface covers the core workflow: get climate, find recommendations, explain a specific option, and handle account connection. Minor gap: the descriptions reference additional tools like explain_score and compare_candidates that are not in the current list, which implies a larger surface that becomes available after connection and could confuse an agent relying only on the fetched tool list.

Available Tools

4 tools

connect_my_accountA

Idempotent

Inspect

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).

ParametersJSON 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.

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.

explain_optionA

Read-only

Inspect

Explain ONE specific option contract the user named — ticker + put/call + strike + expiry. Unlike explain_score and compare_candidates, which can only explain contracts the engine already picked, this prices and scores the exact contract you ask about, including strikes the screener would never surface (deep in the money, far out of the money). Returns the live quote, Greeks, premium and collateral per contract, annualized yield, the chance it expires worthless (the SELLER's side), and the RENT score. If we cannot price it (no open interest, no bid, strike does not exist) it says so and why, rather than substituting a different contract. Output is analysis, not a recommendation to trade.

ParametersJSON Schema

Name	Required	Description
`lang`	No
`risk`	No
`type`	Yes
`expiry`	Yes	YYYY-MM-DD
`intent`	No	defaults to csp for a put, covered_call for a call
`strike`	Yes
`ticker`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only indicate readOnly and openWorld, but the description adds substantial behavioral context: it prices and scores the exact contract, returns live quote, Greeks, premium, collateral, yield, expiration probability from the seller's side, and RENT score. It also explicitly says that if pricing fails it will say so and why, rather than substituting another contract, and that the output is analysis, not a recommendation.

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 dense but well-structured: purpose first, then differentiation, then return contents, then failure behavior, then a caveat. Every sentence adds distinct value and there is no filler or repetition of schema fields.

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 no output schema and only 29% schema description coverage, the description is unusually complete. It covers what the tool returns, how it behaves on failure, and how to interpret the output (analysis, not a trade recommendation). The only minor omission is context for lang/risk, but their enum values are mostly self-explanatory.

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 only 29%, so the description carries real weight. It correctly maps the four required parameters to a concrete contract and adds meaning for strike ('including strikes the screener would never surface'). However, it does not describe the optional lang and risk parameters, leaving their semantics to the schema's enum values.

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 verb and resource: 'Explain ONE specific option contract the user named' and enumerates the contract components (ticker, put/call, strike, expiry). It also explicitly contrasts with explain_score and compare_candidates, so an agent can immediately tell this tool apart from alternatives.

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 clearly states when to use this tool: when the user names an exact contract, including strikes the screener would not surface. It names the alternatives and explains their limitation ('can only explain contracts the engine already picked'), which gives the agent a concrete routing rule.

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

find_recommendationsA

Read-only

Inspect

Find RENT-ranked option income candidates (candidates only, not advice) for a ticker. Set defined_risk=true for CREDIT SPREADS (bull put / bear call) instead of single-leg naked selling; omit it and we default to whatever this user actually trades. Output is analysis, not a recommendation to trade.

ParametersJSON Schema

Name	Required	Description
`risk`	No
`wing`	No	Spread width, only meaningful with defined_risk=true: tight = least buying power, wide = more credit.
`intent`	No
`ticker`	Yes
`direction`	No
`timeframe`	No	target DTE in days, e.g. 21/30/45 (default 30)
`defined_risk`	No	true = attach a protective long leg → CREDIT SPREAD (bull put / bear call). false = single-leg naked selling. Omit to use what this user actually trades (inferred from their open positions and last pick, never a silent guess — the result says which was used and why).

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds meaningful behavioral context: it is not advice, it returns candidates/analysis, and the defined_risk default is not silent — 'the result says which was used and why.' This is strong disclosure of behavior beyond what annotations provide.

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?

Two dense sentences with no filler: the core purpose and disclaimer come first, followed by the critical defined_risk usage caveat. Every clause contributes information needed to use the tool correctly.

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

Completeness4/5

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

For a 7-parameter tool with no output schema, the description covers the most important decisions and behavioral caveats. It could be more complete by explaining risk/intent selections and what the returned analysis contains, but the core invocation with just ticker is clear and safe.

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

Parameters3/5

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

Schema description coverage is only 43%, and the description substantially compensates for the most nuanced parameter, defined_risk, including the default behavior. However, it does not explain risk, intent, or direction beyond their enum names, and the 'RENT' ranking concept is left undefined, so the compensation is only partial.

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 uses a specific verb and resource: 'Find RENT-ranked option income candidates' for a ticker. It actively disambiguates the tool name by stating 'candidates only, not advice' and 'Output is analysis, not a recommendation to trade,' making its purpose unmistakable.

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?

The description gives explicit guidance for the key decision: 'Set defined_risk=true for CREDIT SPREADS ... instead of single-leg naked selling; omit it and we default to whatever this user actually trades.' It clearly explains the main branch of use, though it does not explicitly name alternative tools or state when not to use the tool at all.

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

get_market_climateA

Read-only

Inspect

Current rent climate (market regime + VIX/IV env + macro proximity → seller-friendliness read). Output is analysis, not a recommendation to trade.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint. The description adds the meaningful clarification that the output is analysis, not a trade recommendation, and characterizes it as a 'current' snapshot. This goes beyond the annotations without contradicting them.

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 single, front-loaded sentence that conveys the core purpose and a key behavioral caveat with no wasted words. Efficient and easily parseable.

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

Completeness4/5

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

For a zero-parameter tool with safety annotations covering read-only and open-world behavior, the description is sufficient. It communicates what the tool outputs and the important non-recommendation aspect. No critical information is 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?

The tool has zero parameters, so the schema is fully covered. The description does not need to explain parameters. Baseline of 4 applies.

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

Purpose4/5

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

The description clearly states the tool's purpose: providing a current market climate analysis based on market regime, VIX/IV environment, and macro proximity, with output as a seller-friendliness read. It is specific and distinct from siblings like find_recommendations, though it does not explicitly name alternatives.

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

Usage Guidelines3/5

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

The description implies usage for market climate analysis but does not explicitly state when to use this tool versus alternatives. It does clarify that the output is not a trade recommendation, indirectly guiding away from tools like find_recommendations, but lacks direct when/when-not guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 24, 2026

Changedconnect_my_account2 fields changed

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"
+}

1 tool updateSep 23, 2026

Changedconnect_my_account1 field changed

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"
+}

4 tool updatesSep 20, 2026
- First observedconnect_my_account
- First observedexplain_option
- First observedfind_recommendations
- First observedget_market_climate

Related MCP Connectors

cvserver
com.convexvalue
Live US options chains with Greeks and IV, a screener, SQL, and FMP fundamentals.
Finance Databases Search
1
ApexVol Options AnalyticsOAuth
io.github.ryansilk
Options analytics for AI assistants: chains, IV rank, VRP, Greeks, GEX, expected moves, screeners.
Finance Cryptocurrency
11
mcpOAuth
com.earnings-watcher
Live options-implied earnings moves, 10y implied-vs-actual history, IV rush/crush, scanner.
Finance Research & Data
1
Options Analysis SuiteOAuth
com.optionsanalysissuite
Options analytics: 17 pricing models, 17 Greeks, GEX, IV, 23 screeners, unusual, dark pool, max pain
Finance Research & Data
21

Related MCP Servers

longbridgeofficial
Finance Research & Data
longbridge
A
license
B
quality
A
maintenance
US/HK markets — 110 tools: real-time quotes, options, orders, fundamentals, alerts, DCA & portfolio
Updated 4 days ago (2026-09-22 11:10 UTC)
165
14
Apache 2.0
Quant Companion MCP
Finance Search
Ademscodeisnotsobad
F
license
Not graded
quality
D
maintenance
Provides real-time options analytics, pricing with Greeks, Monte Carlo simulations, volatility analysis, strategy backtesting, and risk metrics using actual market data from Yahoo Finance and Polygon.io.
Updated 9 months ago (2025-12-23 01:20 UTC)
1
-
traders-edge-mcp
Finance Research & Data
jsconiers
A
license
Not graded
quality
B
maintenance
Provides a consolidated 0DTE options cockpit for SPX/SPXW, including chain, Greeks, dealer exposure, volatility term structure, and economic events, using free delayed market data.
Updated 5 days ago (2026-09-21 14:01 UTC)
2
MIT
Interactive Brokers MCP Server
Finance Autonomous Agents Search
kelvingao
F
license
Not graded
quality
D
maintenance
Connects AI assistants to Interactive Brokers for intelligent portfolio management, options analysis, risk monitoring, and automated trading strategy suggestions. Enables real-time account tracking, Greeks calculations, option chain analysis, and playbook-based risk adjustments through natural language.
Updated 9 months ago (2026-01-05 11:09 UTC)
5
-