Using MCP for procurement research: keep the evidence attached

I build BidSkim, a service that matches UK suppliers to public-sector contracts. One useful way to work with procurement data is to query it through an AI assistant. The difficult part is keeping the evidence visible when the assistant turns a structured record into a confident sentence.

A contract ending in six months is a reason to investigate. It does not prove that the buyer will run a new tender on that date. A published award value is also different from money actually paid to the supplier. Those distinctions should survive every step from retrieval to the final answer.

Start with a research question

A useful request contains the work, geography and time window:

Find IT support contracts in Yorkshire that are approaching their recorded end date in the next six months. Show the buyer, incumbent, source notice and the evidence for the date. Put confirmed live tenders in a separate table.

That gives the assistant something testable to retrieve. It also prevents a list of historical awards from being presented as a list of opportunities that are open for bidding.

Preserve three layers

Keep the published fact, the inference and the missing information separate. For example, this is an illustrative response shape, not BidSkim's API schema:

{
  "published_fact": {
    "contract_end_date": "2027-03-31",
    "source_url": "<official notice URL>"
  },
  "inference": {
    "label": "Potential renewal to investigate",
    "reason": "Recorded end date falls within the research window"
  },
  "unknowns": [
    "Whether an extension will be exercised",
    "Whether a replacement tender will be published"
  ]
}

The date above is fictional. The point is the separation. If a field is missing, return it as missing. Do not ask the model to fill gaps from what usually happens in that industry.

Treat matching as qualification

A notice can describe the right service and still be unsuitable. The delivery region, minimum qualifications, contract size and deadline can each rule it out. Ask for a short reason for every suggested match, including the requirement that needs checking. A similarity score is useful for sorting; the original notice determines whether the supplier can bid.

A good results table has columns for the opportunity, why it fits, what could disqualify it and the source. It should be possible to verify one row without repeating the whole conversation.

Keep research tools read-only

A research assistant needs to search and retrieve records before it needs permission to change anything. BidSkim's MCP connection is read-only and includes tender search, renewal research, buyer and supplier profiles, and account pipeline queries. Access follows the account's plan; MCP is included with Predict.

For a first check, ask the assistant for one result and open its source. Then widen the search. If the result is a renewal signal, verify the contract dates and any extension wording before acting on it.

Check the output against the source

Before relying on a shortlist, check that the live notices are still open, the deadline was copied correctly, and any renewal estimate is labelled as an estimate. Keep the notice links alongside the answer when exporting it.

Connecting an assistant to real records makes research more useful. Keeping the distinction between evidence and inference makes that research easier to trust.