Retrieve the final OutcomeReceipt for a completed operation.
WHEN TO USE: Use after get_status returns success/failure/partial to retrieve the full result with cost and reason codes. WHEN NOT TO USE: Do not use for operations still in pending/executing state — use get_status first. 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 cover readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond this: the response includes cost and reason codes, the operation must be completed, and it is free with ~50ms latency. This enriches the agent's understanding of what calling this tool entails.
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: purpose first, then explicit usage guidance, then cost and latency. Every sentence adds value and none is redundant with the schema or annotations.
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 one-parameter read tool with annotations covering safety, the description is nearly complete. It covers preconditions, sequencing, expected content (cost and reason codes), and performance characteristics. Minor gap: it doesn't elaborate on the OutcomeReceipt structure, but no output schema exists and the mention of cost and reason codes provides enough orientation.
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 zero description for operation_id. The description compensates by linking it to a completed operation from get_status, implying the ID comes from that prior call. Though it doesn't name the parameter explicitly, the context makes the parameter's role clear enough for correct invocation.
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 the final OutcomeReceipt for a completed operation, with a specific verb and resource. It distinguishes itself from get_status by focusing on the full result rather than the status, so an agent can immediately tell what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (after get_status returns success/failure/partial) and when not to use (pending/executing state), and names the alternative (get_status). This leaves no ambiguity about sequencing or conditions.
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.
Most tools target clearly distinct compliance subdomains: messaging compliance, sanctions screening, trade restrictions, company verification, and cost preview. The main overlap is between map_trade_restriction and screen_sanctions, since both screen parties against sanctions lists, but their descriptions differentiate trade-level screening from dedicated name screening well enough.
Tool names mostly follow a consistent snake_case verb_noun pattern: check_compliance, get_outcome, get_status, preview_cost, screen_sanctions, verify_company_record. self_test is the one minor deviation since it reads more like a noun than an imperative verb_object name, but it does not break the overall pattern.
Eight tools is a well-scoped size for a compliance pre-flight server. Each tool has a distinct role, and the count is neither bloated nor too thin for the apparent domain.
The core compliance workflows are covered: messaging pre-flight checks, sanctions screening, cross-border trade restrictions, company registry verification, and cost/status helpers. The main gaps are intentional exclusions like PEP screening, export-control product classification, and consent management, which are documented but prevent the set from being a fully comprehensive compliance suite.