Hueri

Inspiration

Procurement opportunities are everywhere, but finding the right tender is often harder than finding a tender.

HUERI was built around a practical problem: environmental consultancies and other organizations need to continuously monitor procurement notices, understand whether an opportunity is relevant to their capabilities, and quickly decide what deserves attention.

We wanted to explore a different interaction model for that intelligence. Instead of making users search through another dashboard, could procurement intelligence become something an AI assistant can access and reason over through a standard protocol?

That led us to the Model Context Protocol (MCP).

What we built

HUERI is a tender-intelligence platform that collects procurement opportunities, stores tender information and recorded AI assessments, and exposes a read-only MCP server over Streamable HTTP.

For this hackathon, we built a voice-assistant-style interface that acts as a simulated Alexa+ client and communicates with the MCP server using real MCP protocol operations.

The assistant can discover and use three MCP tools:

• search_tenders — find procurement opportunities using filters such as query, source, score, fit, analysis state, and ordering.
• get_tender_details — retrieve the details of a specific tender.
• explain_tender_match — explain the stored AI assessment for why a tender was considered relevant.

The interaction can be multi-step. For example:

"Find environmental audit tenders."

The assistant discovers the available tools, searches the tender data, and presents the matching opportunity.

A follow-up such as:

"Explain the first one."

uses the result of the previous operation to call the explanation tool for that tender.

The routing is deliberately deterministic. There is no hidden LLM making arbitrary tool-selection decisions in the demo router. Follow-up calls depend on the results returned by the preceding operation.

Why MCP?

The interesting part of the project is not simply putting a chat interface in front of an API.

MCP gives an AI assistant a standardized way to discover capabilities and invoke tools. In HUERI, the client performs the actual MCP lifecycle:

initialize → notifications/initialized → tools/list → tools/call

The server advertises its tools and their input/output schemas rather than requiring the client to know HUERI's private API implementation.

This makes the tender intelligence available as a capability that an assistant can consume.

Security was a design requirement

Because procurement data comes from external sources and AI-generated assessments are not automatically trustworthy, the MCP service is explicitly read-only.

The demo uses a dedicated PostgreSQL role with restricted privileges. Our verification suite checks that the role:

• can read the tender and tender-analysis data it needs;
• cannot read users, notifications, or company profiles;
• cannot insert, update, or delete tender data;
• cannot create tables;
• cannot grant itself additional privileges;
• is not a PostgreSQL superuser, CREATEROLE, CREATEDB, or BYPASSRLS role;
• operates with default_transaction_read_only=on;
• has a five-second statement timeout.

The MCP server also treats tender text and stored AI analysis as untrusted information. They are reported as data rather than instructions for the assistant to follow.

The browser never receives the MCP bearer token; the demo backend keeps that credential server-side.

What was challenging

The hardest part was not making an endpoint respond to JSON.

We had to make the interaction conform to the MCP protocol while preserving the existing HUERI application and keeping the new service isolated from sensitive application functionality.

We also had to make failure behaviour explicit.

For example, tool discovery is visible in the demo trace, but a discovery failure should not prevent the requested operation from being attempted. We added regression tests for protocol errors, response-ID mismatches, malformed initialization responses, discovery failures, unexpected discovery exceptions, and accidental exposure of server error text.

The result is a demo where the protocol interaction can be inspected rather than merely claimed.

What we learned

We learned that making an application "AI-ready" is less about adding an AI chatbot and more about defining safe, explicit capabilities that an AI system can use.

MCP helped us separate those concerns:

HUERI owns the procurement intelligence.
The MCP server exposes controlled capabilities.
The assistant decides how those capabilities can be used.

We also learned that security boundaries need to be tested as executable properties. A database role being described as read-only is not enough; the demo actually attempts prohibited operations and verifies that PostgreSQL rejects them.

What's next

This hackathon implementation uses sample tender data and a simulated Alexa+ interface so that the complete MCP interaction can be demonstrated locally.

The underlying architecture is designed so the same MCP tools can sit in front of HUERI's real tender data.

The larger goal is to make procurement intelligence accessible through the interfaces people increasingly use to work with AI — while keeping the underlying data, permissions, and actions controlled.

Built With

• ai
• alexa+
• fastapi
• http
• intelligence
• mcp
• postgresql
• procurement
• python
• streamable
• tender
• uvicorn