financial-evidence
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| financial_evidence_topicsA | List supported topics and their fixed public raw-JSON routes without network access. |
| financial_evidence_routeA | Resolve one or more financial research topics to fixed public raw-JSON sources without fetching them. |
| financial_evidence_fetchB | Fetch bounded untrusted read-only JSON from fixed LiquiLens, Undertow, Seiche, and Palimpsest routes. Status reports transport only; evidence is not evaluated and Evidence Carrier verification is not performed. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| research_task | Start a source-cited funding, institution or liquidity review. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Financial Evidence getting started | Task examples, hosted workflow connection and evidence guidance. Offline. |
TDQS
Scored across 3 tools
fetch is clearly distinct (it actually retrieves data), but topics and route both return topic-to-route mappings without fetching, differing only in all-vs-subset scope. An agent could plausibly misselect between them, though the descriptions do help.
All tools use the consistent financial_evidence_ snake_case prefix. Minor deviation: fetch and route are verbs while topics is a noun, but the pattern is still predictable.
Three tools is on the lean side but reasonable for this narrow, read-only domain (discover topics, resolve routes, fetch JSON). Each tool roughly earns its place, though route and topics could arguably merge.
The discover-resolve-fetch workflow covers the stated read-only purpose with no obvious dead ends. Evaluation/verification is explicitly out of scope, so this is a minor scope limitation rather than a surface gap.