BeliefState

Get investment cases

get_cases

Retrieves dated investment cases for one company or research subject, with optional investor, direction and time filters. Returns attributed thesis records, case IDs, dates, citations and coverage information. Useful for building a research inventory or finding additional cases beyond a brief. Use get_brief for an ordinary overview and get_search_results for a thesis or topic question. Continue a requested inventory with unchanged selectors and its returned cursor. Uses account allowance or prepaid credit.

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": {
      "context": "<context>",
      "llm_model": "<llm_model>"
    },
    "name": "get_cases"
  }
}

Input Schema

Name	Required	Description
`as_of`	No
`limit`	No	Requested page size. For ticker/entity belief lists, MCP returns up to twelve complete summaries within its response budget; pagination.limit is the effective size. Continue with next_cursor and the same ticker/entity_id. REST supports larger pages.
`cursor`	No
`status`	No
`ticker`	No
`context`	Yes	User's research goal in one short sentence (max 300 characters); include relevant ticker and topic. Exclude names, contact/account/portfolio details, credentials and source text.
`direction`	No
`entity_id`	No	Released subject ID returned by get_subjects.
`llm_model`	Yes	Your model identifier, if known (e.g. gpt-6); otherwise leave unknown. Exclude credentials and private deployment names.
`person_id`	No
`time_horizon`	No
`changed_since`	No	Find initial research, author revisions, condition checks/plans or released outcomes becoming available after this cutoff. Keeps author dates and stance separate from system activity. Release changes and a complete ordered event-history checkpoint are not yet included.
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and idempotentHint=false on what reads like a query tool, and the description supplies the reason: "Uses account allowance or prepaid credit," i.e. the call is metered and has a billing side effect — context the annotations alone cannot convey. It also discloses the pagination/continuation contract, though it does not state whether selectors like ticker vs entity_id are mutually exclusive or what happens when neither matches.

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

Conciseness4/5

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

Purpose and scope are front-loaded in the first sentence, return contents second, routing third, continuation fourth, cost last — a sensible priority order with no filler. It is dense, packing return shape, sibling routing and billing into five sentences, but every sentence carries information an agent needs.

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?

For a 13-parameter, metered query tool with an output schema and non-read-only annotations, the description covers the missing pieces that structure cannot: sibling routing, cursor continuation discipline, and credit consumption. Remaining gaps (status enum semantics, as_of behavior) are refinements rather than blockers to a correct first call.

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 46% and 7 of 13 params (as_of, cursor, status, ticker, direction, person_id, time_horizon) carry no schema prose, so the description has to compensate. It names the investor, direction and time filter families and clarifies cursor reuse, but adds no meaning for status enum values, time_horizon format, or the ticker/entity_id choice — leaving half the surface to inference.

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?

States a specific verb and resource ("Retrieves dated investment cases") plus scope ("for one company or research subject") and the filter set (investor, direction, time). It also enumerates what comes back (attributed thesis records, case IDs, dates, citations, coverage), so an agent can distinguish it from get_case, get_brief and get_search_results without opening any schema.

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?

Explicit routing is provided: "Use get_brief for an ordinary overview and get_search_results for a thesis or topic question," with the positive case ("building a research inventory or finding additional cases beyond a brief") stated first. It also gives a continuation rule ("Continue a requested inventory with unchanged selectors and its returned cursor"), covering the multi-call pattern that would otherwise be ambiguous.

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

All BeliefState 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.