AutoRFP.ai is now an MCP server

A pattern has been showing up on customer calls. About once a week, somebody tells us a version of the same thing: “My team is already using Claude or ChatGPT every day. They’re pulling answers out of those tools and pasting them into our RFP responses. How do we make AutoRFP.ai part of that workflow instead of working around it?”

Today, that workflow exists. AutoRFP.ai is now available as a Model Context Protocol (MCP) server. If your team uses any MCP-compatible agent — Claude, ChatGPT, Cursor, Claude Code, Goose, or anything else — you can connect AutoRFP.ai directly to it and use your approved RFP content, projects, and tags as first-class context inside any chat.

This is the first MCP server purpose-built for RFP, DDQ, and security-questionnaire response teams. Here is what it does, why it matters, and how to get it running.

The problem we kept hearing

The shift from “AI for RFPs” to “agentic AI for RFPs” is happening faster than most teams expected. A year ago, the question was “can AI draft this answer.” Today, the question is “can my agent pull the context, draft the answer, check it against my codebase, polish it, and put it back in the right tool?”

What we’ve watched happen in the meantime is messier than the marketing makes it sound. Sales engineers and proposal managers have been quietly using Claude or ChatGPT on the side — to summarise long questionnaires, to rewrite stiff first drafts, to translate between security frameworks. They’ve been pasting answers out of AutoRFP.ai, polishing them in their AI tool with whatever connectors they have hooked up (Salesforce, Gong, Notion, the company wiki), and pasting the result back in. It works. It’s also slow, error-prone, and breaks the audit trail.

Worse, when teams reach for raw Claude or ChatGPT to generate answers, the trust problem shows up immediately. That failure mode is the same one that sinks most homegrown wrappers in a build vs buy for RFP software review. These are brilliant general-purpose models. They do not know your product’s specific security posture, your pricing tiers, your case studies, or the phrasing your win team has refined over hundreds of responses. They will confidently write answers that sound right and are subtly wrong, with no way to trace where the claim came from. For a question that ends up in a compliance audit, that is not a risk most teams want to carry.

So we built the bridge ourselves — once, against the open standard, so it works everywhere.

What the AutoRFP.ai MCP server does

The AutoRFP.ai MCP server exposes your AutoRFP.ai workspace as a set of tools any MCP-compatible agent can call directly. All seven tools in the initial release are read-only. None of them write to your workspace, modify projects, or send anything externally without your explicit action.

Here is the full toolset:

• search_content — Semantic search across your approved content library. Filter by tag.

• list_content — Enumerate your library by tag, file type, or date range.

• list_content_usage — Reverse-lookup which projects and requirements have reused a piece of content (auto-generated vs. manually inserted).

• list_projects — List your RFP, DDQ, and questionnaire projects. Filter by status, due date, or tag.

• get_project — Pull full project details: header, requirement status counts, applied tags.

• list_requirements — Paginated questions and answers within a project. Filter by status, tags, lastUpdatedBy, or whether an answer exists.

• list_tags — Discover your organisation’s full tag vocabulary so the agent can scope every other call correctly.

Three OAuth scopes govern access: tags:read, projects:read, and content:read. There is no write scope in this release. Your data is yours. The agent can read your approved content; it cannot delete, edit, or exfiltrate it.

What this means in practice

The point of the connector is not “ChatGPT or Claude can now write your RFPs.” If you want the best possible first-draft RFP response, you should still use AutoRFP.ai’s response engine directly — it is purpose-built on top of large language models with your approved content as the grounding layer, your Trust Scores attached to every sentence, and the collaboration workflows your team already uses.

The point is everything around the draft. Specifically:

Triage and prioritisation. “List all my open RFP projects due in the next 14 days, sorted by tag.” You get a triage view without leaving your inbox.

Content discovery. “Find me every approved response we’ve ever written about SOC 2 incident response, and show me which projects reused them.” A query that used to mean digging through three different tools is now one prompt.

Pre-sales prep. A solutions engineer prepping for a discovery call can ask their agent “summarise the security questionnaire from the Acme deal, then pull our approved answers from the last three FinServ DDQs we won.” The connector pulls the project, the answers, the reuse data. The SE walks into the call ready.

Cross-tool synthesis. This is the one customers have been asking for loudest. Pair AutoRFP.ai with your other MCP connectors — Salesforce, HubSpot, Gong, Linear, Notion, your code repository — and your agent can pull from all of them at once. “Cross-reference this RFP’s technical requirements with what engineering shipped last quarter from Linear, then draft a tailored answer using our approved library.” The audit trail stays intact, because every answer surfaced from AutoRFP.ai carries its Trust Score and source documents with it.

Win-loss analysis. Pull win themes from Grain call transcripts. Pull pricing detail from HubSpot. Pull the relevant past responses from AutoRFP.ai. Ask your agent to look across all three and find the patterns in your wins. This was a manual project. It is now a Tuesday afternoon.

Why trust still works

The hardest question we had to answer internally before shipping this was: how do we expose RFP content to a general-purpose agent without losing the trust guarantees that make AutoRFP.ai different from “just use ChatGPT”?

The answer is in the protocol. MCP responses carry structured metadata, not just text. Every piece of content the server returns includes its source identifier, its tags, and — crucially — the Trust Score AutoRFP.ai has already computed for it. When the agent uses an AutoRFP.ai answer in a response, the citation lineage is preserved. You can see which approved library item the answer came from, when it was last updated, and which projects have reused it before.

This is not the case when teams paste from ChatGPT or raw Claude. Those responses have no provenance, which is exactly when general AI tools fall short on RFPs. AutoRFP.ai-via-MCP has the same audit trail it has always had — it now just travels through one extra hop.

We also kept the connector read-only on purpose. The MCP spec lets servers expose destructive tools (creates, updates, deletes), and we will introduce write tools later for teams who want them. For launch, we wanted a connector any security team could approve without a long review. Read-only, narrow OAuth scopes, your existing AutoRFP.ai permissions enforced at the row level.

How to connect

Setup is two minutes per agent, and for MCP clients like ChatGPT and Cursor just point them at your region’s /mcp URL:

• US: https://api.us.autorfp.ai/mcp

• EU: https://api.eu.autorfp.ai/mcp

• AU: https://api.autorfp.ai/mcp

In Claude, AutoRFP.ai sits alongside your other connectors. Setting up Claude connectors for a bid team covers which to add first and what Claude can see through each.

Try it

The AutoRFP.ai MCP server is available now to all AutoRFP.ai customers on every plan. There is no additional cost.

If you are not yet an AutoRFP.ai customer — book a demo. We will walk you through the platform first, then show you what it looks like with an AI agent on top.