FineRx

email_savings_card

Email the free FineRx discount card to an address the person gave you.

Use ONLY after the person has given an email address AND confirmed they want the
card sent there — ask for both first, then set ``consent`` to true. The message
contains the card and nothing else; FineRx does not store the address.

Returns {"sent": true, "to": <masked address>} or {"sent": false, "error": ...}.
On an error, say what happened and offer the image or the link instead.

Do not call this without an explicit yes, do not guess or reuse an address, do
not retry a refusal, and do not read the full address back to the person.

Input Schema

TableJSON Schema

Name	Required	Default
`email`	Yes
`locale`	No	en
`consent`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 9, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The description goes beyond annotations by disclosing consent handling, privacy ('FineRx does not store the address'), message content ('contains the card and nothing else'), exact return shapes, and the masked address. These are behavioral details not inferable from annotations alone. The description aligns with annotations: readOnlyHint=false is consistent with sending an email, and no contradiction exists.

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?

Every sentence earns its place: purpose, consent precondition, privacy note, return contract, error fallback, and prohibitions. It is front-loaded with the main action and uses compact paragraphs without unnecessary elaboration. This is appropriately sized for a tool with meaningful side effects and safety constraints.

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?

The description is complete given the annotations and output schema presence. It covers the return contract, error behavior, consent prerequisite, privacy implications, and alternative delivery methods. The locale parameter is the only omission, but its default and optional role mean the agent can still invoke the tool correctly.

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?

With 0% schema description coverage, the description compensates well for the two key parameters: email ('address the person gave you', 'do not guess or reuse') and consent ('set consent to true' after asking). However, the locale parameter is never mentioned; its default 'en' and optionality make this a minor gap, so the score is 4 rather than 5.

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 opens with a specific verb and resource: 'Email the free FineRx discount card to an address the person gave you.' It clearly distinguishes emailing from sibling tools like get_savings_card by focusing on the delivery action and recipient. The fallback phrase 'offer the image or the link instead' further differentiates it from non-email retrieval paths.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance is present: 'Use ONLY after the person has given an email address AND confirmed they want the card sent there.' It also gives clear exclusions and prohibitions such as 'do not call this without an explicit yes, do not guess or reuse an address, do not retry a refusal.' Error-handling guidance tells the agent to offer the image or link instead, covering the alternative path.

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

All FineRx tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?