RFP Hub

@the-rfp-hub/mcp

A Model Context Protocol server for the RFPSear.ch — search Ethereum-ecosystem funding opportunities (grants, hackathons, bounties, accelerators, VC funds, RFPs) from any MCP client, and optionally submit one, with a human approval step that lives outside the tool channel. MIT licensed.

Search is anonymous: no credential, no account, nothing to configure beyond the client entry. A credential is needed only to submit, and only when submitting is explicitly turned on.

Submit from an agent

If the agent only needs to search and fetch, skip this section: install the server below with no credential. To let it submit:

1. Sign in to the deployment's API keys page — https://rfpsear.ch/keys for the hosted Hub, or /keys on a local or staging frontend. Its MCP card prepares the safe scopes below.
2. Choose read and write, leave publish off, and mint the key. This is the safe path: a submission is stored but waits for review instead of appearing immediately.
3. Copy the secret when it appears. It is shown once. The page also shows the exact API origin that belongs in RFPHUB_API_BASE.
4. Configure the client-neutral stdio connection below, then put the origin in RFPHUB_API_BASE and the secret in RFPHUB_API_KEY inside the client's private MCP environment. Never put the secret in a prompt, tool argument or shell command.
5. Restart the client. tools/list now includes submit_opportunity; its first call checks the key's scope and only previews, and a terminal approval is still required before a call writes.

The API keys page is the handoff: it creates the credential and links back here in a new tab, so the one-time secret remains visible while you configure the client.

Install

Client-neutral connection

RFPSear.ch MCP is model-provider and client agnostic. It is a local stdio server: the client launches one process, sends MCP messages on standard input and reads them on standard output. The server does not know which model, vendor or host launched it.

Every compatible client receives the same connection contract:

The names a client gives these fields may vary, but the process and environment do not. Prefer a user-private configuration or secret input; never commit the key to a repository. Restart the client after adding or rotating it.

The exact package version above is intentional. An npm version is immutable; @latest is not, and an MCP server is code your agent runs with your permissions. Pin it, and bump it deliberately.

Equivalent client examples

These are adapters for the same contract, not separate integrations. Omit the environment block for anonymous search and fetch.

Claude Code

claude mcp add --transport stdio rfp-hub -- npx -y @the-rfp-hub/mcp@0.1.4

project-scoped instead of user-scoped — writes .mcp.json in the repo

claude mcp add --scope project --transport stdio rfp-hub -- npx -y @the-rfp-hub/mcp@0.1.4

Those commands install anonymous search and fetch. For submission, add RFPHUB_API_BASE and RFPHUB_API_KEY to the server's private environment using Claude's local or user configuration; keep a shared project .mcp.json secret-free.

A project-scoped server (--scope project) shows as "Pending approval" until claude is run interactively once in that directory. Headless use — CI, scripts, claude -p — needs claude -p ... --mcp-config .mcp.json --strict-mcp-config to load it without that interactive step.

Claude Desktop and Cursor

Root key mcpServers, in claude_desktop_config.json or .cursor/mcp.json:

{

"mcpServers": { "rfp-hub": { "command": "npx", "args": ["-y", "@the-rfp-hub/mcp@0.1.4"], "env": { "RFPHUB_API_BASE": "https://api.rfpsear.ch", "RFPHUB_API_KEY": "rfph_…" } } } }

VS Code

Root key servers, in .vscode/mcp.json:

{

"servers": { "rfp-hub": { "type": "stdio", "command": "npx", "args": ["-y", "@the-rfp-hub/mcp@0.1.4"], "env": { "RFPHUB_API_BASE": "https://api.rfpsear.ch", "RFPHUB_API_KEY": "${input:rfphub-key}" } } }, "inputs": [ { "type": "promptString", "id": "rfphub-key", "description": "RFPSear.ch API key", "password": true } ] }

Codex CLI

codex mcp add rfp-hub -- npx -y @the-rfp-hub/mcp@0.1.4

That command installs anonymous search and fetch. For submission, edit ~/.codex/config.toml (or a trusted project's .codex/config.toml) and add the private environment table below to the server entry. Replace both values with the exact origin and one-time key shown by the API keys page, then restart Codex. This follows the official Codex MCP configuration.

[mcp_servers.rfp-hub]

command = "npx" args = ["-y", "@the-rfp-hub/mcp@0.1.4"]

[mcp_servers.rfp-hub.env] RFPHUB_API_BASE = "https://api.rfpsear.ch" RFPHUB_API_KEY = "rfph_…"

Companion skill

funding-search is a read-only agent skill that teaches a client how to use this server's search and fetch tools well. It is not shipped inside this npm package — it installs from the repository, through whichever of these channels your client supports:

npx skills add The-RFP-Hub/the-rfp-hub --skill funding-search

claude plugin marketplace add The-RFP-Hub/the-rfp-hub

Or copy the skill directory manually into .claude/skills/, .agents/skills/ (Codex), or .gemini/skills/.

Configuration

Two environment variables and one flag. A variable is for a secret — which must never sit on argv, where every process on the machine can read it — or for the identity of the deployment. Everything else is a flag or a fixed constant, so that running this server needs nothing from whoever administers your environment.

The per-request deadline is a fixed 20 seconds, headers and body together. It is not configurable: a deadline an operator can raise is a deadline a stalled destination can hold a tool call open behind.

RFPHUB_API_BASE is checked at startup, before any preview can exist, and four shapes are refused outright:

• plain `http:` for anything but `127.0.0.1`, `[::1]` or `localhost` — the write request carries a bearer credential, and a human approving an origin does not make cleartext safe;
• a username or password in the URL — it would end up in every diagnostic this server writes (no error message ever repeats the value of this variable, for the same reason);
• a path, query or fragment — the approval binds the *origin*, so two bases that differ only after the host would produce the same approval and reach different endpoints;
• anything that is not an absolute `http`/`https` URL.

https://api.rfpsear.ch, https://api.rfpsear.ch/, https://api.rfpsear.ch:443 and https://API.rfpsear.ch are one destination and produce one approval id. Port 444, or a different host, is a different destination and a different id.

Rotating the key means restarting the server. Configuration is read once, at startup, and the credential's fingerprint is one of the five things an approval binds to. A key swapped in the client's env block reaches this process only on its next start; until then previews are still bound to the old fingerprint, and a commit under the new one is refused as a mismatch. Restart before previewing under a new key.

The key goes in the client's `env` block. Never in a prompt, and never as a tool argument — there is no parameter on any tool through which one could be passed, and a test asserts that.

{

"mcpServers": { "rfp-hub": { "command": "npx", "args": ["-y", "@the-rfp-hub/mcp@0.1.4"], "env": { "RFPHUB_API_KEY": "rfph_…" } } } }

The key must carry write and must not carry publish, and this server checks that before its first submission. A publish key is refused, because an approved submission would go live at once.

Tools

search_opportunities *(read)*

Filters: q, fundingType[], status[], ecosystem[], category[], organization, minAward, maxAward, deadlineAfter, deadlineBefore, sort, order, page, limit (max 25). An unknown parameter is an error, never a filter that silently does nothing.

Each result row carries the id, namespace, title, funding type, status, operating organizations, ecosystems, a rendered award line, the next fixed deadline, and two link-out URLs.

It does not return `description` or `summary`. That is deliberate and it is the main safety property of this server: those are the longest free-text fields a publisher controls, they are where an instruction addressed to your agent would live, and twenty of them would dominate the context window. Ask for a full record by id when you actually need the prose.

fetch_opportunity *(read)*

One record in full, as an RFP Hub Standard document, inside an envelope of { notice, opportunity, links }. The document is structurally unmodified — no field removed, none added, no value changed — except that any value shaped like an API key is replaced with a redaction marker on every outbound message, this one included. Not byte-identical otherwise: it is parsed and re-serialized on the way through, so key order and whitespace are the transport's business.

submit_opportunity *(write — registered only when a key is configured)*

Two calls with a person in between. See the next section.

The submission result keeps the API's isListed value as an editorial preference and adds isPubliclyVisible as the actual visibility signal. A record is publicly visible only when reviewStatus is approved and isListed is true; a pending record with isListed: true still waits for review.

Submitting, and the approval step

1. call submit_opportunity { document }

→ checks the key's scope, validates locally, writes nothing, returns: { status: "pending", approvalId: "<64 hex>", preview: {...}, instruction: "..." }

1. a person runs, in their own terminal: npx @the-rfp-hub/mcp@0.1.4 approve → prints the destination, the credential fingerprint, the operation, the protocol revision and the whole document, then asks for confirmation

1. call submit_opportunity { document, approvalId } → claims the approval (single-use), POSTs, returns the result

rfphub-mcp pending lists what is waiting. rfphub-mcp revoke deletes one.

What the approval binds to

An approval is not merely "this document was approved". Its id is a hash over five things, and approve prints all five b