Skip to content

AGENTIC · MCP

Your bid workspace, readable by agents.

BidGlory ships a Model Context Protocol server with 11 tools across three scopes. Claude Desktop, ChatGPT, VS Code Copilot, custom clients — any agent that speaks MCP can read bids, search the catalog, propose line items, and draft proposals through the same RBAC + audit trail your humans use.

11 / 11
v1 tools
3 scopes
read · draft · direct
0 self-promotions
no approve_draft tool ships
See it on your bid Tool catalog ↓
Replace

MCP handshake — agent connecting to BidGlory

/public/screens/shot-mcp-handshake.png

WHY THIS MATTERS

The boring 90% of a bid is the part agents are best at.

A typical integration shop spends most of an estimator's day on three tasks that don't actually require human judgment: hunting a part number in three vendor catalogs, copying line items from last month's similar job, and reconciling pricing against the latest manufacturer sheet. Tedious, error-prone, expensive in hours.

None of that needs an estimator. It needs a fast, careful executor with full access to the catalog and pricing engine. That's what an agent is. BidGlory's MCP server gives your agent that access — scoped, audited, reversible — so the estimator's day shifts to the 10% where they actually make the difference: choosing systems, tier strategy, judging labor estimates, closing the customer.

The hard rule: agents propose, humans dispose. Drafts ship through the same approval gate the in-app AI panel uses, and we deliberately do not ship an approve_draft tool. There is no MCP path from "agent wrote it" to "customer received it" without a human pressing the button.

TOOL CATALOG · v1

11 tools, grouped by what they're allowed to touch.

The catalog is a contract. Every tool here is immutable once shipped — breaking changes go out as .v2, with the prior version deprecated for at least 90 days before removal.

PHASE 1 · READ

Read-only

Granted automatically on every token. Safe by construction — no writes, no mutations.

  • bidglory.list_bids.v1 Filter and page through bids — by client, stage, sold date, total range.
  • bidglory.get_bid.v1 Full bid header + line items + client + computed totals.
  • bidglory.list_clients.v1 Page through clients with search by query / category.
  • bidglory.search_products.v1 Catalog lookup against Model / MFGNumber / Description / Features.
  • bidglory.summarize_bid_status.v1 Compact rollup — items, totals, last edit, draft-pending flag.

PHASE 2 · DRAFT

Drafts, awaiting approval

Granted by default. Writes land as drafts; a human in the UI is the only path to promote them to live data.

  • bidglory.propose_bid_item.v1 Add a draft line item. Routes through SaveBidItemAsync so totals recompute; tagged provenance=mcp until approved.
  • bidglory.draft_proposal_section.v1 Draft the cover letter / scope of work / install notes. AiDraftApprovedAtUtc stays NULL until the estimator approves.
  • bidglory.list_pending_drafts.v1 Inspect what the agent (or anyone) has queued, by bid or provenance.

PHASE 3 · DIRECT

Direct writes, explicit opt-in

Off by default. Must be granted per-token by an admin. Applies immediately — no draft step.

  • bidglory.create_bid.v1 New bid + optional starter items. Returns bidId + bidNumber so the agent can chain follow-up calls.
  • bidglory.update_bid_status.v1 Move a bid through its lifecycle — stage, probability, sold, abandoned, locked.
  • bidglory.create_client.v1 New client / org record.

Out of scope for v1: bidglory.approve_draft.* (approval is UI-only), bidglory.delete_* (destructive ops stay in the UI), portal-side client-facing tools (separate surface, separate auth model), and inventory mutations.

SAFETY MODEL

Agents answer to the same audit log your humans do.

SCOPED TOKENS

Three scopes, granted per token

Each UserMcpToken carries a grant matrix: read is automatic, draft is default, direct is explicit admin opt-in. Tokens revoke instantly and inherit the underlying user's RBAC role.

AUDIT TRAIL

Every call hits dbo.McpAuditLog

Tool name, token id, argument hash (not raw args — we don't want PII in the audit log), result kind, latency. Same audit surface as human edits, filterable by token id when you want only the agent's traffic.

NO SELF-PROMOTION

No approve_draft tool ships

An agent with the draft scope can propose line items and proposal sections. It cannot promote its own drafts to live data — that gate lives only in the UI, and we kept it that way on purpose. LLMs don't get to skip the review.

RECOMPUTE INVARIANT

Writes route through the same repository the UI uses

Every MCP write goes through BidGloryRepository, so RecomputeBidTotalsAsync always fires. No "fast path" SQL that would let cached totals drift. Whatever the agent does, the grand total stays consistent with the line items.

VERSIONING

v1 contracts are frozen for at least 90 days past deprecation

Once a tool signature is published, it's immutable. Breaking changes ship as a .v2. The original .v1 stays callable for at least 90 days after we announce its deprecation. Your agent scripts don't break unannounced.

WHAT THIS UNLOCKS

Three things your estimator stops doing.

Overnight catalog sweep

Friday-night pricing audit, on by itself.

Schedule an agent. It paginates bidglory.list_bids.v1 across every open bid, hits bidglory.search_products.v1 for each line, and emails you the diff where the upstream MFG price moved more than a threshold. Nothing changes on the customer-facing proposal — the read scope can't write.

Pre-staged bids

Show up Monday to a queue of drafts, not a blank grid.

A customer-facing intake form drops a new opportunity in. An agent with the default draft scope calls bidglory.propose_bid_item.v1 for each line it can resolve from the catalog, then bidglory.draft_proposal_section.v1 for a cover-letter sketch. You walk in, review, approve in the same UI you already use.

Buyer-side procurement

A customer's procurement agent reads the proposal so the human doesn't have to.

The customer points their own Claude / GPT at the share-token endpoint. The agent calls bidglory.summarize_bid_status.v1 against the read-only scope, lines the rollup up against their internal PO database, and tells the buyer what to expect on the invoice. Your team sees a normal portal session plus an extra row in the audit log noting the agent's User-Agent.

GET STARTED

Two transports. One catalog. A Bearer token.

The server speaks JSON-RPC over HTTP+SSE at /mcp for hosted clients, or stdio for sidecar / CLI use. Both transports expose the same tool catalog and the same auth model: Authorization: Bearer <UserMcpToken>.

claude_desktop_config.json — HTTP+SSE 

{
  "mcpServers": {
    "bidglory": {
      "url": "https://your-bidglory.example.com/mcp",
      "headers": {
        "Authorization": "Bearer bgmcp_…"
      }
    }
  }
}

smoke-test from the shell 

curl -N https://your-bidglory.example.com/mcp \
  -H "Authorization: Bearer $BG_MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"bidglory.list_bids.v1",
                 "arguments":{"limit":5}}}'

Tokens are issued in Settings → MCP tokens, scoped per user + role, and revocable instantly. Default-issued tokens carry read + draft. direct requires an admin to flip the bit explicitly.

★ FREE 30-MINUTE DEMO

See the MCP server respond on your bid.

On the demo we'll connect Claude to a sample BidGlory instance, walk through a real propose-bid-item → approve round-trip, and tail dbo.McpAuditLog beside it the whole time.

Book a free demo Browse features