RetireGolden MCP

Official

by RetireGolden

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct operation: building, projecting, comparing, validating, explaining, solving for spending, batch evaluating, and schema description. No two tools have overlapping purposes; an agent can clearly distinguish them.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., build_plan, compare_scenarios), but batch_evaluate is a verb_verb form, making it slightly inconsistent. Overall, naming is clear and predictable.
Tool Count5/5
Eight tools is well-scoped for a retirement planning server. Each tool serves a core function without unnecessary redundancy, covering the essential workflows.
Completeness4/5
The tool set covers key lifecycle operations: build, project, validate, compare, and solve. However, missing explicit tools to update or retrieve the current plan represent minor gaps that could complicate workflows.
Average 3.3/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 93 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as side effects, data handling, or whether the comparison is purely analytical. The disclaimer hints at limitations but lacks specificity.
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?
The description is brief but front-loaded with a disclaimer that may not be essential for functional clarity. The second sentence is the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no schema descriptions, the description fails to provide complete context about how the comparison works, expected inputs, or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only names 'planA', 'planB', and 'startYear' without explaining their format or purpose. StartYear's role in comparison is unclear.
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 the tool compares two plan JSON documents via projection summaries. This distinguishes it from sibling tools like run_projection or validate_plan, though 'projection summaries' could be more precise.
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 vs alternatives (e.g., batch_evaluate, solve_max_spending). The disclaimer adds legal context but no usage vs. non-usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosure. It states the tool is educational only and not advisory, which informs safety traits. However, it does not mention idempotency or side effects. The return content is listed, but behavioral details like performance or auth needs are missing.
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 a single sentence with a disclaimer. It is concise, but the disclaimer dominates. Front-loading the functional purpose would improve clarity. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is the sole source of context. It fails to adequately explain the tool's purpose or how it differs from sibling tools like 'describe_plan_schema.' The return value is described vaguely, lacking details about the format or structure.
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?
There are no parameters, so baseline is 4. The description does not need to add parameter info. The empty schema already fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description focuses on a disclaimer and only vaguely states it returns 'framing, assumptions, caveats, and limitations for the current session.' The core purpose of explaining a modeled result is implied by the name but not clearly articulated. The verb 'return' is used instead of a specific action like 'explain' or 'describe.'
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 is provided on when to use this tool over siblings like 'describe_plan_schema' or 'run_projection.' The phrase 'for the current session' hints at context but is insufficient. No alternative tools or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it validates a plan, but does not disclose what validation entails (e.g., error checking, schema validation, or semantic checks) or any side effects. The disclaimer is helpful but insufficient.
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 short with two sentences. It front-loads the disclaimer which is important. Could be slightly more efficient by making the function statement more prominent, but overall it is compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema or annotations, the description should provide more context about what validation results look like, how to interpret them, or prerequisites. Currently it leaves the agent guessing about return value and edge cases.
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 0% and the 'plan' parameter is untyped. The description adds meaning by mentioning 'plan JSON (or the current session plan)', clarifying that the parameter accepts JSON text or defaults to the session plan. This provides some context beyond the minimal schema.
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 the tool's action ('Validate plan JSON (or the current session plan)') and verb ('validate') on a specific resource ('plan'). It distinguishes from sibling tools which focus on building, comparing, or scenario analysis, but the heavy disclaimer somewhat dilutes the purpose.
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 is provided on when to use this tool versus alternatives like 'build_plan' or 'run_projection'. The disclaimer about non-advice is a limitation but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses educational-only nature and prohibits prescribing securities actions, implying read-only intent. However, it does not detail side effects, permissions, or rate limits.
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 concise (3 sentences) and front-loaded with a disclaimer. Every sentence serves a purpose, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description lacks detail on return values, result format, or how the output relates to the objective. For a batch evaluation tool with complex inputs, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, and the description only mentions 'policies' generically, ignoring the 'objective' parameter entirely. The description adds minimal meaning beyond the schema, failing to compensate for the low coverage.
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 the tool evaluates many policies against the current household plan, with a 'search-friendly' hint. However, it does not explicitly differentiate from siblings like compare_scenarios or solve_max_spending.
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?
The description provides usage guidance like 'Cap batches sensibly (~40 tool calls total in agent loops)' and a disclaimer. But it lacks explicit when-to-use or when-not-to-use compared to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a disclaimer that this is educational decision-support only and should not be used for actual financial advice. This adds important behavioral context. However, no annotations exist, and the description does not disclose whether the tool modifies state, requires authentication, or has side effects. The transparency is adequate for a read-only computation but incomplete.
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 very short (two sentences) and front-loaded with the disclaimer. Every sentence serves a purpose. It could be slightly more concise by merging the disclaimer with the functional description, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, but the description fails to mention what the return value looks like (e.g., a number, a structure). Since there is no output schema, the agent has no clue about the output format. The disclaimer is helpful but incomplete for a tool that returns data.
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?
There are zero parameters, and schema coverage is 100%. The description adds no parameter info, but none is needed. The baseline score for a parameterless tool is 4.
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 the tool's purpose: to find the maximum sustainable base annual spending for the session plan. The verb 'bisect' is somewhat technical but specific enough. The tool is distinguished from siblings like 'build_plan' and 'compare_scenarios' by focusing on a single computation. However, 'bisect' might be ambiguous to some agents.
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. The disclaimer about educational use is not usage guidance. The description does not specify contexts or prerequisites, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool builds or replaces an in-memory plan and mentions specific constraints (e.g., non-zero wage causes hard error, state requirement). However, it does not detail side effects like mutation of persistent state, idempotency, or error behavior beyond the wage example. Sufficient but not exhaustive.
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 (three sentences) and front-loaded with the core action. The disclaimer is minor. It efficiently conveys the main purpose without redundancy. However, the disclaimer could be integrated or placed after the action for better structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits information about the return value or effect on the system. With no output schema and a complex set of parameters, the agent needs to know what the tool returns or how the in-memory plan is affected. It also does not mention relation to sibling tools like validate_plan or run_projection, leaving gaps in understanding the workflow.
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 description coverage is 80%, but the description adds significant value by explaining contextual details like required state on typed path, override mechanisms (assumptions.state), and hard error on non-zero wage. It clarifies parameter relationships and edge cases beyond the schema's own descriptions.
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 states the tool's action: 'Build or replace the in-memory plan from typed household/policy params or full plan JSON.' It specifies the verb 'build or replace' and the resource 'in-memory plan', distinguishing it from siblings like validate_plan or run_projection, which have different purposes.
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?
The description lacks guidance on when to use this tool versus alternatives. It only includes a disclaimer about educational use, but does not specify scenarios, prerequisites, or when not to use it. No explicit when-to-use or when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it is a 'Read-only meta tool', educational disclaimer, and explains behavior with path parameter. Does not cover rate limits or auth needs, but adequate for a simple schema retrieval tool.
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?
Three sentences, front-loaded with disclaimer, then core action, then usage guidance. Concise and well-structured, though disclaimer could be more brief.
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 no output schema and simple parameters, description covers return value, use of path, workflow, and educational nature. Sufficiently complete for the tool's purpose.
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%, and description adds meaning by explaining dotted path vs JSON pointer syntax and purpose of 'keep token cost down'. Adds value beyond the schema.
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 states the tool returns the engine's versioned Plan JSON Schema and schemaVersion, using specific verb 'return' and 'fetch'. It distinguishes itself from sibling tools like validate_plan by being a meta-tool for schema retrieval.
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?
Provides usage context: optional path parameter for reducing token costs, mentions alternative exposure as MCP resource, and gives workflow hint ('Feed...into update_plan, then validate_plan'). Lacks explicit when-not-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses deterministic behavior, always starts at session plan's startYear, details of tax modeling (federal, state, local, override), and consistency with web app output. Comprehensive.
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?
Description is somewhat long but well-structured: disclaimer first, then core action, parameter details, tax modeling. Every sentence adds value. Could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists. Description partially explains return values for summary and years, but lacks full structure of per-year ledger. With moderate complexity, a bit more detail on output format would improve completeness.
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% for the single parameter. Description adds meaning beyond schema by explaining default behavior and what each enum value returns (summary vs years). Provides context on startYear/endYear/summary/caveats vs per-year ledger.
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?
Description clearly states it runs a deterministic projection on the session plan. It distinguishes from siblings like build_plan (to change start year) and solve_max_spending (optimization). Provides specific verb, resource, and constraints.
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?
Explicitly states educational decision-support only, not advice, and warns against prescribing securities actions. Explains when to use build_plan to change startYear. Could be more explicit about when not to use vs other siblings like compare_scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![RetireGolden-MCP MCP server](https://glama.ai/mcp/servers/RetireGolden/RetireGolden-MCP/badges/card.svg)](https://glama.ai/mcp/servers/RetireGolden/RetireGolden-MCP)

Score Badge

Copy to your README.md:

[![RetireGolden-MCP MCP server](https://glama.ai/mcp/servers/RetireGolden/RetireGolden-MCP/badges/score.svg)](https://glama.ai/mcp/servers/RetireGolden/RetireGolden-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RetireGolden/RetireGolden-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server