Announcing Beacon: Self-improving memory for coding agents
← All MCP servers
MCP server

FinData MCP

mcp:sapph1re/findata-mcp

Stocks, fundamentals, FRED economics, SEC filings & crypto. x402 micropayments, $0.01/call.

Verdict
No issues found

Nothing found that works against the person who installs it.

Analyzed Oct 29, 2026, 16:10 UTC at 00bf88f

Dispute security verdict

If you believe this verdict is incorrect, submit a dispute and we'll review it.

0
findings
—
highest severity
0
threat classes
13
files scanned
74/74
checks satisfied
0
package advisories

Why this verdict

  • benign: 74 checks satisfied, nothing works against the installer of mcp-server:. (3 notes, 0 third-party flags)

Security findings 0

No security findings

Nothing found that works against the person who installs it.

Notes 3

Capabilities, vulnerabilities and disclosed behavior worth knowing. Nothing here works against the person who installs it, so notes never change the verdict.

Data exfiltration

mediumNoteConfirmed on reviewmedium confidence

Every tool call's parameters (tickers, CIKs, series IDs, coin IDs) are sent to the publisher's hosted Railway backend by default, which is the declared service; the host is overridable via FINDATA_BACKEND_URL, so this is disclosed data flow for the declared feature.

https://findata-mcp-production-1cd3.up.railway.app
Reviewer's reasoning

Tool parameters go to the publisher's own declared hosted backend, the documented service for this server, so this is disclosed data flow for the declared feature (test 5 carve-out). The URL is only a default and the host is operator-configurable.

Credential access

mediumNoteConfirmed on reviewmedium confidence

The server's launch configuration declares EVM_PRIVATE_KEY, the user's wallet private key, as a secret environment variable; the client uses it locally to sign x402 USDC payment authorizations sent to the publisher's own backend, so the key is an operator-supplied payment credential for the declared service.

EVM_PRIVATE_KEY
vector:metadata
Reviewer's reasoning

The client uses the wallet key only to build a local EIP-3009 signer and sends just the signed payment payload in the retry header, so the raw key is not transmitted to the backend. The declared use is an operator-supplied payment credential for the publisher's own service, which is a note under the carve-outs, and the claim's description is accurate.

Credential access

mediumNoteConfirmed on reviewmedium confidence

The Smithery manifest claims no API key is required, but the server requires the user's EVM_PRIVATE_KEY wallet key to pay per call; the claim misstates a note-level behavior and is harmless to the user only as a documentation mismatch.

no API key required.
vector:metadata
Reviewer's reasoning

The manifest's claim that no API key is required misstates the wallet-key payment requirement, but the misstated behavior is itself a note-level operator-supplied payment credential, so the false claim stays at note.