BeliefState

Get investment case

get_case

Retrieves one complete investment case by returned belief_id: investor, reasoning, evidence, risks, catalysts, conditions, revisions, outcomes, provenance and coverage gaps. Useful for deeper follow-ups; start company overviews with get_brief. Use paragraph_index only when returned in investment_case and follow support/text offsets for exact evidence. Optional relationship_paths inspects supported dependencies; scenario applies up to eight hypothetical conditions. Both preserve evidence and investor statements. 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": {
      "belief_id": "<belief_id>",
      "context": "<context>",
      "llm_model": "<llm_model>"
    },
    "name": "get_case"
  }
}

Input Schema

Name	Required	Description
`as_of`	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.
`scenario`	No	Optional hypothetical condition assumptions for this belief. Does not change evidence or predict the investor's response. REST: JSON-encode this query parameter.
`belief_id`	Yes
`llm_model`	Yes	Your model identifier, if known (e.g. gpt-6); otherwise leave unknown. Exclude credentials and private deployment names.
`support_index`	No	Source support within the selected paragraph; defaults to 0. Use next_support_index for another passage.
`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.
`paragraph_index`	No	Read exact source support only for a paragraph_index present in the returned investment_case. Records without investment_case do not support this selector. Requires belief_id. Continue with returned as_of and support/text offsets.
`relationship_paths`	No	Inspect directed edge sequences within this Belief's originating case. Maximum depth is 3; edge_budget bounds examined edge steps. Requires belief_id. REST: JSON-encode relationship_paths.
`support_text_offset`	No	UTF-16 offset within the selected supporting passage; defaults to 0. Use next_text_offset to continue its text.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The description adds context the annotations do not: it discloses the billing model ("Uses account allowance or prepaid credit"), which explains the readOnlyHint=false flag on an otherwise retrieval-shaped tool, and it asserts that relationship_paths and scenario "preserve evidence and investor statements." Remaining gaps are minor — it does not state rate limits or whether credit is charged on error — but it meaningfully extends the structured metadata rather than repeating it.

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 the get_brief alternative are front-loaded in the first sentence, followed by parameter-specific guidance in roughly schema order. Some sentences are overloaded (the paragraph_index/support-offset sentence packs three instructions), but nothing is redundant filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with nested objects, an output schema, and non-obvious selector chaining, the description covers the risky parts: when the paragraph selector is legal, how to continue offsets, and what the optional sub-queries do and do not alter. Because an output schema exists, the return-value enumeration is a bonus rather than a requirement, and no critical calling precondition appears missing.

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?

With 80% schema coverage the baseline is 3, and the description earns above that by explaining the cross-parameter dependency between paragraph_index and the returned investment_case, the follow-on support/text offset chaining, and that scenario applies "up to eight hypothetical conditions" while relationship_paths "inspects supported dependencies." It leaves belief_id, context, llm_model and as_of entirely to the schema, which is acceptable given their coverage.

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?

"Retrieves one complete investment case by returned belief_id" states a specific verb, resource, and keying mechanism, then enumerates the payload (investor, reasoning, evidence, risks, catalysts, conditions, revisions, outcomes, provenance, coverage gaps). It also distinguishes itself from the overview sibling by naming get_brief as the starting point, so an agent can separate it from get_cases and get_brief without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear routing guidance: "Useful for deeper follow-ups; start company overviews with get_brief," plus conditional instructions for paragraph_index (only when returned in investment_case). It stops short of explicitly contrasting with get_cases or stating when not to drill into a single belief, so it is strong but not fully exhaustive.

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.