Skip to main content
Glama

Numeratica — financial planning calculations

ira_eligibility

Ira eligibility. Numeratica POST /v1/ira-eligibility — returns JSON with result_id, engine_version, and a not-advice disclaimer (seed echoed for reproducible Monte Carlo where applicable). See the input schema for the accepted fields.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ira_eligibility"
  }
}

Input Schema

NameRequiredDescriptionDefault
ageNo
magiNo
tax_yearNo
compensationNo
filing_statusNo
spouse_coveredNo
elective_deferralNo
employer_contributionsNo
covered_by_workplace_planNo
plan_allows_mega_backdoorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.1/5.0
Behavior2/5

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

No annotations provided. Description mentions output fields and a Monte Carlo seed for reproducibility but does not disclose whether the tool is read-only, requires authentication, or has rate limits. The behavioral profile is insufficient for safe invocation.

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

Conciseness3/5

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

Two sentences; moderately concise. However, the first sentence ('Ira eligibility') is too terse, and the second includes endpoint details that may be irrelevant to the agent. Could be more purpose-driven.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters and no output schema, the description is critically incomplete. It does not explain what the tool actually computes (e.g., eligibility for Traditional vs. Roth IRA), what the output JSON means, or how to interpret results. The agent cannot effectively use this tool with current information.

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

Parameters1/5

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

Schema coverage is 0% (no descriptions for any of the 10 parameters). The description defers entirely to the input schema without adding any semantic meaning, leaving agents to guess what fields like 'magi' or 'elective_deferral' represent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Ira eligibility' which implies checking eligibility for IRA contributions, but it lacks a clear verb (e.g., 'determines', 'checks') and does not specify what aspect of eligibility. No contrast with sibling tools like retirement_backdoor_roth or roth_vs_traditional.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. With numerous sibling tools related to retirement and Roth, the description should indicate scenarios where IRA eligibility checking is appropriate.

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.