financial-evidence
This server lets you route and fetch bounded public financial-evidence JSON from fixed sources, read-only and without an API key.
financial_evidence_topics: lists the supported topics with no network access.
financial_evidence_route: resolves up to 5 topics to their fixed public raw-JSON source URLs without fetching them.
financial_evidence_fetch: fetches untrusted read-only JSON from fixed public routes for the supported topics.
Supported topics: money-market, capital-market, china-economy, bank-risk, and market-liquidity.
Fetch accepts optional
timeoutandmax_byteslimits to bound retrieval.All tools are read-only and idempotent.
Fetch reports transport status only; it does not evaluate evidence or perform Evidence Carrier verification.
Works as a remote MCP endpoint or as a local stdio server with no required account or API key.
Allows querying financial evidence from money markets, bank risk, market liquidity, and China economy data through DuckDB using HTTP-backed views.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@financial-evidenceWhat are the latest money-market and bank-risk trends?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Financial Evidence Agent Skills
Try the underlying evidence first: Open three browser research questions for bank NPA disclosures, dollar funding and BTC exit estimates. Each example calls its named public MCP after a click and displays the returned sources, dates and limits. No key or installation is needed. The page also has setup and starter questions for Financial Evidence and eight other hosted MCPs. The browser examples call individual services; they do not verify an Evidence Carrier or evaluate a combined Financial Evidence packet.
Public documentation
includes a crawlable integration matrix plus agent-readable llms.txt, pricing,
integration metadata, and a dated
third-party marketplace ledger.
The v0.1.5 semantic contract defines transport-only
status, source-reported adapter metadata, and the explicit non-Carrier boundary.
Version 0.1.5 is a signed, independently verified release. Its versioned
Agent Skill, terminal, Codex, Gemini, editor, and bundle installs use the same
release, with published artifacts, container, Registry record, and Homebrew
formula. The Claude self-hosted marketplace command follows the repository's
mutable default branch; review the checked-out commit before enabling it.
Open, read-only Agent Skills for routing financial research to bounded public evidence. The first skill connects four complementary products without turning them into one score:
Seiche — money markets, repo, reserves, Treasury cash and system funding.
LiquiLens — covered bank and lender evidence.
Undertow — market depth, provider concentration and position-sized exit liquidity.
Palimpsest — revision-safe China economy evidence and information-state history.
For a daily research workflow, Market Brief provides free, source-cited funding, capital-market and liquidity briefs with local change comparisons. This separately versioned browser companion and agent skill uses the existing public evidence sources.
Install the agent skill
npx skills add https://github.com/beepboop2025/financial-evidence-skills/tree/v0.1.5/financial-evidence \
--skill financial-evidenceOr copy financial-evidence/ into the Agent Skills
directory supported by your agent. The folder follows the open
Agent Skills specification.
The skill is also indexed in the public skills.sh directory.
Once installed, ask your agent to research a money-market, capital-market, bank-risk, market-liquidity or China-economy question. The skill's description lets compatible agents activate it when the work matches.
Related MCP server: NanoSearchMCP
Use from any terminal
No account or API key is required. On macOS or Linux with Homebrew:
brew install beepboop2025/tap/financial-evidence
financial-evidence fetch --topic money-market --topic china-economyThe formula installs financial-evidence, financial-evidence-mcp, and native
Bash, Zsh, and Fish completions. Alternatively, run directly from GitHub
without installing:
uvx --from git+https://github.com/beepboop2025/financial-evidence-skills.git@v0.1.5 \
financial-evidence fetch --topic money-market --topic china-economyOr install it as a persistent command:
uv tool install git+https://github.com/beepboop2025/financial-evidence-skills.git@v0.1.5
financial-evidence topics
financial-evidence route --topic capital-market --format table
financial-evidence fetch --topic bank-risk --format ndjson
financial-evidence doctor --format csvExit code 0 means every requested source was retrieved, 1 means transport
was partial, and 2 means every requested source was unavailable. Legacy
packet status is preserved and equals transport_status; both mean transport
reachability only. Every packet says status_semantics: transport_only,
evidence_status: not_evaluated, and carrier_verification: not_performed.
That makes the client safe to compose in shell pipelines without mistaking an
HTTP success for validated evidence or a verified Evidence Carrier. JSON,
NDJSON, and CSV go to standard output; no result is silently replaced with a
score.
Outside Homebrew, shell completions are emitted as inert text:
financial-evidence completion zsh > ~/.zfunc/_financial-evidenceUse as MCP infrastructure
The public Streamable HTTP endpoint requires no local install, account, or API key:
https://liquilens.in/mcp/financial-evidenceIt exposes the same three read-only topics, route, and fetch tools for
clients that support remote MCP. The root .mcp.json is the
portable plugin configuration for that public remote:
{
"mcpServers": {
"financial-evidence": {
"type": "http",
"url": "https://liquilens.in/mcp/financial-evidence"
}
}
}The package also includes a dependency-free stdio server for local or
offline-compatible client setups. Its pinned configuration is in
integrations/mcp-config.json. Both transports
accept the MCP 2025-11-25 initialization flow and the stateless 2026-07-28
discovery flow. Local stdio messages use newline-delimited JSON-RPC; nothing
except protocol messages is written to standard output.
The official MCP Registry record publishes both the multi-architecture OCI
package and the public Streamable HTTP endpoint. Remote clients do not need
uv, Docker, a credential, or a local subprocess.
Install in Gemini CLI or Claude Code
Gemini CLI can install this repository as an extension. Its root
gemini-extension.json connects only to the fixed
public remote MCP endpoint and allowlists the three read-only tools; the
mirrored skills/financial-evidence folder gives Gemini the domain routing
instructions as well:
gemini extensions install https://github.com/beepboop2025/financial-evidence-skills \
--ref v0.1.5Claude Code can add this repository as a self-hosted marketplace and install the bundled plugin:
claude plugin marketplace add beepboop2025/financial-evidence-skills
claude plugin install financial-evidence@liquidity-labThis Claude command follows the mutable default branch. Review the checked-out commit before enabling the plugin; the versioned install routes above remain pinned to the verified release.
The Claude plugin loads the same byte-identical Agent Skill plus the root
.mcp.json public remote server. These are direct, self-hosted install routes;
they do not imply inclusion in a vendor-operated marketplace or endorsement.
Install in Codex; prepare ChatGPT
Codex can add the repository's plugin marketplace and then install the plugin:
codex plugin marketplace add beepboop2025/financial-evidence-skills --ref v0.1.5
codex plugin add financial-evidence@liquidity-labThe OpenAI plugin package combines the byte-identical Agent Skill with the
public remote MCP endpoint. The Codex repository install route is public. A
ChatGPT and Codex universal-directory submission is also prepared, but has not
been submitted, approved, or published by OpenAI. The remaining review,
publisher-identity, and domain-challenge steps belong to the OpenAI account
owner. See OPENAI_PLUGIN_SUBMISSION.md for the
listing copy and required positive and negative tests.
The root .mcp.json is the portable plugin form for the public remote MCP
server. VS Code and Cursor retain separate workspace files for the pinned local
stdio server, so plugin installs do not depend on a local Python process while
editor workspaces can still use one.
Install in VS Code or Cursor
The repository also includes editor-specific workspace configuration:
.vscode/mcp.json uses VS Code's top-level servers
object, while .cursor/mcp.json uses Cursor's top-level
mcpServers object. Public install links currently launch the verified v0.1.5
stdio server through uvx, matching the repository manifests.
VS Code can install the server through its protocol handler:
vscode:mcp/install?%7B%22name%22%3A%22financial-evidence%22%2C%22type%22%3A%22stdio%22%2C%22command%22%3A%22uvx%22%2C%22args%22%3A%5B%22--from%22%2C%22git%2Bhttps%3A%2F%2Fgithub.com%2Fbeepboop2025%2Ffinancial-evidence-skills.git%40v0.1.5%22%2C%22financial-evidence-mcp%22%5D%7DOr add it to your VS Code user profile from a terminal:
code --add-mcp '{"name":"financial-evidence","type":"stdio","command":"uvx","args":["--from","git+https://github.com/beepboop2025/financial-evidence-skills.git@v0.1.5","financial-evidence-mcp"]}'Cursor can install the same configuration through its base64-encoded deeplink:
cursor://anysphere.cursor-deeplink/mcp/install?name=financial-evidence&config=eyJ0eXBlIjoic3RkaW8iLCJjb21tYW5kIjoidXZ4IiwiYXJncyI6WyItLWZyb20iLCJnaXQraHR0cHM6Ly9naXRodWIuY29tL2JlZXBib29wMjAyNS9maW5hbmNpYWwtZXZpZGVuY2Utc2tpbGxzLmdpdEB2MC4xLjUiLCJmaW5hbmNpYWwtZXZpZGVuY2UtbWNwIl19Install uv first so uvx is on your path. Review the source and exact
configuration before accepting an editor's install or trust prompt: uvx
executes the pinned package locally, and the fetch tool can contact the fixed
public HTTPS sources documented by this project. Cursor asks for tool approval
by default. VS Code normally asks you to trust a server when it first starts,
but starting directly from mcp.json can skip that prompt, so inspect the file
before using its inline start action. These are self-installable compatibility
artifacts, not claims of a VS Code or Cursor marketplace listing or endorsement.
For desktop clients that support one-click MCP Bundles, download
financial-evidence-0.1.5.mcpb from the last verified GitHub release. The bundle uses the
cross-platform uv runtime and requires no API key or configuration.
Finance-tool integrations
Remote MCP: connect any Streamable HTTP client to
https://liquilens.in/mcp/financial-evidence; no local runtime, account, or API key is required.Gemini CLI: the root extension manifest bundles the Agent Skill and allowlists the three tools exposed by the public remote MCP endpoint.
Claude Code: the self-hosted
liquidity-labmarketplace installs the versioned plugin, Agent Skill, and MCP configuration from this repository.Codex: the repository marketplace installs the Agent Skill and public remote MCP package directly.
ChatGPT: the universal-directory submission packet is prepared; public availability remains pending account-owned verification, submission, review, and publication.
OpenBB: install
financial-evidence[openbb]from this repository inside an OpenBB environment and runopenbb-build. The registered router exposesobb.financial_evidence.routes()andobb.financial_evidence.fetch(), which also become available to OpenBB's REST, notebook and MCP surfaces.DuckDB: run
integrations/duckdb/financial_evidence.sqlto create separate HTTP-backed views for all four products.Excel / Power Query: paste
integrations/excel/FinancialEvidence.pqinto Advanced Editor and invoke, for example,FinancialEvidence("money-market").FDC3: the public Financial Evidence Inspector receives and broadcasts declared standard contexts through
window.fdc3.integrations/fdc3/appd-record.jsonis its FDC3 2.0 web-app record for self-hosted or enterprise directories. The same record is served as raw JSON for direct directory ingestion. The record and runtime do not imply FINOS review, directory acceptance, or vendor endorsement.Containers: tagged releases publish a multi-architecture image to
ghcr.io/beepboop2025/financial-evidence-skills. The image runs stdio MCP by default; use--entrypoint financial-evidencefor terminal commands.Official MCP Registry: tagged images are published under
io.github.beepboop2025/financial-evidenceusing GitHub OIDC and the image's ownership annotation. No long-lived registry credential is stored.
Release integrity
Each tagged release rebuilds and retests the Python and JavaScript contracts
from the exact signed main commit before publication. The release attaches a
wheel, source archive, MCP bundle, CycloneDX SBOM, and SHA256SUMS; GitHub
Sigstore build-provenance attestations bind every downloadable artifact to the
release workflow. Consumers can verify an artifact with gh attestation verify
against beepboop2025/financial-evidence-skills.
Optional bounded retrieval
The bundled helper uses only Python's standard library, accepts a fixed topic allowlist and fetches only fixed public HTTPS endpoints:
python3 financial-evidence/scripts/fetch_evidence.py \
--topic money-market --topic china-economyIt returns one JSON packet with exact and resolved source URLs, canonical human
scope URLs, retrieval clocks, byte counts, content SHA-256 values, separate
product documents, and explicit errors. Successful responses also include only
the endpoint-specific source state and clocks named by explicit adapters, with
RFC 6901 paths and fetched-byte provenance; missing configured fields are
not_reported. The router does not infer freshness, eligibility, or rights.
Routes declare financial_authority: none and carrier_state: not_published,
and therefore expose no carrier_url. Redirects are rejected before following.
Returned JSON is untrusted evidence data, not executable instructions. Missing,
restricted, or unavailable evidence is never converted to zero or “calm.”
Boundaries
This repository provides public research routing, not investment advice, security recommendations, execution quotes, credit ratings or guarantees. Source publishers retain their rights; an open-source helper does not relicense upstream data.
Development
python3 -m unittest discover -s tests -v
python3 -m py_compile financial-evidence/scripts/fetch_evidence.py src/financial_evidence/*.pyThe code and skill instructions are MIT-licensed.
Available Tools
3 toolsfinancial_evidence_fetchFetch Financial EvidenceBRead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | Yes | ||
| timeout | No | ||
| max_bytes | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and idempotent behavior, and the description adds meaningful context: evidence is untrusted, responses are transport status only, and no evidence evaluation or Evidence Carrier verification occurs. This prevents an agent from overinterpreting what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the action front-loaded and the critical caveat immediately after. There is no filler, and it does not repeat what annotations or the schema already provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, sibling tools, and no output schema, the description leaves too much unspecified: parameter semantics, return-value structure, and when to choose this tool over alternatives. The transport-only caveat is useful but not enough to make the definition complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meaning. The word 'bounded' is a weak implicit hint about size limits, but it does nothing to clarify the required topics array or the timeout and max_bytes controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: fetch JSON from fixed named routes, with useful qualifiers like bounded, untrusted, and read-only. It is clear what the tool does, but it does not explicitly contrast with the sibling tools financial_evidence_topics and financial_evidence_route, so it falls short of top-tier differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus its siblings, no explicit 'use X instead' conditions, and no exclusion criteria. The status-report caveat is behavioral information, not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
financial_evidence_routeRoute Financial ResearchARead-onlyIdempotentInspect
Resolve one or more financial research topics to fixed public raw-JSON sources without fetching them.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful operational context: sources are fixed, public, raw JSON, and the tool does not fetch them. This goes beyond the annotations, though the exact return shape is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the verb, resource, and the most important behavioral distinction ('without fetching them'). There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The single parameter is fully constrained by the schema, and annotations cover side-effect safety. The description states the core contract: topics in, fixed public raw-JSON sources out, no fetching. Without an output schema, a slightly more explicit statement of the returned mapping would be ideal, but the definition is still sufficient for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides needed context that the 'topics' parameter refers to financial research topics and that each resolves to a fixed source. The schema's enum carries the allowed values, so the agent has enough information, but the description does not explain what each enum value represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Resolve'), a precise object ('one or more financial research topics'), and the output ('fixed public raw-JSON sources'), plus the key constraint 'without fetching them.' This clearly separates it from financial_evidence_fetch and financial_evidence_topics without needing to inspect either.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without fetching them' signals that this tool is for routing only and implicitly tells the agent not to use it when retrieval is needed. It does not explicitly name sibling tools or list when-not scenarios, but the context is clear and adequate for a simple one-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
financial_evidence_topicsList Financial Evidence TopicsARead-onlyIdempotentInspect
List supported topics and their fixed public raw-JSON routes without network access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds useful context that the result is fixed, public, raw-JSON, and requires no network access. This goes beyond the structured annotations by clarifying auth expectations, output format, and the absence of network I/O.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one focused sentence that leads with the action and resource, then adds the key behavioral qualifiers. Every word earns its place; there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool, the description is complete: it states what will be returned (topics and routes), the nature of those routes (fixed, public, raw-JSON), and the operational characteristic (no network access). No output schema exists, but the description supplies enough for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline of 4 applies and the description does not need to explain parameter meaning. The empty input schema is fully accounted for, and the description confirms there is nothing else to configure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a precise resource ('supported topics and their fixed public raw-JSON routes'), making the tool's function immediately clear. It also differentiates from the sibling fetch/route tools by emphasizing enumeration of routes rather than retrieval of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without network access' signals that this is a metadata/discovery call, not a data-fetching call, so it should be used before invoking financial_evidence_fetch. It does not explicitly name the sibling tools or state when not to use them, but the zero-parameter, discovery-oriented wording gives sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.5- First observed
financial_evidence_fetch - First observed
financial_evidence_route - First observed
financial_evidence_topics
TDQS
Scored across 3 tools
The fetch tool is clearly distinct, but topics and route overlap somewhat since topics already lists the raw-JSON routes. The distinction is mostly clear: topics returns the full catalog, while route resolves a specific topic to its sources.
All tool names share the consistent financial_evidence_ prefix and use straightforward lowercase snake_case. The final words topics, route, and fetch are simple and predictable.
Three tools is well-scoped for the stated purpose of listing, resolving, and fetching financial evidence sources. Each tool serves a distinct step in the workflow without unnecessary bloat.
The topics -> route -> fetch pipeline is complete for transport-level evidence retrieval. Missing verification or evaluation is intentional and explicitly disclaimed, but the server name might lead agents to expect some evidence assessment capability.
Maintenance
Related MCP Connectors
Read-only hosted MCP over CanonicAI's cited Answers corpus on canonicai.com.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Read-only MCP access to DSGHT.ai published foresight and country-grounded claim resolution.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceQuery SEC EDGAR filings, XBRL financials, and company data through MCP.685 npm10Apache 2.0
- FlicenseNot gradedqualityDmaintenanceProvides web search, page fetching, and A-stock data access (financial reports, announcements, research reports, penalties, IR meetings) via MCP tools.-
- AlicenseNot gradedqualityCmaintenanceProvides access to Hong Kong Monetary Authority public open data via MCP, enabling natural language queries without an API key.18 npmMIT

LuxAlgo Library MCPofficial
AlicenseAqualityAmaintenanceRead-only, keyless MCP server for searching and retrieving trading concepts, indicator details, families, and source code from the LuxAlgo Library.48387 npm16MIT