PubSec Radar
Server Details
Federal sales intelligence: expiring-contract triggers, agency spend intel, deal qualification.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose covering different aspects of federal sales intelligence: agency spending profiles, expiring contracts, discovery questions, incumbent lookup, and deal qualification. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., agency_spend_profile, find_expiring_contracts). The verbs are descriptive and distinct, making the set predictable and easy to navigate.
Five tools is an ideal number for this domain. Each tool covers a critical step in the federal sales workflow without redundancy or unnecessary complexity. The scope is well-focused.
The set covers the core activities: analyzing spend, finding expiring contracts, generating questions, looking up incumbents, and qualifying deals. A minor gap is lack of direct competition analysis, but agents can infer this from existing tools.
Available Tools
5 toolsagency_spend_profileProfile a federal agency's contract spendingAInspect
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 one fiscal year. Good queries name one agency, e.g. agency="HHS". Figures come from a daily snapshot of USAspending covering the current fiscal year plus a 3-year trend; freshness is stated in the response. Federal only. Read the coverage caveats — current-FY totals are partial-year and intel-agency spend is never published.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency name, acronym, or code — e.g. "HHS", "Department of Veterans Affairs", "075". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully covers behavior: data source (USAspending snapshot), time coverage (current FY plus 3-year trend), freshness indicated in response, and limitations (partial-year, intel-agency not published). Not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with the core question, and each sentence delivers value without redundancy. Caveats are placed logically at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description adequately explains what the tool returns, its data sources, freshness, and limitations. No gaps remain for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage for the single parameter 'agency' with examples. Description adds slight context (e.g., one agency per query) but not significantly beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool answers 'what does this agency actually buy, and from whom?' and lists specific outputs (total obligations, 3-year trend, top vendors/NAICS). It distinguishes from siblings by focusing on a different aspect of contract spend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use 'before a first call' and 'Good queries name one agency', implying appropriate context. It includes caveats (Federal only, partial-year, intel-agency) but does not explicitly mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_expiring_contractsFind expiring federal contractsAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max contracts to return (top by obligated amount). Default 15. | |
| agency | Yes | Federal agency name, acronym, or code — e.g. "DHS", "Department of Defense", "070". Federal only; SLED is out of scope. | |
| naics_code | No | Optional NAICS code to narrow by category, e.g. "541512" (computer systems design). | |
| window_days | No | How far ahead to look for contract end dates, in days from today. Default 90, max 365. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately describes the output (incumbent vendor, dollar values, contracting office) and includes important caveats (data freshness, federal scope). However, it does not disclose potential failure modes (e.g., what happens if agency not found) or any rate limits. The behavioral traits are adequately but not exhaustively covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose and key triggers. Every sentence adds value—no wasted words. It is structured logically, starting with use case, then example, then caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description provides sufficient context for a list-type tool. It explains what the tool returns, its scope, and important caveats. It could mention the output format (e.g., JSON array) but overall it is complete enough for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing usage examples and clarifying the purpose of each parameter beyond the schema. For example, it explains that 'limit' returns top by obligated amount, and 'window_days' is how far ahead to look. This enhances the agent's understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding expiring federal contracts for sales triggers. It specifies the verb (find), the resource (expiring federal contracts), and the value (upcoming recompetes, displacing incumbents). It distinguishes from sibling tools like agency_spend_profile and incumbent_lookup by focusing on expiration dates and sales triggers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('when prospecting or prepping a federal account and you want sales triggers'). It provides an example query and clarifies scope ('Federal only (no state/local)'). It includes a caveat about data freshness. While it doesn't explicitly contrast with each sibling, the context makes it clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_discovery_questionsGenerate public-sector discovery questionsAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency the meeting is with — name, acronym, or code, e.g. "DHS". | |
| naics_code | No | Optional NAICS code for your category — adds questions about specific expiring contracts. | |
| meeting_context | No | What kind of meeting you are prepping for. | first_call |
| product_category | Yes | What you sell, in plain words — e.g. "data analytics platform", "zero-trust network security". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses data-backed questions with source URLs and outlines the contextual tuning (fiscal-year, FedRAMP/ATO). No side effects or limitations are mentioned, but the behavior is appropriate for a question generator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count and full schema coverage, the description adequately explains what the tool returns and how to use it. The optional naics_code is addressed, and the output is described as discovery questions with citations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds meaningful context beyond the schema, such as example usage and guidance on parameter values (e.g., 'Good queries name the agency...').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns discovery questions for public-sector selling, with specific attributes like fiscal-year timing and contract vehicles. It distinguishes from sibling tools that focus on spend profiles, contracts, or opportunity qualification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when prepping a meeting with a federal agency' and provides example queries. It advises adding naics_code for expiring contracts but does not directly contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
incumbent_lookupLook up an incumbent vendor's federal contractsAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max awards to return (largest first). Default 15. | |
| agency | No | Optional federal agency to scope the lookup, e.g. "DHS". Omit to search government-wide. | |
| vendor | Yes | Vendor/incumbent name as registered in federal awards, e.g. "Booz Allen Hamilton", "CACI". FPDS matches it as a phrase — shorter fragments match more. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the return includes awards with values and end dates, flags upcoming expirations, and mentions 'Federal only'. However, it omits data freshness, rate limits, auth requirements, and pagination, leaving gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the purpose, includes a concrete example, and provides necessary cautions without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns and flags an important caveat. It covers the primary use case and constraints, leaving little ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds example values and cautions about fragment matching but does not introduce meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: answering 'who am I displacing and when?' by returning incumbent vendor's current and recent awards with values and end dates. It uses a specific verb-resource combination and distinguishes from sibling tools which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (for displacement windows), gives example queries, and notes that zero results don't mean no presence. It doesn't explicitly compare to alternatives but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
qualify_opportunityQualify a federal opportunity (public-sector MEDDPICC)AInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Federal agency the deal is at — name, acronym, or code, e.g. "DHS". | |
| deal_facts | No | 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 | No | Competitor/incumbent vendor name if known — their real awards at this agency get pulled as evidence. | |
| product_category | Yes | What you are selling, e.g. "SIEM platform". | |
| estimated_value_usd | No | Rough deal size in USD, if known. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses behavioral traits: 'Scores measure evidence specificity, not truth' and explains that public-record evidence is automatically pulled when incumbent_vendor is named. It also notes that unknown fields can be left empty and gaps are output. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but every sentence provides useful information. It front-loads the main purpose and then details behavioral nuances and parameter usage. Could be slightly more concise, but no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested object, no output schema), the description is quite complete. It explains the scoring philosophy, the public-sector adaptations, and the automated evidence pulling. It mentions the output is a scorecard with gap-closing questions, compensating for missing output schema. The description could provide more explicit details on the scorecard format, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by explaining the MEDDPICC dimensions and their public-sector adaptations (e.g., 'budget authority instead of generic economic buyer'). It also clarifies that the deal_facts object can be omitted for pure-discovery scoring, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Use this to pressure-test a federal deal' and describes the output as a 'evidence-scored scorecard adapted for public sector'. It specifies the verb (qualify, pressure-test) and resource (federal opportunity). The sibling tools (e.g., agency_spend_profile, generate_discovery_questions) are distinct, so this tool stands out as the MEDDPICC scoring tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to pressure-test a federal deal' and explains that it returns gap-closing questions and public-record evidence, providing clear context for when to use it. However, it does not explicitly mention when not to use it or name alternatives, though the sibling tools are sufficiently differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!