Query the current state of any in-flight async operation by operation_id.
WHEN TO USE: Use to poll the state of a pending_async operation when no webhook callback has arrived or to check progress. WHEN NOT TO USE: Do not poll more frequently than once per 10 seconds — use webhook delivery for real-time updates instead. COST: free - no key required LATENCY: ~50ms
| Name | Required | Description | Default |
|---|---|---|---|
| operation_id | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context such as cost, latency, and the operational constraint not to poll more often than every 10 seconds. This goes beyond what the annotations provide without contradicting them.
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 compact and well-structured with labeled sections for usage, cost, and latency. Every sentence adds operational value, and the core purpose is front-loaded before the supplementary guidance.
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 single-parameter read-only tool with strong annotations, the description covers the essential invocation context: what to pass, why to poll, backoff advice, and cost/latency. It does not specify the exact response shape or possible status values, but no output schema exists and the operation semantics are reasonably inferable. A note distinguishing this from sibling get_outcome would improve completeness, but it is not a critical gap.
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 provides only the parameter name and type (string), with 0% description coverage. The tool description clarifies that operation_id identifies an async operation, but does not add format, source, or example details. Since there is only one parameter and its purpose is largely self-evident, this is adequate but not rich.
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?
States a precise verb ('Query'), resource ('current state of any in-flight async operation'), and key parameter ('by operation_id'). This clearly identifies what the tool does and distinguishes it from generic or unrelated sibling 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?
Provides explicit WHEN TO USE and WHEN NOT TO USE guidance, including polling vs. webhook delivery and a concrete 10-second rate limit. This is exactly the kind of decision-making context an agent needs to select and invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The three company-verification tools (verify_company_record, screen_sanctions, lookup_us_contracts) are clearly distinct by data source and purpose. get_status and get_outcome are the main potential confusion, but their lifecycle boundary (pending vs completed) is explicitly described.
Naming mixes multiple verb styles: get_outcome/get_status, lookup_us_contracts, preview_cost, screen_sanctions, self_test, verify_company_record. There is no consistent verb_noun or resource-oriented pattern across the set.
Seven tools is a reasonable count for a company-verification/due-diligence server. However, three of them (get_status, get_outcome, preview_cost) are generic infrastructure that feel bolted on rather than part of the core verification workflow.
The core verification surface covers company registry existence, sanctions screening, and US federal contracts, which addresses common due-diligence queries. The set is incomplete as a whole because get_status/get_outcome depend on async operations that no included tool can initiate, and preview_cost references operations unrelated to company verification.