Samgov
Server Details
SAM.gov MCP — Federal contract opportunities and entity registration data
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-samgov
- GitHub Stars
- 0
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.1/5 across 15 of 15 tools scored. Lowest: 2.9/5.
Each tool has a clearly distinct purpose: ask_pipeworx for general queries, specific entity tools (resolve, profile, compare, changes), SAM contract tools, memory tools, and feedback. The only potential overlap is ask_pipeworx being a meta-tool, but it's designed to delegate, reducing ambiguity.
All tools use snake_case, but naming patterns vary: some are verb_noun (ask_pipeworx, compare_entities), others are noun_noun (entity_profile, sam_entity_search), and a few are lone verbs (forget, recall, remember). The sam_ prefix adds consistency within that subgroup, but overall the pattern is not perfectly uniform.
15 tools is within the ideal range and well-scoped for a server covering federal contracts and entity data. Each tool serves a necessary function without redundancy, and the count feels appropriate for the breadth of capabilities offered.
The tool surface covers the full lifecycle of entity lookup (resolve, profile, changes, compare) including SAM contracts (search, get, set-aside, entity search) and fact-checking. Memory and feedback tools round out the experience. No obvious gaps for the stated purpose.
Available Tools
15 toolsask_pipeworxAInspect
Answer a natural-language question by automatically picking the right data source. Use when a user asks "What is X?", "Look up Y", "Find Z", "Get the latest…", "How much…", and you don't want to figure out which Pipeworx pack/tool to call. Routes across SEC EDGAR, FRED, BLS, FDA, Census, ATTOM, USPTO, weather, news, crypto, stocks, and 300+ other sources. Pipeworx picks the right tool, fills arguments, returns the result. Examples: "What is the US trade deficit with China?", "Adverse events for ozempic", "Apple's latest 10-K", "Current unemployment rate".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool automatically selects the best data source and fills arguments, which is important behavioral information beyond the input schema. No annotations are provided, so the description carries full burden, and it does so well, though it could mention potential limitations or error cases.
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 with the core purpose, followed by examples. It avoids unnecessary details, though the examples are helpful but slightly verbose. Every sentence serves a purpose.
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 simple input (single string) and no output schema, the description adequately explains usage and behavior. It provides examples and sets expectations. Could be slightly more complete by mentioning that results may vary based on data source availability.
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?
The input schema has 100% coverage with a clear parameter description. The description adds context by explaining the parameter's purpose in natural language, but since schema coverage is high, the additional value is moderate. No contradictions or omissions.
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 accepts a plain English question and returns an answer from the best data source. It distinguishes itself from other tools by abstracting away the need to browse or select specific tools, emphasizing a single natural language interface.
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 advises users to simply describe what they need and provides concrete examples, effectively guiding usage. However, it does not explicitly mention when not to use this tool or alternative tools, which would be helpful given the presence of specialized siblings like sam_entity_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_entitiesAInspect
Compare 2–5 companies (or drugs) side by side in one call. Use when a user says "compare X and Y", "X vs Y", "how do X, Y, Z stack up", "which is bigger", or wants tables/rankings of revenue / net income / cash / debt across companies — or adverse events / approvals / trials across drugs. type="company": pulls revenue, net income, cash, long-term debt from SEC EDGAR/XBRL for tickers like AAPL, MSFT, GOOGL. type="drug": pulls adverse-event report counts (FAERS), FDA approval counts, active trial counts. Returns paired data + pipeworx:// citation URIs. Replaces 8–15 sequential agent calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| values | Yes | For company: 2–5 tickers/CIKs (e.g., ["AAPL","MSFT"]). For drug: 2–5 names (e.g., ["ozempic","mounjaro"]). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (paired data + URIs) and efficiency benefit (replaces 8-15 calls). No annotations provided, so description carries full burden; additional detail on behavioral traits would be beneficial.
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?
Three concise sentences with front-loaded purpose, no wasted words. Each sentence adds essential 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?
Covers input, output summary, and benefit. Without output schema, description provides reasonable completeness for expected use. Minor gap: no mention of error handling or edge cases.
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 covers both parameters with descriptions (100% coverage). Description enriches by providing concrete examples for both entity types (e.g., tickers/CIKs, drug names), adding value 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?
Description clearly states the tool compares 2-5 entities side by side, specifies supported types (company, drug) and metrics returned, and distinguishes from siblings by noting it replaces 8-15 sequential calls.
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 states when to use (comparing 2-5 entities) and what types are supported, but does not explicitly address when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Find tools by describing the data or task. Use when you need to browse, search, look up, or discover what tools exist for: SEC filings, financials, revenue, profit, FDA drugs, adverse events, FRED economic data, Census demographics, BLS jobs/unemployment/inflation, ATTOM real estate, ClinicalTrials, USPTO patents, weather, news, crypto, stocks. Returns the top-N most relevant tools with names + descriptions. Call this FIRST when you have many tools available and want to see the option set (not just one answer).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that the tool 'Returns the most relevant tools with names and descriptions', which is a useful behavioral trait. Since no annotations are provided, the description carries full burden for transparency. It could be improved by noting that the search is based on natural language and the number of results can be limited via the 'limit' parameter.
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 long, with the first sentence clearly stating the action, the second explaining the output, and the third providing usage guidance. Every sentence is valuable and there is no wasted text.
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 that the tool has a simple purpose (search a catalog) and the input schema is fully documented, the description covers everything an agent needs: what it does, how to use it, and when to use it. The lack of output schema is acceptable because the description states what is returned (tool names and descriptions).
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?
The input schema has 100% coverage, meaning both parameters (query and limit) have descriptions. The description does not add new parameter meaning beyond what the schema provides, so baseline 3 is appropriate. The description's examples of queries (e.g., 'analyze housing market trends') reinforce the schema's examples but don't add extra 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: searching a tool catalog by describing a need, and returning relevant tool names and descriptions. It also includes a specific use case ('Call this FIRST') which distinguishes it from sibling tools like 'ask_pipeworx' or 'sam_search_opportunities'.
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 'Call this FIRST when you have 500+ tools available and need to find the right ones for your task', providing clear guidance on when to use the tool. It implies that this tool is for discovery, not for executing tasks, which differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
entity_profileAInspect
Get everything about a company in one call. Use when a user asks "tell me about X", "give me a profile of Acme", "what do you know about Apple", "research Microsoft", "brief me on Tesla", or you'd otherwise need to call 10+ pack tools across SEC EDGAR, SEC XBRL, USPTO, news, and GLEIF. Returns recent SEC filings, latest revenue/net income/cash position fundamentals, USPTO patents matched by assignee, recent news mentions, and the LEI (legal entity identifier) — all with pipeworx:// citation URIs. Pass a ticker like "AAPL" or zero-padded CIK like "0000320193".
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today; person/place coming soon. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). Names not supported — use resolve_entity first if you only have a name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns citation URIs and bundles multiple data sources. It also mentions that federal contracts are excluded due to slowness. However, it does not discuss potential rate limits, authentication, or error handling.
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 but information-dense. It front-loads the purpose, lists key data sources, mentions the output format, and provides usage guidance—all in a few sentences. No wasted words.
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?
Without an output schema, the description explains the return type (citation URIs) lists specific data categories. It could be more detailed about the structure of the response, but given the complexity and the context of sibling tools, it is fairly complete.
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?
The input schema has 100% coverage with clear descriptions for both parameters. The description adds critical context beyond the schema: type only supports 'company', value accepts ticker or CIK (not names), and directs users to resolve_entity for names.
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 a full profile of an entity across multiple packs, listing specific data sources like SEC filings, XBRL data, USPTO patents, news, and LEI. It distinguishes itself from siblings by noting it replaces 10-15 sequential agent calls and directs to an alternative for federal contracts.
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 states when to use (for company profiles) and when not to (for federal contracts, use usa_recipient_profile). Also provides a prerequisite: use resolve_entity if only a name is available, as names are not supported directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetCInspect
Delete a previously stored memory by key. Use when context is stale, the task is done, or you want to clear sensitive data the agent saved earlier. Pair with remember and recall.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states the action is deletion but does not mention irreversibility, confirmation, or side effects. For a destructive operation, more transparency is needed.
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?
Single sentence, front-loaded verb, no wasted words. Efficiently conveys purpose.
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?
For a simple deletion tool with no output schema and no annotations, description is minimal. Lacks behavioral warnings (irreversible, permission requirements). Could mention that memory is permanently removed.
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% (1 param with description). Description adds no additional meaning beyond schema; baseline 3 applies.
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?
Description clearly states it deletes a stored memory by key, specifying the verb (delete), resource (stored memory), and parameter (key). Distinguishes from sibling tools like 'remember' (create) and 'recall' (retrieve).
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?
No guidance on when to use this tool versus alternatives. Implies deletion when memory should be removed, but doesn't specify conditions or warnings (e.g., irreversible action).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pipeworx_feedbackAInspect
Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | bug = something broke or returned wrong data. feature = a new tool or capability you wish existed. data_gap = data Pipeworx does not currently expose. praise = positive note. other = anything else. | |
| context | No | Optional structured context: which tool, pack, or vertical this relates to. | |
| message | Yes | Your feedback in plain text. Be specific (which tool, what error, what data was missing). 1-2 sentences typical, 2000 chars max. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it discloses a rate limit of 5 messages per identifier per day and implies that feedback is free. It also instructs on what to include, but does not mention any authentication or post-submission behavior.
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—five sentences covering purpose, usage, rate limits, and parameter hints—with no wasted words. Every sentence adds value.
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 or annotations, the description adequately covers purpose, usage guidelines, rate limiting, and parameter semantics. It does not need to explain return values for a simple feedback tool.
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%, but the description adds meaningful context beyond enum names and schema descriptions. For 'type', it explains each enum value's meaning, and for 'message' it advises specificity, length, and format.
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: 'Send feedback to the Pipeworx team.' and lists specific use cases (bug reports, feature requests, missing data, praise), distinguishing it from sibling tools like ask_pipeworx or discover_tools.
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 clear context on when to use (feedback scenarios) and explicit instructions (describe in terms of Pipeworx tools/data, no verbatim prompts). It also mentions the rate limit, though it doesn't explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a value previously saved via remember, or list all saved keys (omit the key argument). Use to look up context the agent stored earlier — the user's target ticker, an address, prior research notes — without re-deriving it from scratch. Scoped to your identifier (anonymous IP, BYO key hash, or account ID). Pair with remember to save, forget to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses that omitting key lists all memories and that memories persist across sessions. It does not mention performance, but for a simple key-value retrieval, this is sufficient.
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?
Two concise sentences, no wasted words. The purpose and usage are front-loaded, making it efficient for an agent to parse.
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 simplicity (1 optional param, no output schema), the description is complete. It explains both modes and the persistence context. The only minor gap is that it doesn't describe the format of the returned memory, but for a simple retrieval tool, this is acceptable.
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 explaining that omitting the key lists all memories, which is not obvious from the schema alone. This clarifies the behavior of the optional 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 verb 'Retrieve' and the resource 'stored memory', with two distinct modes: retrieval by key or listing all memories. It distinguishes itself from sibling tools like 'remember' (store) and 'forget' (delete) by focusing on retrieval.
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 explains when to use the tool ('to retrieve context you saved earlier') and implicitly differentiates from 'remember' and 'forget' by being the retrieval counterpart. It could explicitly mention not to use it for storing or deleting, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recent_changesAInspect
What's new with a company in the last N days/months? Use when a user asks "what's happening with X?", "any updates on Y?", "what changed recently at Acme?", "brief me on what happened with Microsoft this quarter", "news on Apple this month", or you're monitoring for changes. Fans out to SEC EDGAR (recent filings), GDELT (news mentions in window), and USPTO (patents granted) in parallel. since accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes + total_changes count + pipeworx:// citation URIs.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type. Only "company" supported today. | |
| since | Yes | Window start — ISO date ("2026-04-01") or relative ("7d", "30d", "3m", "1y"). Use "30d" or "1m" for typical monitoring. | |
| value | Yes | Ticker (e.g., "AAPL") or zero-padded CIK (e.g., "0000320193"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses the parallel fan-out to SEC EDGAR, GDELT, USPTO, the accepted 'since' formats, and the return structure (structured changes + count + URIs). It does not mention rate limits or authentication, but the core behavioral traits are transparent.
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, each earning its place: purpose, behavior for company, input/output details. No redundant words, front-loaded with the core action.
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 tool's complexity (parallel fan-out, multiple sources, two 'since' formats, no output schema), the description covers all essential aspects. An agent can correctly determine when and how to invoke it.
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% (all parameters have descriptions). The description adds meaningful context beyond schema: explains 'since' accepts ISO or relative strings with examples, 'value' can be ticker or CIK, and 'type' only supports 'company'. This elevates understanding.
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 ('What's new about an entity since a given point in time') and provides specific details on how it operates for 'company' type. It distinguishes itself from sibling tools like 'entity_profile' (static profile) and 'compare_entities' by focusing on change-monitoring.
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 gives explicit use cases ('brief me on what happened with X' or change-monitoring workflows) and provides example 'since' values. However, it does not explicitly state when not to use this tool or name alternative sibling tools, which would strengthen guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Save data the agent will need to reuse later — across this conversation or across sessions. Use when you discover something worth carrying forward (a resolved ticker, a target address, a user preference, a research subject) so you don't have to look it up again. Stored as a key-value pair scoped by your identifier. Authenticated users get persistent memory; anonymous sessions retain memory for 24 hours. Pair with recall to retrieve later, forget to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses persistence behavior: authenticated users get persistent memory, anonymous sessions last 24 hours. However, it doesn't mention any limits (e.g., max keys, size), side effects, or if overwriting is allowed.
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?
Two sentences covering purpose, use case, and persistence details. No wasted words, front-loaded with core action.
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?
For a simple key-value store with full schema coverage and no output schema, the description is sufficiently complete. It explains the value of use and persistence, though missing constraints like key format or size limits.
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 explaining the purpose of saving findings and preferences, and the key examples in the schema are descriptive. The description reinforces usage context, justifying a 4.
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 stores a key-value pair in session memory, specifying verb 'store', resource 'key-value pair', and context 'session memory'. It distinguishes from siblings like 'forget' and 'recall' by its purpose.
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 explains when to use this tool: to save intermediate findings, user preferences, or context across tool calls. It does not explicitly exclude scenarios or mention alternatives, but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAInspect
Look up the canonical/official identifier for a company or drug. Use when a user mentions a name and you need the CIK (for SEC), ticker (for stock data), RxCUI (for FDA), or LEI — the ID systems that other tools require as input. Examples: "Apple" → AAPL / CIK 0000320193, "Ozempic" → RxCUI 1991306 + ingredient + brand. Returns IDs plus pipeworx:// citation URIs. Use this BEFORE calling other tools that need official identifiers. Replaces 2–3 lookup calls.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Entity type: "company" or "drug". | |
| value | Yes | For company: ticker (AAPL), CIK (0000320193), or name. For drug: brand or generic name (e.g., "ozempic", "metformin"). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the output format (ticker, CIK, company name, resource URIs) and implies a read-only operation, but it does not explicitly state whether the tool modifies data, require authentication, or has rate limits. The description adds useful behavioral context beyond the schema but lacks completeness.
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 two sentences long, each sentence adds essential information: the core functionality and version details with examples. There is no fluff or repetition. It is front-loaded with the main action and efficiently conveys the tool's purpose.
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 tool has no output schema, the description partially compensates by listing return fields (ticker, CIK, company name, URIs). However, it does not mention error handling, edge cases (e.g., ambiguous names), or any side effects. For a simple lookup tool, it is adequate but could be more comprehensive.
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?
The input schema already provides 100% coverage with descriptions for both parameters. The description adds value by explaining the value parameter accepts ticker, CIK, or company name with examples, and notes that type currently only supports 'company'. This clarifies usage beyond the schema's enum and generic description.
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 resolves an entity to canonical IDs across Pipeworx data sources. It specifies the verb 'resolve', the resource 'entity', and provides concrete examples for type='company'. It also implies efficiency by stating 'Replaces 2–3 lookup calls', distinguishing it from alternative approaches.
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 context on when to use the tool (to resolve entities to canonical IDs) and mentions it replaces multiple lookup calls, but it does not explicitly state when not to use it or name alternative tools. Sibling tools like sam_entity_search might serve similar purposes, but no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sam_entity_searchAInspect
Search registered federal contractors by business name or UEI. Returns UEI, CAGE code, address, NAICS codes, small business status, and certifications.
| Name | Required | Description | Default |
|---|---|---|---|
| naics | No | Filter by primary NAICS code (optional) | |
| state | No | Filter by 2-letter US state code (e.g., "VA", "CA") | |
| _apiKey | Yes | SAM.gov API key | |
| business_name | Yes | Legal business name to search for | |
| small_business | No | Filter to only small business entities (optional) |
Output Schema
| Name | Required | Description |
|---|---|---|
| entities | Yes | |
| total_records | Yes | Total number of matching entities in SAM |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses the search scope (registered entities), data returned, and optional filters. Lacks details on API key handling or rate limits, but is sufficient for safe usage.
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?
Single sentence efficiently conveys purpose, scope, and output. No redundancy or unnecessary words.
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 lists returned fields. The tool has 5 parameters but schema covers all; description adds context for optional filters. Some behavioral details (pagination, result limits) missing but acceptable for a search tool.
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% with descriptions for each parameter. The description adds context by listing return fields and optional filters, which enhances meaning beyond the schema. No additional param details are necessary.
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 action (search), the target (registered entities in SAM.gov), and lists specific data returned (UEI, CAGE code, etc.). It distinguishes from sibling tools by focusing on entity search rather than opportunities or memory operations.
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 implies use when needing vendor/contractor data, and sibling tool names suggest alternatives for opportunities. However, no explicit when-not-to-use or alternative comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sam_get_opportunityAInspect
Get full details for a federal contract opportunity by solicitation number. Returns description, contact info, deadlines, attachments, NAICS codes, and set-aside status.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | SAM.gov API key | |
| solicitation_number | Yes | The solicitation number to look up (e.g., "W912DY-24-R-0001") |
Output Schema
| Name | Required | Description |
|---|---|---|
| type | No | Procurement type |
| title | No | Opportunity title |
| active | No | Active status indicator |
| office | No | Procuring office name |
| ui_link | No | URL to opportunity details on SAM.gov |
| sub_tier | No | Sub-tier agency code |
| set_aside | No | Small business set-aside type if applicable |
| department | No | Procuring department/agency |
| naics_code | No | Primary NAICS code |
| description | No | Full opportunity description |
| posted_date | No | Date opportunity was posted |
| archive_date | No | Archive date if applicable |
| archive_type | No | Archive type if applicable |
| resource_links | No | URLs to opportunity documents and resources |
| point_of_contact | No | List of points of contact for the opportunity |
| organization_type | No | Type of procuring organization |
| response_deadline | No | Proposal response deadline |
| classification_code | No | Classification code |
| solicitation_number | No | Unique solicitation identifier |
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 burden. It implies a read-only operation (getting details) without stating side effects, permissions, or error handling. The description adds context on returned data but does not disclose behaviors like potential API limits or data freshness.
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 a single, concise sentence that front-loads the key purpose and lists the returned data. Every word is necessary, and it avoids redundancy.
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 simple input (2 parameters, no nested objects, no output schema), the description is largely sufficient. It specifies the returned data fields, which is helpful. However, it could mention that the output may be empty if the solicitation number is invalid, but overall completeness is high.
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?
The input schema already describes both parameters with 100% coverage. The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 retrieves full details for a federal contract opportunity using a solicitation number, listing specific data fields (point of contact, attachments, classification, full description). The verb 'Get' and resource 'opportunity' are specific, and the tool's purpose is distinct from sibling tools like sam_search_opportunities (search) and sam_set_aside_opportunities (set-aside).
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 explains when to use it (to get full details by solicitation number) but does not mention when not to use it or compare to alternatives. Sibling tools like sam_search_opportunities suggest a different use case, but the description lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sam_search_opportunitiesAInspect
Search active federal contract opportunities by keyword, NAICS code (e.g., "541512"), set-aside type, posting date range, and procurement type. Returns titles, solicitation numbers, deadlines, and agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-100, default 10) | |
| naics | No | NAICS code to filter by (e.g., "541512" for computer systems design) | |
| ptype | No | Procurement type filter: p (presolicitation), o (solicitation), k (combined synopsis/solicitation), a (award notice) | |
| offset | No | Result offset for pagination (default 0) | |
| _apiKey | Yes | SAM.gov API key | |
| keyword | Yes | Search term for opportunity title or description | |
| posted_to | No | End of posting date range in MM/dd/yyyy format | |
| set_aside | No | Small business set-aside type: SBA (Small Business), SDVOSB (Service-Disabled Veteran), HUBZone, 8AN (8(a)), WOSB (Women-Owned), EDWOSB (Economically Disadvantaged Women-Owned) | |
| posted_from | No | Start of posting date range in MM/dd/yyyy format |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Number of results returned in this request |
| offset | Yes | Offset used for pagination |
| opportunities | Yes | |
| total_records | Yes | Total number of matching opportunities in SAM.gov |
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 clearly describes the tool as a search operation (non-destructive) and enumerates filter capabilities, which is sufficient for behavioral transparency. It does not contradict annotations.
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 a single, well-structured sentence that front-loads the main purpose and lists filters concisely. No wasted words.
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 tool's complexity (9 parameters, no output schema), the description adequately covers the search functionality and filters. It does not explain return values, but output schema is absent so that is a minor gap. It is sufficient for an agent to understand when to use it.
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%, so baseline is 3. The description lists filters (keyword, NAICS code, etc.) but does not add meaning beyond what the schema already provides for each parameter. It does not explain return format or pagination details.
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 searches active federal contract opportunities on SAM.gov and lists specific filters (keyword, NAICS code, set-aside type, posting date range, procurement type). It distinguishes itself from sibling tools like sam_entity_search (entity search) and sam_get_opportunity (single opportunity retrieval).
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 implies usage for searching opportunities but does not explicitly state when to use this tool vs alternatives like sam_get_opportunity or sam_set_aside_opportunities. There is no guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sam_set_aside_opportunitiesAInspect
Find federal contracts reserved for small businesses (women-owned, HUBZone, service-disabled veteran-owned, etc.). Returns titles, deadlines, and agencies.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return (1-100, default 10) | |
| naics | No | Optional NAICS code filter | |
| _apiKey | Yes | SAM.gov API key | |
| keyword | No | Optional keyword to narrow results | |
| set_aside | Yes | Set-aside type (required): SBA (Small Business), SDVOSB (Service-Disabled Veteran), HUBZone, 8AN (8(a)), WOSB (Women-Owned), EDWOSB (Economically Disadvantaged Women-Owned) |
Output Schema
| Name | Required | Description |
|---|---|---|
| limit | Yes | Number of results returned in this request |
| opportunities | Yes | |
| total_records | Yes | Total number of matching set-aside opportunities |
| set_aside_type | Yes | Set-aside type being searched |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly states it's a search/filter operation, implying read-only behavior. It doesn't mention any side effects or access requirements beyond the API key. No contradictions are present.
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 two sentences long, front-loads the key action and resource, and each sentence adds value. No unnecessary words.
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 tool's moderate complexity (5 parameters, no output schema), the description is adequate but could mention what the results contain (e.g., list of opportunity IDs) or how pagination works. The set_aside parameter's values are documented in the schema, which is sufficient.
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%, so the description adds no additional parameter information beyond what the schema already provides. The description's mention of 'small business set-aside type' aligns with the set_aside parameter but doesn't add new semantics. Baseline 3 is appropriate.
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 explicitly states the tool searches federal contract opportunities filtered by small business set-aside type. It specifies the purpose (finding reserved opportunities) and the resource (federal contract opportunities), which clearly distinguishes it from sibling tools like sam_search_opportunities.
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 notes the tool is useful for finding reserved opportunities, implying a use case. However, it does not provide explicit guidance on when not to use it or how it differs from sam_search_opportunities, which also searches opportunities. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_claimAInspect
Fact-check, verify, validate, or confirm/refute a natural-language factual claim or statement against authoritative sources. Use when an agent needs to check whether something a user said is true ("Is it true that…?", "Was X really…?", "Verify the claim that…", "Validate this statement…"). v1 supports company-financial claims (revenue, net income, cash position for public US companies) via SEC EDGAR + XBRL. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported), extracted structured form, actual value with pipeworx:// citation, and percent delta. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → numeric comparison).
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Natural-language factual claim, e.g., "Apple's FY2024 revenue was $400 billion" or "Microsoft made about $100B in profit last year". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully inform about behavior. It discloses output structure (verdict, extracted form, value with citation, delta) but omits details on failure modes, rate limits, or required authentication. The behavioral description is adequate but not rich.
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?
Two sentences cover purpose, scope, output, and value. Every word is necessary; no redundancy or filler.
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, no output schema, and no annotations, the description covers input domain, output verdicts, citation format, and efficiency benefit. Minor gap: no mention of handling unsupported claim types or error responses.
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%, so baseline 3 is appropriate. The description adds example claims but does not provide meaning beyond what the schema already provides for the single required 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?
Description specifies exactly what the tool does (fact-check a natural-language claim against authoritative sources), the domain (company-financial claims for public US companies), and the verdict types returned. This clearly distinguishes it from siblings like compare_entities or entity_profile.
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 explains that the tool replaces 4–6 sequential agent calls, indicating a usage context. However, it does not explicitly state when to avoid this tool or mention alternatives like ask_pipeworx for non-financial claims.
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!