StockLens

Read My Shortlist

get_shortlist_summary

Read-onlyIdempotent

Read 1 to 10 companies the person names in one call, in their order. Each row returns a verdict; scored rows supply the complete nightly reading, with scores, reasons, freshness and standing when available. It does not discover companies, sort the market, start analyses or change a portfolio. Use discover_stocks for market screens. State available standing inside the complete reading, led by Fundamental then the coarse Composite band, with standing.universe, each band's population and standing.as_of. Each listing market is its own universe; different markets may be read side by side, never ranked on one scale. StockLens supplies bands for US, Japan, Eurozone, UK and Canada when the market has at least 200 eligible companies. Never compute bands, quote exact numeric ranks or percentiles, or turn a standing change into a company fact. Relay standing_definition coverage exclusions and standing.message for available, outside_universe and unavailable. If standing is absent, say it could not be supplied. For a legacy plan_limited result, mention it only when the person asks where the company stands, ranks or compares; otherwise keep the score reading silent about that limit. Say: Standing is not included in your current plan. To change your plan, visit stocklens.com/pricing. Definitions appear once in standing_definition; each scored reading keeps its own date, and only available bands supply populations. Do not present different dates as a same-night comparison. Relay non-scored company statuses per row. Preserve a supplied free-save remedy and ask for consent before any save. Ask about ambiguous rows; never guess. For informational purposes, not investment advice. A successful result counts once toward the person's weekly research allowance; a RATE_LIMITED result states the limit and when it renews, so relay it and do not call again before then.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "companies": "<companies>"
    },
    "name": "get_shortlist_summary"
  }
}

Input Schema

Name	Required	Description	Default
`companies`	Yes	The person's own shortlist, 1 to 10 companies. Preserve their order; do not invent or add companies.

Output Schema

Name	Required	Description	Default
`scope`	Yes
`companies`	Yes
`standing_definition`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 10, 2026
- addedOutput schema / properties / companies / items / properties / standing / properties / market
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / companies / items / properties / standing / properties / universe
```
Added value: +{
+  "type": "string"
+}
```
AddedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, but the description adds substantial operational context: weekly research allowance consumption, RATE_LIMITED renewal behavior, standing availability rules, no numeric rank computation, plan_limited messaging, and consent before saving. There is no contradiction with the annotations.

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

Conciseness3/5

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

The purpose is front-loaded and most sentences carry relevant rules, but the description is a dense, overlong paragraph mixing tool selection, output formatting, compliance, and rate-limit guidance. It could be restructured or trimmed for faster scanning without losing necessary information.

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 tool's complexity around scoring, standing bands, market universes, plan limits, and rate limits, the description is complete. An output schema exists, yet the description still supplies the operational rules an agent needs to correctly relay and constrain results.

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 100% for the single 'companies' parameter, so the schema carries the main burden. The description adds some context about preserving order and asking about ambiguous rows, but it does not go much beyond the schema's own ticker/exchange descriptions.

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 first sentence states a specific action ('read 1 to 10 companies the person names') and the core return ('Each row returns a verdict'). It also explicitly distinguishes itself from discover_stocks and says what it does not do, though the purpose is slightly buried in a long block of output rules.

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?

It explicitly names the alternative ('Use discover_stocks for market screens') and lists when-not activities ('does not discover companies, sort the market, start analyses or change a portfolio'). It further gives conditional usage rules for plan_limited results, rate limits, and ambiguous rows.

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

All StockLens 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?