Connector architecture
One MCP service, narrow tools, explicit scopes, and human approval for material actions.
Technical overview of the planned BidAgent remote MCP service, OAuth boundary, tool groups, tenant authorization, and safety controls.
Proposed read tools
The initial tool surface should expose bounded retrieval without leaking cross-tenant data or entire document corpora.
- search_opportunities
- get_pursuit
- get_analysis_status
- list_compliance_items
Proposed controlled actions
Write tools should be introduced only after read tools pass authentication, authorization, prompt-injection, schema, and evaluation tests.
- create_pursuit
- request_bid_analysis
- request_human_review
- update_compliance_item
Release gates
The endpoint is not represented as live until it has OAuth discovery, exact audience and scope enforcement, rate limits, structured output schemas, audit logging, and positive/negative tool-selection tests.
- OAuth and tenant isolation
- MCP Inspector coverage
- Human-confirmation behavior
Frequently asked questions
What will the BidAgent MCP URL be?
The intended canonical path is /mcp on the BidAgent custom domain. It is not published as an active endpoint during the current public pre-beta.
Why not expose the database directly?
Direct database access would bypass business rules, tenant authorization, audit controls, and safe tool boundaries. Connectors should call narrowly scoped application tools.