Search U.S. federal contract opportunities and awards, then save searches and track pursuits.
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.
Average 3.7/5 across 10 of 10 tools scored.
Each tool targets a distinct resource and action: specific opportunities, comps, vendors, vendor awards, watch status, saved searches, and tracked opportunities. No two tools overlap in a way that would cause misselection.
All tool names follow a clear verb_noun pattern with consistent snake_case, such as get_opportunity, save_opportunity_search, and update_tracked_opportunity. Minor noun variations (e.g., saved_search vs opportunity_search) are domain-appropriate and do not break the pattern.
With 10 tools, the set is well-scoped for a government opportunity and vendor search service with account tracking features. Each tool serves a clear purpose without unnecessary redundancy.
The tool surface covers the core workflows: searching and fetching opportunities, viewing vendor data, managing saved searches, and tracking opportunities. Read operations are paired with appropriate save/update actions, and disable via update covers removal needs.
get_opportunityGet an opportunityAGet one SAM.gov opportunity by notice ID.
| Name | Required | Description | Default |
|---|---|---|---|
| notice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond the singular cardinality already evident from the name/title. It does not contradict the annotations but also does not disclose additional traits like return format or error 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 a single, front-loaded sentence of 9 words. Every word contributes to the purpose; there is no filler or 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?
For a simple get-by-ID tool, the description suffices: it names the action, resource, and lookup key. With rich annotations (readOnly, idempotent) and a minimal schema, the main omission is explicit mention of return value or error handling, but these are conventional for a getter and not critical for correct invocation.
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 0%, so the description must compensate. However, it merely restates the parameter name 'by notice ID' without adding format, provenance, constraints, or usage details beyond what the name implies. This provides little added meaning over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the resource ('SAM.gov opportunity'), and clarifies scope ('one' by 'notice ID'). This distinguishes it from sibling tools like search_opportunities or get_opportunity_comps, which operate on lists or comparisons.
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 phrase 'by notice ID' implies the tool should be used when a specific notice ID is known, and not for open-ended searches. However, it does not explicitly name alternatives or state when not to use it, leaving the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_opportunity_compsGet comparable public awardsAGet comparable public awards for one opportunity. These are historical ranges and counts, not win odds.
| Name | Required | Description | Default |
|---|---|---|---|
| notice_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds valuable context by stating the output is historical ranges/counts, not probabilities, which is not captured in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences. The first states the action and object; the second clarifies the data type. Every word earns its place with no 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?
For a simple read-only tool with one parameter and robust annotations, the description covers the essential return semantics and scope adequately. The lack of output schema is offset by the clear description of output being historical ranges and counts.
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 0%, so the description must compensate. It implies notice_id identifies the opportunity but does not explicitly define the parameter, leaving a minor gap for a single-parameter tool.
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 uses a specific verb and resource: 'Get comparable public awards' and adds scope 'for one opportunity.' It also distinguishes the tool's output from win odds, differentiating it from siblings like get_opportunity and get_vendor_awards.
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 clear context (benchmarking a single opportunity against historical comparables) and an explicit exclusion ('not win odds'), but it does not name alternative tools or provide explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vendorGet a vendorAGet a public vendor or awardee record by 12-character UEI.
| Name | Required | Description | Default |
|---|---|---|---|
| uei | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so safety is covered. The description adds that the record is public, but it does not describe return format or error conditions. For a simple get-by-ID tool, this 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?
The description is a single sentence of ten words, immediately communicating the essential action and input. There is 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?
For a low-complexity read operation with one parameter and comprehensive annotations, the description is nearly complete. It could state the return value more explicitly, but given the simple nature and sibling names, the behavior is predictable. A small gap remains.
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 specifies the 'uei' parameter with min/max length 12. The description repeats the length constraint ('12-character UEI') but does not explain what a UEI is or provide additional meaning, such as its format or source. Thus, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets a public vendor or awardee record using a 12-character UEI, giving a specific verb and resource. It is distinct from sibling tools like get_vendor_awards, which retrieve awards rather than vendor records.
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 you have a 12-character UEI and want the corresponding vendor/awardee record, but it does not explicitly mention alternatives or when not to use this tool. No comparison with sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vendor_awardsGet vendor awardsAGet public award history for one vendor UEI.
| Name | Required | Description | Default |
|---|---|---|---|
| uei | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that the history is 'public' and scoped to 'one vendor UEI', which is useful context but does not disclose behavior like pagination, rate limits, or result format. This is comparable to the get_calls example where the description added scope, warranting a 3.
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 action and resource. There is zero filler or redundant information, earning a perfect score for conciseness.
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?
This is a simple read-only tool with strong annotations, but the description lacks detail about the 'limit' parameter and does not describe the return shape (though no output schema exists). The one-liner is sufficient for basic understanding but leaves some gaps, such as how limit affects results and whether output is a list or paginated.
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?
With schema description coverage at 0%, the description must compensate. It explains 'uei' via 'one vendor UEI' but does not mention the 'limit' parameter or its meaning (e.g., controlling the number of awards returned). The schema provides type and constraints, but the description adds no value for 'limit', so parameter semantics are weak.
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 'Get public award history for one vendor UEI' clearly states the action (Get) and the resource (award history for a vendor by UEI). It is specific and distinguishes itself from sibling tools like get_opportunity or get_vendor by focusing on award history and the UEI identifier.
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 the tool is used to fetch award history for a single vendor UEI, but it does not explicitly state when to use it versus alternatives like get_vendor or search opportunities. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_watch_statusGet saved-search and pursuit statusARead the connected account saved searches and tracked pursuits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the 'connected account' context and clarifies the exact scope of data being read, which goes 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Read,' and contains no extraneous information. Every word contributes to understanding the tool's function.
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 simplicity (zero parameters, no output schema, rich annotations), the description adequately conveys what the tool does and what data it accesses. No missing information is apparent for this read-only status check.
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 tool has zero parameters, so the baseline of 4 applies. The description does not add parameter details, but none are necessary since the schema already fully covers the empty parameter set.
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 uses the specific verb 'Read' and names the exact resources 'saved searches and tracked pursuits,' making it distinct from sibling tools that retrieve individual opportunities or vendors. The tool's purpose is immediately clear.
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 is provided on when to use this tool versus alternatives like get_opportunity or search_opportunities. The description only states what it does, with no prerequisites, exclusions, or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_opportunity_searchSave an opportunity searchAInspectSave a federal opportunity search and choose its alert cadence.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| cadence | No | daily | |
| enabled | No | ||
| search_spec | Yes | ||
| delivery_channels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the core action (save) and cadence selection but does not disclose return format, required permissions, or potential errors. With annotations all false and providing no safety hints, the description carries the burden but falls short of explaining behavioral outcomes beyond the basic function.
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 one clear sentence with no wasted words. It is front-loaded with the main action and includes the key differentiator (cadence), making it highly efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a nested 'search_spec' object and multiple optional parameters, the description is too sparse to guide a correct call. It does not explain how to construct the search spec or what the response will be, nor does it position the tool within the workflow relative to 'search_opportunities' or 'update_saved_search'.
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 0%, so the description must compensate, but it only references 'search' and 'cadence' indirectly. It fails to explain the 'name', 'enabled', 'delivery_channels' parameters or the structure of the 'search_spec' nested object, providing minimal added value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a federal opportunity search and lets the user choose an alert cadence. The verb 'save' distinguishes it from the sibling 'update_saved_search', making the primary purpose unambiguous.
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 for creating a new saved search, but it does not explicitly say when to use this tool versus alternatives like 'update_saved_search' or 'search_opportunities'. No exclusions or contextual hints are provided, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_opportunitiesSearch federal contract opportunitiesASearch GovGazette public opportunity data using text, classification, buyer, location, status, and date filters.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| psc | No | ||
| sort | No | ||
| limit | No | ||
| naics | No | ||
| state | No | ||
| agency | No | ||
| cursor | No | ||
| status | No | ||
| set_aside | No | ||
| awardee_uei | No | ||
| notice_type | No | ||
| awardee_cage | No | ||
| posted_preset | No | ||
| deadline_preset | No | ||
| awarded_contractor_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds that data is 'public' but provides no further behavioral details such as pagination behavior, response shape, or filter combination semantics. With annotations present, the added value is minimal but not contradictory.
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, tightly written sentence that wastes no words. It communicates the essential purpose and main filter categories effectively, making it easy for an agent to parse quickly.
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 (16 optional parameters, no output schema), the description is under-specified. It omits critical operational details like pagination via cursor, limit defaults, sort behavior, or how filters combine. An agent would not know how to handle result sets or advanced filters, making the description insufficient for confident invocation.
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 0%, so the description must compensate. It groups parameters into conceptual filters (text, classification, buyer, location, status, date) but leaves many parameters (set_aside, notice_type, awardee_uei, awardee_cage, sort, limit, cursor, etc.) unaddressed. While the groupings help with primary use cases, the description is insufficient for the full 16-parameter surface.
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 resource ('GovGazette public opportunity data'), and the scope (filtering by text, classification, buyer, location, status, and date). This distinguishes it from sibling tools like get_opportunity, which retrieves a single record, and save_opportunity_search, which persists searches.
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 when to use the tool: when you need to search/filter opportunities across various criteria. It does not explicitly name alternatives or exclusions, but the verb 'Search' and filter list make the context clear, and sibling names (e.g., get_opportunity) suggest a single-record alternative. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
track_opportunityTrack an opportunityAAdd or replace one tracked opportunity and its next action in the connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| enabled | No | ||
| notice_id | Yes | ||
| next_action | No | ||
| alert_cadence | No | immediate | |
| pursuit_state | No | watching | |
| delivery_channels | No | ||
| source_profile_id | No | ||
| next_action_due_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a write operation (readOnlyHint false) and idempotent (idempotentHint true). The description adds the upsert behavior ('add or replace') and the account-scoped operation ('in the connected account'), which are valuable behavioral insights not present in the annotations. It doesn't disclose side effects like overwriting, but annotations cover destructiveHint, so 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?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core 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?
With 9 parameters, no output schema, and a minimal description, the tool lacks contextual completeness. It doesn't explain the semantics of key fields like pursuit_state or alert_cadence, nor what happens after tracking (e.g., notifications). The description provides the central purpose but not the operational context needed for accurate use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and 9 parameters. The description only references 'next action' (mapping to next_action) but leaves notes, enabled, alert_cadence, pursuit_state, delivery_channels, source_profile_id, and next_action_due_at unexplained. It does not compensate for the schema's lack of parameter descriptions, so semantic meaning for most fields is missing.
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 uses a specific verb phrase 'Add or replace' and a clear resource: 'one tracked opportunity and its next action.' This distinguishes it from read-only sibling tools (get_opportunity, get_watch_status) and from update_tracked_opportunity, which likely implies a different mutation behavior. The account scope 'in the connected account' adds further clarity.
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 creating or replacing a tracked opportunity, but it does not explicitly state when to use this tool versus update_tracked_opportunity or save_opportunity_search. There are no when-not-to-use conditions or alternative tool mentions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_saved_searchUpdate a saved searchBChange or disable a saved search in the connected GovGazette account.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes | ||
| cadence | No | daily | |
| enabled | No | ||
| search_spec | Yes | ||
| delivery_channels | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, non-destructive, idempotent operation, so the safety profile is covered. The description adds the ability to 'disable' a saved search, which clarifies one specific mutation behavior, but does not disclose other side effects such as how changes propagate or whether disabling affects notifications.
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 sentence that gets straight to the point with no unnecessary words, making it concise and well-structured.
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?
With six parameters including a nested search_spec object and no output schema, the description is too brief to provide a complete understanding. It omits essential details about parameter relationships, required fields, and the effect of updates, leaving significant gaps for a tool of this complexity.
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 0% description coverage, and the tool description does not explain any of the six parameters. While names like 'id' and 'name' are self-explanatory, the critical 'search_spec' object and the semantics of 'cadence', 'enabled', and 'delivery_channels' remain undefined, leaving the agent to guess.
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 modifies or disables an existing saved search, using the specific verbs 'change' and 'disable' for the 'saved search' resource. It distinguishes this from sibling tools like save_opportunity_search or update_tracked_opportunity by focusing specifically on saved searches in the connected GovGazette account.
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 the tool is used for modifying existing saved searches but provides no explicit guidance on when to use it over alternatives such as creating a new saved search. There are no when-to-use or when-not-to-use conditions, nor any mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_tracked_opportunityUpdate a tracked opportunityBChange or disable a tracked opportunity in the connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| enabled | No | ||
| notice_id | Yes | ||
| next_action | No | ||
| alert_cadence | No | immediate | |
| pursuit_state | No | watching | |
| delivery_channels | No | ||
| source_profile_id | No | ||
| next_action_due_at | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is a mutable operation (readOnlyHint=false, destructiveHint=false). The description adds that it can 'disable' (via the enabled parameter), which is beyond annotations. However, it does not disclose other behavioral aspects like whether changes are reversible, what triggers notifications, or whether it requires an existing tracked opportunity. This is moderate added value.
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 with no filler or redundant details. It efficiently communicates the core 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 tool with 9 optional parameters and no output schema, the description is too minimal. It does not explain what fields are changeable, what the required 'notice_id' represents, what 'disable' implies, or what the response will be. The agent is left with insufficient context to understand the full behavior of the update operation.
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 0% and there are 9 parameters. The description provides no meaning for any parameter beyond what the schema field names suggest. It does not explain 'notice_id', 'source_profile_id', 'pursuit_state', or other domain-specific concepts. The schema names are somewhat self-explanatory, but the description fails to compensate for the low coverage.
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 ('change or disable') and the resource ('a tracked opportunity'), and it distinguishes from siblings like track_opportunity (creation) and get_opportunity (read). The phrase 'in the connected account' adds context about scope.
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 is given on when to use this tool versus alternatives. It does not explicitly say 'use for existing tracked opportunities' or mention track_opportunity as the creation counterpart. The name implies update context, but the description lacks any exclusions or selection criteria.
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.
No comments yet. Be the first to start the discussion!
