GovToolsPro

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.4
Disambiguation5/5
Each tool has a clearly distinct purpose: market analysis, award pattern analysis, incumbent identification, partner finding, solicitation retrieval, labor rate lookup, NECO data lookup, recompete prediction, go/no-go scoring, and credit balance check. No two tools overlap in functionality.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., analyze_market, find_incumbents, get_solicitation, lookup_labor_rates). The only outlier is 'balance', which is a noun and could be renamed to 'get_balance' or 'check_balance' for consistency.
Tool Count5/5
10 tools is an appropriate number for a government contracting intelligence server. Each tool covers a specific analytical or data retrieval function without unnecessary duplication, and the scope is well-defined.
Completeness4/5
The tool set covers the main aspects of government contracting analysis: market overview, specific solicitation details, partner finding, labor rates, recompete opportunities, and decision support. A minor gap is the lack of a tool to search or list solicitations by keyword, as get_solicitation requires a known ID.
Average 4.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on June 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by stating data source (USAspending + FPDS) and cost (3 credits), which are beyond the annotations and provide useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and outputs, then state data source and cost. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 params, output schema exists), description covers purpose, outputs, data source, and cost. Could mention data recency or limitations, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides full descriptions for all 4 parameters (100% coverage). Description does not add parameter-specific semantics beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool analyzes award patterns for contracts in a NAICS, listing specific outputs (award-size distribution, competition mix, etc.). It distinguishes from siblings like analyze_market by narrowing to award patterns and listing typical metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when award pattern analysis is needed, but does not explicitly state when to use or avoid this tool versus siblings like analyze_market or find_incumbents. No alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it notes the tool is deterministic, free, and handles FPDS failures gracefully (USAspending data remains intact). This is useful for an agent understanding side effects and reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose and data sources, and every sentence provides valuable information. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple data sources, multiple outputs), the description covers purpose, outputs, data sources, and failure behavior. An output schema exists for return values, so additional detail is not critical. Lacks explicit prerequisites beyond NAICS (already in schema), but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description does not add additional parameter-level information beyond what the schema provides, but the schema is sufficient. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies likely current incumbent(s) for a solicitation using specified public data sources. It specifies the output (incumbent name, award value, period of performance, etc.), distinguishing it from sibling tools like get_solicitation or predict_recompete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding incumbents but does not explicitly state when to use this tool versus alternatives. It does not mention when not to use it or provide comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds value by disclosing the data sources (USAspending + Census) and the credit cost (5 credits). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with key content. Every sentence earns its place, providing a clear overview without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description sufficiently covers the tool's scope. It lists major output categories and capabilities, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add further meaning to the parameters beyond what the schema provides; it lists output components but does not clarify input semantics like NAICS format or PSC usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing a full market-intelligence snapshot for a NAICS code. It lists specific components (federal spending trend, industry size, top contractors, etc.) and distinguishes from siblings like analyze_award_patterns, which focuses on awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through its output scope (market snapshot, not awards), but it does not explicitly state when to use this tool vs alternatives like analyze_award_patterns or find_incumbents. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, open-world. The description adds value by stating it's free, that it exercises authentication end-to-end, and that the extension and API share the same credit pool. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the main purpose. No unnecessary words. Every sentence provides useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, annotations covering safety traits, and an output schema (not shown but exists), the description is complete. It explains what is returned and additional context about auth and credit pool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined (schema coverage 100% by default). With zero parameters, the baseline is 4. The description doesn't need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the credit balance and subscription status for the authenticated account. The verb 'Return' and resource 'credit balance and subscription status' are specific. Sibling tools like find_incumbents serve different purposes, so no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. It mentions exercising auth end-to-end and being free, but doesn't explicitly tell an agent when to select this tool over alternatives or in what context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds 'Deterministic, free' and 'Expiration/option signals reflect reported data and may lag,' providing extra context about behavior and data freshness beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Few sentences, front-loaded with main purpose, then details. No redundant phrases. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers source (USAspending), filter options, enrichment, return fields (days-until-expiration, urgency), and behavioral notes (deterministic, free, data lag). Completes the picture for a retrieval tool with nested filters and enrichment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the schema already explains all parameters. Description summarizes filter types but adds no significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool discovers expiring federal contracts as recompete opportunities, with specific filtering and enrichment options. Distinguishes from sibling tools like find_incumbents or get_solicitation by focusing on recompete detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing recompete opportunities, but no explicit guidance on when not to use or how it compares to siblings. Lacks exclusionary criteria or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral details: it specifies the output includes 'GSA CALC awarded ceiling rates (min/median/max by category) plus BLS OEWS wage data with a +55% government wrap estimate,' and notes the data is free and public. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, with the primary purpose in the first sentence. Every sentence adds value: what it does, what it returns, that it is free/public, and a usage tip. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail the return structure fully. It covers the key output components and data sources. It lacks mention of data freshness or limitations, but for a public-data lookup tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters having descriptions. The tool description does not add significant new meaning beyond the schema; it only restates that the tool works with NAICS code and/or labor category. Thus, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Benchmark federal labor rates for a NAICS code and/or a specific labor category,' which clearly specifies the verb (benchmark/lookup) and resource (federal labor rates). The tool name and description align, and the sibling tools (e.g., analyze_award_patterns, predict_recompete) are distinct, so differentiation is inherent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: it is for benchmarking federal labor rates using GSA CALC and BLS data, and advises to 'verify allowable rates against the RFP.' Although it does not explicitly state when not to use or name alternatives, the context is clear and sufficient given the absence of closely related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint) and adds value by explaining deterministic behaviour, detection logic for hard blockers, and output structure. No contradictions. However, it does not detail all possible edge cases or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences that front-load the purpose, then detail the logic and inputs. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (four parameters, nested objects, output schema present), the description adequately explains inputs and high-level output. It could mention that the output includes a numeric score and recommendations, but the output schema covers details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has detailed descriptions in the schema. The tool description does not add new information beyond summarizing the inputs; therefore it meets the baseline for high schema coverage without extra param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool scores a federal solicitation as GO/NO-GO (0-100) against a company profile, and lists specific capabilities like detecting hard blockers, scoring NAICS match, etc. This clearly distinguishes it from sibling tools such as find_incumbents or predict_recompete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool by stating it requires analyzed solicitation documents and a company profile. It mentions it is deterministic and free, but does not explicitly exclude alternatives or provide when-not-to-use guidance against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses deterministic, free nature, enrichment of top results, and the need for independent verification beyond annotations which already mark it as read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: first defines purpose and inputs, second details output and cautions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects (inputs, output format, limitations, verification need), and output schema handles return values, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema, and the description adds minimal extra meaning beyond restating the keyword and address roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it finds potential teaming partners/subcontractors near a solicitation's place of performance, distinguishing it from sibling tools like find_incumbents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly ties usage to solicitation context and provides caution to verify independently, but does not discuss when to avoid or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds 'Deterministic, free — pulls from SAM.gov's public opportunity records,' reinforcing idempotency and clarifying the public source. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core action and returning fields. No wasteful wording; every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With complete schema coverage, clear annotations, and a detailed output schema (not shown but known), the description fully covers the tool's purpose, parameters, and workflow integration. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by explaining the primary/favored status of noticeId and the best-effort fallback of solicitationNumber, beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single SAM.gov solicitation by notice ID or solicitation number, listing returned fields. It distinguishes itself from siblings by positioning as the workflow entry point and naming downstream tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (as the entry point for a workflow feeding into score_go_no_go, find_incumbents, or find_partners_near). Does not contrast with all siblings like balance or lookup_neco_data, but provides sufficient context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context: 'Deterministic scrape of the public neco.navy.mil site, free.' This extra detail about safety and cost is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste. It front-loads the action and key fields, then provides usage guidance and differentiation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but mentioned), the description need not detail return values. It covers input guidance, behavioral context (deterministic, free), and unique value proposition. With annotations and full schema coverage, no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 critical meaning: 'Primary, most robust input' for necoUrl, 'Best-effort' for solicitationNumber, and explains how hkey 'improves solicitationNumber resolution.' This exceeds the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Fetch and parse') and clearly identifies the resource ('Navy NECO solicitation page'). It lists the structured fields extracted and explicitly distinguishes itself from siblings by stating 'No other govcon MCP exposes NECO data.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Pass the full NECO URL when you have it (most reliable); solicitationNumber alone is best-effort.' It also mentions that the tool is deterministic and free. While it doesn't explicitly list when not to use alternatives, the sibling differentiation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![govtoolspro-mcp-server MCP server](https://glama.ai/mcp/servers/smythmyke/govtoolspro-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/smythmyke/govtoolspro-mcp-server)

Score Badge

Copy to your README.md:

[![govtoolspro-mcp-server MCP server](https://glama.ai/mcp/servers/smythmyke/govtoolspro-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/smythmyke/govtoolspro-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smythmyke/govtoolspro-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server