Wraps

Estimate Wraps + AWS cost

estimate_cost

Read-only

Estimate the real monthly cost of running email on Wraps + AWS: the flat Wraps platform fee for the plan, and the itemized AWS bill (SES, EventBridge, SQS, Lambda, DynamoDB, dedicated IP, WAF). The Wraps fee never varies with volume; the AWS-side event-pipeline line items (EventBridge, SQS, Lambda, DynamoDB) are derived from emails sent and event types per email. The events parameter is accepted for backward compatibility and does not currently affect the estimate. Use this instead of doing the arithmetic — six variables interact, including which SES pricing plan the AWS account is on.

Input Schema

TableJSON Schema

Name	Required	Description
`tier`	No	Wraps plan.
`emails`	Yes	Emails sent per month.
`events`	No	Custom events you emit via POST /v1/events per month. Emails sent and SES delivery events (deliveries, opens, clicks, bounces) are not counted and do not affect price.
`billing`	No	Wraps billing interval.
`sesPlan`	No	AWS SES pricing plan for that account and Region. New AWS accounts default to 'essentials' ($0.16/1K); 'alacarte' is $0.10/1K.
`retention`	No	How long email event history is kept.
`dedicatedIp`	No	Include a dedicated sending IP.

Output Schema

TableJSON Schema

Name	Required	Description
`aws`	No	AWS-side cost, itemized.
`input`	No	The estimate inputs, after defaults were applied.
`total`	Yes	Wraps fee plus the AWS bill.
`wraps`	No	Flat Wraps platform fee for the plan. Does not vary with volume.
`period`	Yes	Always month.
`currency`	Yes	Always USD.
`shareUrl`	No	Link reproducing this estimate on wraps.dev.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 14, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "aws": {
+      "description": "AWS-side cost, itemized.",
+      "properties": {
+        "sesPlan": {
+          "description": "SES pricing plan the estimate assumes.",
+          "type": "string"
+        },
+        "total": {
+          "type": "number"
+        }
+      },
+      "type": "object"
+    },
+    "currency": {
+      "description": "Always USD.",
+      "type": "string"
+    },
+    "input": {
+      "description": "The estimate inputs, after defaults were applied.",
+      "type": "object"
+    },
+    "period": {
+      "description": "Always month.",
+      "type": "string"
+    },
+    "shareUrl": {
+      "description": "Link reproducing this estimate on wraps.dev.",
+      "type": "string"
+    },
+    "total": {
+      "description": "Wraps fee plus the AWS bill.",
+      "type": "number"
+    },
+    "wraps": {
+      "description": "Flat Wraps platform fee for the plan. Does not vary with volume.",
+      "type": "object"
+    }
+  },
+  "required": [
+    "currency",
+    "period",
+    "total"
+  ],
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds valuable behavioral context: the Wraps fee never varies with volume, the AWS event-pipeline line items are derived from emails and event types, and the events parameter is ignored. It does not contradict annotations and goes beyond the safety profile to explain the estimation logic.

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 four sentences long, each contributing distinct information: purpose, fee structure, the events note, and a usage recommendation. It is front-loaded with the core purpose and avoids redundant wording, though it is slightly longer than strictly necessary.

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?

Given the tool's complexity (7 parameters, 4 enums, output schema present), the description covers the essential logic, flags the ignored parameter, and explains why to use it. It does not describe the output format, but the output schema exists to cover that, and the description provides enough context for correct invocation.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by noting the events parameter is backward-compatible and ignored, and by hinting that 'six variables interact,' which alerts the agent to parameter interdependencies. This extra semantic context justifies a 4.

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 clearly identifies the tool as a cost estimator for email on Wraps + AWS, specifying the flat Wraps fee and the itemized AWS bill components (SES, EventBridge, SQS, Lambda, DynamoDB, dedicated IP, WAF). It also states it should be used 'instead of doing the arithmetic,' distinguishing it from the sibling document tools, which are entirely unrelated. The purpose is specific and unambiguous.

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?

The description explicitly instructs to use this tool instead of manual calculation, and it clarifies the events parameter is accepted only for backward compatibility and does not affect the estimate. This provides clear guidance on when to invoke the tool and what to expect, even though siblings are not competing alternatives.

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

All Wraps 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.