StockLens

Inspect Reading

inspect_reading

Read-onlyIdempotent

Explain why an exact StockLens reading says something, using evidence already produced; no credits, new analysis or writes. Use for a selected score reason, finding, qualification or assessment, including momentum, authorized moat or Beneish where produced. Copy reading_ref and the labelled view/selector from inspection arguments; overview is the default. A clear evidence request authorizes this read without another permission question. Follow a returned overview continuation only when more saved choices are needed; each call reads this same exact reading. Keep the company, date, reading kind/depth and all material context. USED_IN_ASSESSMENT, RELATED_OBSERVATION and FUTURE_CHECK have different roles. A selected_reason SOURCE_METRIC supplies its own saved interpretation; RELATED_ASSESSMENT is context, not evidence for that reason. Narrative sentences stay unbound. A standalone observation has no assessment-relative role; produced inapplicability can be inspected for its explanation, without a calculated score. Assessment-level unions do not prove per-sentence witnesses, a group is not a causal pair, and shared observations are not independent corroboration. Unknown, gated, expired and uncaptured detail stays typed; never substitute today's reading, retry unchanged or start a run to fill it. Pending/failed narrative does not erase deterministic evidence. Avoid repeating the same bound meaning as both narrative and finding. Only the four declared views are supported; this is not full structural inspection of every web card. An exact report link is optional.

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": {
      "reading_ref": "<reading_ref>"
    },
    "name": "inspect_reading"
  }
}

Input Schema

Name	Required	Description
`view`	No	Copy from inspection.arguments; default overview. Only overview, finding, assessment or observation.
`selector`	No	Copy the selector from inspection.arguments, including an optional overview continuation. Required for other views.
`reading_ref`	Yes	Exact reading_ref returned by StockLens. Never reconstruct from a ticker or date.

Output Schema

Name	Required	Description	Default
`kind`	No
`view`	Yes
`as_of`	No
`scope`	Yes
`reason`	No
`status`	Yes
`company`	No
`finding`	No
`message`	No
`verdict`	No
`coverage`	No
`evidence`	No
`narrative`	No
`assessment`	No
`inspection`	No
`report_url`	No
`limitations`	No
`reading_ref`	Yes
`availability`	Yes
`evidence_scope`	No
`selected_reason`	No
`detail_expires_at`	No
`binding_availability`	No
`reason_origins_availability`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 6, 2026

changedOutput schema / properties / evidence_scope / enum

Previous value: -[
-  "unbound",
-  "assessment",
-  "finding",
-  "observation"
-]New value: +[
+  "unbound",
+  "assessment",
+  "finding",
+  "observation",
+  "selected_reason"
+]

addedOutput schema / properties / reason_origins_availability

Added value: +{
+  "enum": [
+    "AVAILABLE",
+    "PARTIAL",
+    "NOT_APPLICABLE",
+    "UNAVAILABLE",
+    "GATED",
+    "NOT_CAPTURED",
+    "UNBOUND",
+    "EXPIRED",
+    "CAPTURE_FAILED",
+    "BUDGET_LIMIT"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / selected_reason

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "destination_availability": {
+      "enum": [
+        "AVAILABLE",
+        "PARTIAL",
+        "NOT_APPLICABLE",
+        "UNAVAILABLE",
+        "GATED",
+        "NOT_CAPTURED",
+        "UNBOUND",
+        "EXPIRED",
+        "CAPTURE_FAILED",
+        "BUDGET_LIMIT"
+      ],
+      "type": "string"
+    },
+    "driver": {
+      "additionalProperties": false,
+      "properties": {
+        "context": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "domain": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "kind": {
+          "enum": [
+            "SUPPORTIVE",
+            "HEADWIND",
+            "MIXED",
+            "COVERAGE_GAP",
+            "NEUTRAL_NOT_MATERIAL"
+          ],
+          "type": "string"
+        },
+        "label": {
+          "type": "string"
+        },
+        "metric": {
+          "type": [
+            "null",
+            "string"
+          ]
+        },
+        "peer_group": {
+          "type": [
+            "null",
+            "string"
+          ]
+        }
+      },
+      "required": [
+        "kind",
+        "label"
+      ],
+      "type": "object"
+    },
+    "interpretation_ref": {
+      "type": "string"
+    },
+    "reason_ref": {
+      "type": "string"
+    },
+    "relation": {
+      "description": "SOURCE_METRIC identifies the selected saved occurrence. RELATED_ASSESSMENT offers context, not witnesses for this reason.",
+      "enum": [
+        "SOURCE_METRIC",
+        "RELATED_ASSESSMENT"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "reason_ref",
+    "interpretation_ref",
+    "driver",
+    "destination_availability"
+  ],
+  "type": [
+    "null",
+    "object"
+  ]
+}

AddedNov 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already establish that this is read-only, idempotent, and non-destructive, but the description adds substantive behavior: no credits or new analysis/writes, every call reads the same saved reading, unknown/gated/expired data stays typed, and pending/failed narrative does not erase deterministic evidence. It also sets clear scope limits, including that only four views are supported and this is not full structural inspection.

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, but the body is one dense, jargon-heavy paragraph with many abstract caveats (for example assessment-level unions, causal pairs, and independent corroboration) that are hard to scan. The constraints are relevant, but a shorter or bulleted structure would preserve them without the parsing burden.

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 a read-only, idempotent tool with a fully described input schema and an output schema, the description covers purpose, evidence semantics, view limits, continuation behavior, and failure states. It is more than complete enough for an agent to call it correctly.

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 coverage is 100% and the schema already documents the view default, selector copying, and reading_ref format; the description mostly repeats those instructions. It adds a small amount by tying selector use to saved continuation choices and insisting each call targets the same exact reading, but not enough to exceed the baseline for fully documented parameters.

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?

Opens with a specific verb and object ('Explain why an exact StockLens reading says something') and bounds the operation to evidence already produced. It distinguishes this from new analysis, run initiation, and writes, though it never names the sibling tools it replaces.

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?

States concrete use cases (selected score reason, finding, qualification, assessment) and several when-nots: do not substitute today's reading, retry unchanged, or start a run to fill missing detail. It also explains when to follow an overview continuation and limits the tool to four named views, leaving little ambiguity about invocation.

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?