Skip to main content
Glama

Quote a call

quote_call
Read-onlyIdempotent

Returns the rate-checker price for dialling a number or a country. No sign-in. Does not dial.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNo
currencyNoGBP, EUR, USD, or ILS. Omit for the rate-checker default.
destinationNoPhone number to price.
number_typeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still earns credit for adding two facts not in the annotations: no authentication is required ('No sign-in') and no call is placed ('Does not dial'), which directly answers the side-effect question for a quote tool.

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?

Two short sentences, front-loaded with what the tool returns and followed immediately by the two constraints that matter most (no sign-in, no dialling). Zero waste.

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?

For a simple, read-only, no-output-schema quote tool this is nearly complete: the return intent and the two key behavioral constraints are stated. The remaining gap is that it never clarifies the country-vs-destination relationship or how it differs from check_call_rate.

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

Parameters3/5

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

Schema coverage is 50%: currency and destination are described in the schema, while country and number_type are undocumented in both places. The description hints that a number OR a country can be supplied (suggesting alternative inputs) but adds no format, enum, or mutual-exclusion detail beyond that baseline hint.

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?

States a specific verb and resource ('returns the rate-checker price') plus the two things that can be priced (a number or a country). However, it does not distinguish itself from the very similar sibling check_call_rate, nor from quote_number, which is a real ambiguity for an agent choosing among rate tools.

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

Usage Guidelines3/5

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

'No sign-in. Does not dial.' implies this is a safe, non-authenticated pre-check operation, which is useful context. But there is no explicit when-to-use or when-to-use-an-alternative guidance, and the near-duplicate sibling check_call_rate is never addressed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.