Skip to main content
Glama

Legacy

Price a gift

quote
Read-onlyIdempotent

What a gift to these charities comes to: what the donor pays, the payment processing fee, each charity’s share and, if asked, the Gift Aid they could claim. The donor chooses Gift Aid and any tip at checkout, so these are assumptions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
giftAidNoWhether to show Gift Aid, which only a UK taxpayer can add
charitiesYes
tipPercentageNoAn optional tip to Legacy, taken from the gift

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
giftAidYes
charitiesYes
donorPaysYes
platformTipYes
maximumTotalYes
minimumTotalYes
charitiesReceiveYes
minimumPerCharityYes
paymentProcessingYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish it is read-only, idempotent, non-destructive, and closed-world. The description adds valuable context about what it returns (donor cost, fees, charity shares, optional Gift Aid) and notes the assumptions around Gift Aid/tip. It does not discuss rate limits or authentication, but for a safe read operation that additional context is appropriate.

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

Conciseness4/5

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

The description is brief and front-loads what the calculation yields. It is slightly conversational but no sentence is wasteful; the assumptions note earns its place.

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?

The tool has an output schema and rich annotations, so the description needn't explain return formats or safety. It does cover the main outputs and the Gift Aid/tip assumption, making it mostly complete for the tool, though sibling routing could be clearer.

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 67%, and the schema itself already documents Gift Aid, charityNumber, amount, and tipPercentage in detail with examples. The description mentions Gift Aid and tips only at a high level, adding little parameter meaning beyond what the schema provides. Baseline 3 is appropriate.

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 this is a pricing/quote tool that breaks down donor cost, fees, charity shares, and Gift Aid. It does not explicitly contrast itself with siblings like check_charities or create_checkout_link, so it misses the top score for sibling differentiation.

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?

Usage is implied (you invoke it to get price breakdowns), but the description offers no explicit when-to-use, when-not-to-use, or alternative-tool guidance. It does not tell the agent how this relates to check_charities or create_checkout_link.

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.

Resources