Skip to main content
Glama

Message a Business

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.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral detail: it returns min/max ranges when cost depends on channel or outcome, explicitly disclaims an accuracy percentage, and notes the tool is free. This goes well beyond the structured metadata.

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 front-loaded purpose, followed by examples, usage rules, and cost note. Every section earns its place; the content is detailed without being repetitive or bloated.

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

Completeness5/5

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

There is no output schema, so the description carries the burden of explaining return values. It covers the main return categories, exact vs. range behavior, the cost_range caveat, and the free nature of the tool. This is sufficient for an agent to decide whether to call the tool and what to expect.

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?

Schema description coverage is only 50%, and the description compensates with concrete examples showing how to pass 'operation' and 'params'. It demonstrates the shape for send_message and schedule_appointment, but it does not enumerate valid operation values, leaving some ambiguity.

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

Purpose5/5

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

The description states a specific verb ('Return an expected cost estimate, latency estimate, and success-probability estimate') and resource ('for a proposed call before execution'). It clearly distinguishes this preview tool from execution tools like send_message, and explains the exact vs. range behavior for prices.

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?

The description provides explicit WHEN TO USE ('before any operation... under a budget constraint') and WHEN NOT TO USE ('do not use in a hot loop... cache the result for at least 60 seconds'). It does not explicitly name an alternative tool, but the exclusion of hot-loop usage and the 'before execution' framing gives clear operational guidance.

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

All Message a Business 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.1/5.0
Disambiguation4/5

Most tools have clearly distinct roles: compliance preflight, messaging, transactional sends, directory lookup, conversation/status/outcome retrieval, cost preview, and health check. The main ambiguity is between send_message and send_transactional_confirmation, both of which can handle booking confirmations and transactional message types, though the descriptions do provide guardrails.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: check_compliance, find_business, get_conversation, get_outcome, get_status, preview_cost, send_message, verify_business. Even longer names like send_transactional_confirmation stay within the same convention. No mixed casing or inconsistent verb styles.

Tool Count5/5

10 tools is well-scoped for a business messaging platform. Each tool covers a distinct aspect: search/verify businesses, check compliance, send messages, preview costs, and inspect async results. The count is neither bloated nor thin for the stated purpose.

Completeness4/5

The core workflows are covered: find/verify a business, check compliance, send messages, retrieve conversations, and get operation outcomes. Minor gaps exist, such as no explicit tool for managing consent records and no webhook configuration tool, but agents can still complete primary messaging tasks without dead ends.

Resources