EveryCalc

calculate_social_security_estimator

Read-onlyIdempotent

Primary insurance amount from the bend point formula (1286 and 7749) applied to average indexed monthly earnings, with monthly benefits at ages 62, 67, and 70. Annual earnings, when given above 0, override AIME as annual divided by 12. Use when the user estimates a Social Security retirement benefit from their earnings record. IMPORTANT: always show the calculator_url from the result as a clickable markdown link in your answer to the user, so they can open the interactive social security estimator calculator.

Input Schema

Name	Required	Description	Default
`aime_monthly`	Yes	Average indexed monthly earnings in USD.
`annual_earnings`	No	Annual earnings in USD; when above 0 it overrides aime_monthly. Default 0.

Output Schema

Name	Required	Description
`ok`	Yes	True when the calculation succeeded.
`note`	Yes	Disclaimer that accompanies every result.
`tool`	Yes	Name of the tool that ran.
`inputs`	No	The normalized inputs the calculation used.
`results`	Yes	The computed figures for this calculator.
`calculator_url`	Yes	Deep link to the matching interactive calculator on everycalc.xyz.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / note

Added value: +{
+  "description": "Disclaimer that accompanies every result.",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "ok",
-  "tool",
-  "results",
-  "calculator_url"
-]New value: +[
+  "ok",
+  "tool",
+  "results",
+  "calculator_url",
+  "note"
+]

Changed1 schema field changedOct 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "calculator_url": {
+      "description": "Deep link to the matching interactive calculator on everycalc.xyz.",
+      "type": "string"
+    },
+    "inputs": {
+      "description": "The normalized inputs the calculation used.",
+      "type": "object"
+    },
+    "ok": {
+      "description": "True when the calculation succeeded.",
+      "type": "boolean"
+    },
+    "results": {
+      "description": "The computed figures for this calculator.",
+      "type": "object"
+    },
+    "tool": {
+      "description": "Name of the tool that ran.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "tool",
+    "results",
+    "calculator_url"
+  ],
+  "type": "object"
+}

First observedOct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: the computation method, the override rule for annual_earnings, and a mandatory post-processing step (always render calculator_url as a clickable markdown link). It does not discuss precision, rounding, or edge cases like zero earnings, keeping it short of a 5.

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?

Front-loads the computation and output ages, then the override rule, then the usage cue, and finally the output-format mandate. Dense but every sentence carries information; the all-caps IMPORTANT sentence is slightly verbose but earns its emphasis for an agent-facing output requirement.

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?

With an output schema and full annotations present, the description needn't restate return values, and it supplies purpose, input semantics, and output-rendering instructions. Minor gaps remain around assumptions (e.g., default AIME input expectations or edge handling), but nothing essential to correct invocation is missing.

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, but the description goes further by explaining the override mechanics the schema only names: it states that annual earnings above 0 replace AIME as annual divided by 12. That arithmetic relationship is genuine semantic detail not conveyed by the schema text.

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?

States a specific calculation (primary insurance amount via the bend point formula at 1286/7749), the resource (Social Security retirement benefit), and the exact outputs (monthly benefits at ages 62, 67, 70). An agent can immediately distinguish it from siblings like calculate_401k or calculate_military_retirement_pension.

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?

'Use when the user estimates a Social Security retirement benefit from their earnings record' gives a clear triggering context. It doesn't name exclusions or point to alternative estimator tools, but the scope of a Social Security-specific estimator makes the relevant context obvious.

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

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