StockLens

Get Market Summary

get_market_summary

Read-onlyIdempotent

Retrieve the latest StockLens composite analysis summary for a stock ticker. Returns composite score (0-100), an overall rating, per-domain scores and grades, and key strengths and challenges. No account is required for the 600 largest companies StockLens scores. A signed-in caller reaches further (Free the same 600, Pro the top 5,000, Max the whole scored universe) and always reads anything on their own watchlist, however deep it ranks. Outside that surface the call is refused with TIER_INSUFFICIENT, which is NOT a statement that the stock is unscored: do not tell the user StockLens has no analysis for it. Data is derived from the most recent nightly analysis run. Use this to quickly assess a stock before deciding whether to run a full analysis. Does NOT accept more than one ticker and does NOT rank, sort, filter, or list multiple stocks — for any "top N", "best/worst", "highest/lowest scored", or filtered multi-stock request, call discover_stocks instead; never assemble a ranking by calling this tool repeatedly and inventing an order.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ticker`	Yes	Stock ticker symbol (e.g. AAPL MSFT TSLA)
`exchange`	No	Exchange code (e.g. NASDAQ NYSE). Optional - resolved automatically if omitted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scope`	Yes
`rating`	Yes
`sector`	Yes
`ticker`	Yes
`exchange`	Yes
`industry`	Yes
`watchlist`	No
`data_source`	Yes
`company_name`	Yes
`analysis_date`	Yes
`domain_scores`	Yes
`key_strengths`	No
`config_context`	Yes
`key_challenges`	No
`composite_score`	Yes
`watchlist_offered`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 20, 2026

addedOutput schema / properties / watchlist

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "message": {
+      "type": "string"
+    },
+    "tool": {
+      "type": "string"
+    },
+    "tracked": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "tracked",
+    "tool",
+    "message"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

addedOutput schema / properties / watchlist_offered
```
Added value: +{
+  "type": "boolean"
+}
```

Changed3 schema fields changedSep 5, 2026

addedInput schema / properties / ticker / pattern
```
Added value: +"^[A-Za-z][A-Za-z.\\-]{0,9}$"
```

addedOutput schema / properties / scope

Added value: +{
+  "enum": [
+    "single_ticker"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "ticker",
-  "exchange",
-  "company_name",
-  "sector",
-  "industry",
-  "composite_score",
-  "rating",
-  "domain_scores",
-  "analysis_date",
-  "config_context",
-  "data_source"
-]New value: +[
+  "ticker",
+  "exchange",
+  "company_name",
+  "sector",
+  "industry",
+  "composite_score",
+  "rating",
+  "domain_scores",
+  "analysis_date",
+  "config_context",
+  "data_source",
+  "scope"
+]

First observedAug 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: tier-based access, the TIER_INSUFFICIENT error semantics ('NOT a statement that the stock is unscored'), the nightly data derivation, and the instruction not to tell users a stock is unscored. This goes well beyond the structured annotations.

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 detailed but every sentence contributes: return payload, access tiers, error semantics, use case, and exclusions. It front-loads the core purpose and the key constraints before moving to edge cases, with no filler or repetition.

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 output schema exists and annotations cover safety, the description fills the remaining gaps: when to call it, what tier restrictions apply, how to interpret TIER_INSUFFICIENT, and which sibling to use for multi-stock queries. An agent has everything needed to invoke it correctly and avoid common mistakes.

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 adds value by explicitly constraining input to a single ticker and clarifying that exchange is optional and auto-resolved. It also reinforces that the tool cannot accept multi-ticker or ranking-style input, which is useful parameter-level guidance beyond the schema.

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: 'Retrieve the latest StockLens composite analysis summary for a stock ticker.' It also distinguishes this tool from siblings by explicitly stating it does NOT rank, sort, filter, or list multiple stocks, and points to discover_stocks for those cases.

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 gives an explicit use case: 'Use this to quickly assess a stock before deciding whether to run a full analysis.' It also provides clear exclusions: any 'top N', 'best/worst', 'highest/lowest scored', or filtered multi-stock request should call discover_stocks instead, and repeated calls to assemble a ranking are forbidden.

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?