Skip to main content
Glama

YieldLord · 包租公

find_recommendations

Read-only

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
riskNo
wingNoSpread width, only meaningful with defined_risk=true: tight = least buying power, wide = more credit.
intentNo
tickerYes
directionNo
timeframeNotarget DTE in days, e.g. 21/30/45 (default 30)
defined_riskNotrue = 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources