Skip to content

AGENTIC · MCP

Your bid workspace, readable by agents.

BidGlory runs a Model Context Protocol server with eight tools in two scopes: read and draft. Claude Code connects to it directly and Claude Desktop through the mcp-remote bridge. The assistant sees exactly what you see in BidGlory — and nothing it drafts reaches a bid until a person approves it.

8 tools
live in v1
2 scopes
read · draft
0 self-promotions
no approve_draft tool ships

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, logged, and gated by a person — 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. Everything an agent drafts waits on the Agent drafts page, 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

Eleven tools in the catalog, eight live, grouped by what they're allowed to touch.

The catalog is a contract. A published tool doesn't change shape — breaking changes go out as .v2, and the .v1 stays callable for at least 90 days after its replacement is generally available. The three Direct tools are listed so the contract is public; they refuse every call in this release.

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

On by default. Nothing an agent drafts touches the bid: lines and text wait on the Agent drafts page until a person approves or discards them.

  • bidglory.propose_bid_item.v1 Stage a line for a bid, with a preview of the new grand total. Approving it adds the line and recomputes the bid's totals in the same save.
  • bidglory.draft_proposal_section.v1 Stage a cover letter, scope of work or install notes. The reviewer sees it beside the text on the bid now; the bid is untouched until approval.
  • bidglory.list_pending_drafts.v1 Inspect what the agent (or anyone) has queued, by bid or provenance.

PHASE 3 · DIRECT

Direct writes — not available yet

Registered in the catalog and refused on every call in this release. A token cannot be granted Direct, and the three tools answer “not available in this release”.

  • 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 work inside the same rules your people do.

SCOPED TOKENS

Scoped tokens you make yourself

Each person makes their own tokens on Agent access: read is always on, draft is ticked by default. A token is shown once and stored only as a hash; it sees what its owner sees, and stops working when it's revoked, when it expires, or when the owner's password or access changes. Admins see and can revoke everyone's.

AUDIT TRAIL

Every call hits dbo.McpAuditLog

Tool name, token, a hash of the arguments (never the arguments themselves), the result and the timing — kept 90 days. Rate limits per token and per network address keep a runaway loop from flooding the bid.

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 — Approve lives only on the Agent drafts page, and we kept it that way on purpose. LLMs don't get to skip the review.

RECOMPUTE INVARIANT

An approved line is saved like any other line

When you approve a drafted line, it is built the way the bid page's own Add builds it and saved through the same repository path, which recomputes the bid's totals in the same save. No "fast path" SQL that would let cached totals drift from the line items.

VERSIONING

v1 stays callable for at least 90 days after v2

Once a tool signature is published, it doesn't change. Breaking changes ship as a .v2, and the original .v1 is removed no earlier than 90 days after the .v2 is generally available. Your agent scripts don't break unannounced.

WHAT THIS UNLOCKS

Three jobs to hand an assistant.

Monday pipeline review

Ask where every open bid stands, in plain English.

An assistant with a read-only view pages through bidglory.list_bids.v1 and calls bidglory.summarize_bid_status.v1 on each — stage, totals, what's ordered and installed, whether drafts are waiting. Read tools can't change anything, so nothing on a proposal moves.

From walkthrough notes to lines

Hand it your notes; review the lines it proposes.

Paste the site-walk notes into Claude. It looks up parts with bidglory.search_products.v1 and stages lines with bidglory.propose_bid_item.v1, each with a note saying why. You approve or discard each one on Agent drafts.

Scope text that matches the bid

A scope of work drafted from the lines that are actually there.

The assistant reads the bid with bidglory.get_bid.v1 and stages a scope with bidglory.draft_proposal_section.v1. You read it beside the text on the bid now, and the proposal changes only when you approve.

GET STARTED

One endpoint. A token. Two minutes.

The server answers JSON-RPC over MCP's Streamable HTTP transport at POST /mcp — for the hosted app, https://bidglory.net/mcp — one JSON response per request, with Authorization: Bearer bgmcp_…. Make the token under your name, top right → Agent access, and copy it straight away: it is shown once.

Claude Code

claude mcp add --transport http bidglory https://bidglory.net/mcp \
  --header "Authorization: Bearer bgmcp_…your token…"

Claude Desktop — claude_desktop_config.json, through mcp-remote

{
  "mcpServers": {
    "bidglory": {
      "command": "npx",
      "args": ["-y", "mcp-remote@<pinned version>", "https://bidglory.net/mcp",
               "--header", "Authorization:${BIDGLORY_AUTH}"],
      "env": { "BIDGLORY_AUTH": "Bearer bgmcp_…your token…" }
    }
  }
}

Claude Desktop's built-in custom connectors expect OAuth, which BidGlory doesn't offer yet — hence the bridge. Pin an mcp-remote version you have reviewed. Limits: 120 calls a minute per token, 20 draft calls a minute.

★ FREE 30-MINUTE DEMO

See an assistant draft on your bid.

On the demo we'll connect Claude to a sample BidGlory instance and walk a real round-trip: it proposes lines and a scope, and you approve them on Agent drafts.