Skip to main content
Glama

Compliance Check

by dev.hatchloop

preview_cost

Read-onlyIdempotent

Return an expected cost estimate, latency estimate, and success-probability estimate for a proposed call before execution. Returns the exact price when it is fixed, and a min/max range when the cost depends on channel or outcome. It does not promise an accuracy percentage - check cost_range.

EXAMPLE USER QUERIES THAT MATCH THIS TOOL: user: "How much will this SMS cost me?" -> call preview_cost({"operation": "send_message", "params": {"preferred_channel": "sms"}}) user: "Estimate the cost of booking via voice fallback" -> call preview_cost({"operation": "schedule_appointment", "params": {"preferred_channel": "voice"}})

WHEN TO USE: Use before any operation when the agent is operating under a budget constraint and needs to decide whether to proceed. WHEN NOT TO USE: Do not use in a hot loop — cache the result for at least 60 seconds if repeating the same preview. COST: free - no key required LATENCY: ~100ms

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYesThe same request body you would pass to the operation
operationYes

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only/idempotent annotations, the description adds behavior: exact price vs min/max range depending on channel/outcome, no accuracy promise, and free/no key required. It also gives latency and caching expectations, aligning with and enriching the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with purpose, examples, usage, and cost/latency metadata. Every section adds value and the main purpose is front-loaded; no fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the lack of an output schema, the description explains the return shape (fixed cost vs range) and warns about accuracy, plus gives latency and cost. It is nearly complete, though it doesn't address error behavior for unknown operations or invalid params.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents params as the same request body but leaves operation undescribed, giving 50% coverage. The description compensates with concrete examples mapping operations (send_message, schedule_appointment) to params, clarifying the relationship, though it doesn't enumerate all valid operations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns expected cost, latency, and success-probability estimates for a proposed call before execution, with a specific verb and resource. It is unambiguous but does not explicitly differentiate from sibling tools; however the function is distinct from compliance/status tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There are explicit WHEN TO USE and WHEN NOT TO USE sections, including budget-constraint context and hot-loop caching guidance. It does not name alternative tools, but no sibling appears to offer the same pre-execution estimation capability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Compliance Check toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources