_ registry / mcp http-sse · checked 47m ago

pubsec-sales

https://pubsec-sales-mcp.kabrawala.workers.dev

Registry code: dff4c66754225aff

api record

Federal sales intelligence: expiring-contract triggers, agency spend intel, deal qualification.

from a public catalogue that lists it, not from the operator

endpoint
https://pubsec-sales-mcp.kabrawala.workers.dev/mcp
protocol
http-sse ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is pubsec-sales live?
Yes — it answered the hub's last check (checked 47m ago). It answered 100% of checks over the last 30 days.
Is pubsec-sales free to use?
Yes — the hub reached it with no key and no payment.
What tools does pubsec-sales have?
5 tools: agency_spend_profile, generate_discovery_questions, qualify_opportunity, find_expiring_contracts, incumbent_lookup.
Is pubsec-sales safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
100%

90 days 100%· all time 100%

latency
507ms

last good check

priced tools
0

of 5 tools

_ answered our checks, 90 days 308 checks · signed record
  • unknown → live
_ what it is for
used for
  • find expiring federal contracts
  • profile an agency's spending
  • look up an incumbent vendor
  • qualify a federal deal
  • generate discovery questions
takes → gives
text → text, data
tools
5 reads
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

inferred, not observed

Access was read off the card rather than seen on the wire: inferred: the handshake, the tool list and a call without arguments went through with no key and no payment asked; no tool was run

_ what it can do 5 tools
5 never probed 0 of 5 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • agency_spend_profile reads unknown never probed

    Use this to answer "what does this agency actually buy, and from whom?" before a first call: total contract obligations, 3-year trend, top 10 vendors, and top 10 NAICS categories for the latest fiscal year with published data. Good queries name one agency, e.g. agency="HHS". Figures come from a daily snapshot of USAspending (latest published fiscal year plus a 3-year trend); the fiscal year and freshness are stated in the response. Federal only. Read the coverage caveats — in-progress fiscal years are partial, and intel-agency spend is never published.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "agency"
      ],
      "properties": {
        "agency": {
          "type": "string",
          "description": "Federal agency name, acronym, or code — e.g. \"HHS\", \"Department of Veterans Affairs\", \"075\"."
        }
      }
    }
    arguments 13 lines
  • generate_discovery_questions reads unknown never probed

    Use this when prepping a meeting with a federal agency: it returns discovery questions tuned to public-sector selling (fiscal-year timing, contract vehicles, FedRAMP/ATO, incumbents), grounded in the agency's live spending data where possible — each data-backed question cites the number that motivated it with a source URL. Good queries name the agency, what you sell, and the meeting type, e.g. agency="DHS", product_category="zero-trust network security", meeting_context="first_call". Add naics_code to surface expiring-contract questions.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "agency",
        "product_category"
      ],
      "properties": {
        "agency": {
          "type": "string",
          "description": "Federal agency the meeting is with — name, acronym, or code, e.g. \"DHS\"."
        },
        "naics_code": {
          "type": "string",
          "pattern": "^\\d{2,6}$",
          "description": "Optional NAICS code for your category — adds questions about specific expiring contracts."
        },
        "meeting_context": {
          "enum": [
            "first_call",
            "technical_deep_dive",
            "procurement_discussion"
          ],
          "type": "string",
          "default": "first_call",
          "description": "What kind of meeting you are prepping for."
        },
        "product_category": {
          "type": "string",
          "minLength": 3,
          "description": "What you sell, in plain words — e.g. \"data analytics platform\", \"zero-trust network security\"."
        }
      }
    }
    arguments 34 lines
  • qualify_opportunity reads unknown never probed

    Use this to pressure-test a federal deal: pass what you know per MEDDPICC dimension (leave unknowns empty) and get back an evidence-scored scorecard adapted for public sector — budget authority instead of generic economic buyer, procurement vehicle as the paper process — with gap-closing questions and public-record evidence pulled automatically (name the incumbent_vendor and their real awards/end dates at the agency get attached). Scores measure evidence specificity, not truth; the response says what verified evidence looks like for each dimension.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "agency",
        "product_category"
      ],
      "properties": {
        "agency": {
          "type": "string",
          "description": "Federal agency the deal is at — name, acronym, or code, e.g. \"DHS\"."
        },
        "deal_facts": {
          "type": "object",
          "properties": {
            "metrics": {
              "type": "string",
              "description": "Quantified mission outcome the buyer expects (their numbers, not your pitch)."
            },
            "champion": {
              "type": "string",
              "description": "Who sells for you internally — name, role, what they've done for you so far."
            },
            "competition": {
              "type": "string",
              "description": "Who else is in — incumbent, other bidders, or internal do-nothing option."
            },
            "paper_process": {
              "type": "string",
              "description": "Procurement path — vehicle, contract type, contracting office, ceiling."
            },
            "economic_buyer": {
              "type": "string",
              "description": "Who has budget/obligation authority — name, role, what they've said."
            },
            "identified_pain": {
              "type": "string",
              "description": "The forcing function — mandate, audit finding, incident, failed program."
            },
            "decision_process": {
              "type": "string",
              "description": "Steps and dates to award — RFI, evaluation, decision milestones."
            },
            "decision_criteria": {
              "type": "string",
              "description": "How they'll evaluate — technical factors, past performance, price weighting."
            }
          },
          "description": "What you know so far, one field per MEDDPICC dimension. Omit entirely (or leave fields empty) for pure-discovery scoring — gaps are the output."
        },
        "incumbent_vendor": {
          "type": "string",
          "description": "Competitor/incumbent vendor name if known — their real awards at this agency get pulled as evidence."
        },
        "product_category": {
          "type": "string",
          "minLength": 3,
          "description": "What you are selling, e.g. \"SIEM platform\"."
        },
        "estimated_value_usd": {
          "type": "number",
          "description": "Rough deal size in USD, if known.",
          "exclusiveMinimum": 0
        }
      }
    }
    arguments 66 lines
  • find_expiring_contracts reads unknown 15h ago

    Use this when prospecting or prepping a federal account and you want sales triggers: contracts at an agency that end soon, with the incumbent vendor, dollar values, and contracting office. Expiring contracts mean upcoming recompetes — the best time to displace an incumbent. Good queries name one agency and optionally a NAICS code, e.g. agency="DHS", naics_code="541512", window_days=90. Federal only (no state/local). Every response includes data-freshness and coverage caveats — read them; no data ≠ no spend.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "agency"
      ],
      "properties": {
        "limit": {
          "type": "integer",
          "default": 15,
          "maximum": 25,
          "minimum": 1,
          "description": "Max contracts to return (top by obligated amount). Default 15."
        },
        "agency": {
          "type": "string",
          "description": "Federal agency name, acronym, or code — e.g. \"DHS\", \"Department of Defense\", \"070\". Federal only; SLED is out of scope."
        },
        "naics_code": {
          "type": "string",
          "pattern": "^\\d{2,6}$",
          "description": "Optional NAICS code to narrow by category, e.g. \"541512\" (computer systems design)."
        },
        "window_days": {
          "type": "integer",
          "default": 90,
          "maximum": 365,
          "minimum": 1,
          "description": "How far ahead to look for contract end dates, in days from today. Default 90, max 365."
        }
      }
    }
    arguments 32 lines
  • incumbent_lookup reads unknown 15h ago

    Use this to answer "who am I displacing and when?": a vendor name (plus optional agency scope) returns their current and recent awards with values and end dates, flagging awards that end within 12 months as displacement windows. Good queries use the vendor's registered name or a distinctive fragment, e.g. vendor="Booz Allen", agency="DHS". Federal only. Zero results ≠ no presence — check the caveats for name-matching tips.

    mcp-tool

    {
      "type": "object",
      "$schema": "http://json-schema.org/draft-07/schema#",
      "required": [
        "vendor"
      ],
      "properties": {
        "limit": {
          "type": "integer",
          "default": 15,
          "maximum": 25,
          "minimum": 1,
          "description": "Max awards to return (largest first). Default 15."
        },
        "agency": {
          "type": "string",
          "description": "Optional federal agency to scope the lookup, e.g. \"DHS\". Omit to search government-wide."
        },
        "vendor": {
          "type": "string",
          "minLength": 2,
          "description": "Vendor/incumbent name as registered in federal awards, e.g. \"Booz Allen Hamilton\", \"CACI\". FPDS matches it as a phrase — shorter fragments match more."
        }
      }
    }
    arguments 25 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id dff4c66754225aff.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/dff4c66754225aff/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/dff4c66754225aff/badge.svg)](https://brick.blue/agent/dff4c66754225aff?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
90%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.