AstraEye Labs

List available analyses

list_analyses

Read-onlyIdempotent

Lists the analyses AstraEye can run: each one's id, name, scientist, asset class (crypto, equity or universal; an analysis runs only on assets of its class, universal on both), what it does, the plan it is on and whether the member's plan includes it, with the member's own plan alongside, and readsEarlierFindings: true for an analysis that works from what other analyses found, which must run in a later stage or phase than them (needs names specific prerequisites when known), and securityTypes: the kinds of security it can describe (stock, etf, mutual_fund), where an analysis about companies lists only stock, is not run for a fund and is not charged for one. Use the id or name when asking SAGE about an analysis or asking it to run one. Prices are not listed; SAGE states them when asked.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_analyses"
  }
}

Input Schema

Name	Required	Description
`detail`	No	summary (default): id, name, scientist, asset class and a one-line summary. full adds each analysis's full description; best with a scientist or assetClass filter.
`scientist`	No	Only this scientist's analyses, by id (for example atlas or nova).
`assetClass`	No	Only analyses for this asset class.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 28, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish that this is a safe, read-only, idempotent, closed-world operation. The description adds substantial context beyond annotations: it explains plan inclusion, readsEarlierFindings prerequisites, securityTypes behavior, and that prices are not listed but are available from SAGE on request. It does not cover pagination or ordering details, which keeps it from a 5.

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 description is front-loaded with the core purpose, but it is delivered as one very long, dense sentence with many nested clauses. The information is valuable, yet the structure makes it harder to scan, and some field-level detail could be more cleanly separated.

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?

There is no output schema, so the description carries the burden of explaining return content, and it does so thoroughly: id, name, scientist, asset class, description, plan inclusion, readsEarlierFindings, prerequisites, and securityTypes. It also clarifies plan and pricing boundaries. An agent has enough context to call the tool and interpret the result.

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%, so the schema already documents detail, scientist, and assetClass. The description adds asset-class semantics in the return context but does not explain the parameters themselves beyond what the schema provides. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Lists the analyses AstraEye can run.' It clearly identifies a list operation over analyses. It does not explicitly contrast itself with the singular sibling get_analysis, so it stops short of full sibling differentiation.

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 guidance 'Use the id or name when asking SAGE about an analysis or asking it to run one' explains how to use the returned identifiers downstream, but not when this tool should be selected over alternatives. No when-not-to-use cases or direct sibling alternatives are provided. Usage is implied rather than explicitly framed.

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

All AstraEye Labs 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?