decisions
Server Details
Verified US tax and money decision tools: verdict plus a pre-filled deep link to the full page.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 5 of 5 tools scored. Lowest: 3.2/5.
Each tool addresses a distinct financial decision (filing status, freelance rate, job offer, raise/bonus, retirement account) with no overlap, ensuring clear selection.
All tool names use consistent snake_case with descriptive phrases (e.g., best_filing_status, freelance_rate_floor), following a clear pattern.
Five tools is well-scoped for a specialized decision calculator server, covering common financial choices without being excessive.
The set covers key personal finance decisions, but missing some like rent-vs-buy or loan payoff; however, each tool returns a complete verdict and link, so no dead ends.
Available Tools
5 toolsbest_filing_statusMarried Filing Jointly vs SeparatelyARead-onlyIdempotentInspect
Married Filing Jointly vs Separately — Compares Married Filing Jointly vs Separately for a couple and says which keeps more, including lost credits. Returns a one-line verdict plus a link to the full interactive page with the numbers pre-filled. Accepts only numbers and enums.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tax year, e.g. 2026. Omit to use the current tax year. | |
| spouseA | Yes | ||
| spouseB | Yes | ||
| otherDependents | No | A non-negative number (US dollars unless the field name says otherwise). | |
| investmentIncome | No | A non-negative number (US dollars unless the field name says otherwise). | |
| qualifyingChildren | No | A non-negative number (US dollars unless the field name says otherwise). | |
| hasChildcareExpenses | No | true or false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds that the tool returns a one-line verdict and a link, and mentions 'including lost credits,' which provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loaded with the purpose. However, it could be slightly more structured without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, multiple parameters) and no output schema, the description should provide more detail on input structure and output format beyond mentioning a verdict and link. The phrase 'accepts only numbers and enums' is misleading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% with descriptions for most parameters, but the description states 'Accepts only numbers and enums,' which contradicts the schema which includes booleans and objects. This mischaracterization confuses parameter types and does not add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Married Filing Jointly vs Separately' and description clearly state the tool compares two filing statuses and returns a verdict on which keeps more, including lost credits. It is distinct from sibling tools which cover other financial comparisons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for tax filing status comparison but does not explicitly say when to use it over alternatives, nor does it provide exclusion criteria. Sibling tools are unrelated, so differentiation is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
freelance_rate_floorFreelance Rate FloorARead-onlyIdempotentInspect
Freelance Rate Floor — Calculates the hourly rate a freelancer must bill to match a given salary after self-employment tax and lost benefits. Returns a one-line verdict plus a link to the full interactive page with the numbers pre-filled. Accepts only numbers and enums.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Tax year, e.g. 2026. Omit to use the current tax year. | |
| stateCode | Yes | Two-letter US state code, e.g. CA, TX, NY. | |
| filingStatus | Yes | One of: single, married_joint, married_separate, head_of_household. | |
| currentSalary | Yes | A non-negative number (US dollars unless the field name says otherwise). | |
| annualBenefitsValue | Yes | A non-negative number (US dollars unless the field name says otherwise). | |
| billableHoursPerYear | No | A non-negative number (US dollars unless the field name says otherwise). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, so the description adds value by stating the output is a one-line verdict with a link to an interactive page. This clarifies the read-only nature and adds context about the response format, though it could elaborate on any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose in the first sentence. Every word earns its place—no redundancy, just clear and concise information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity, the description covers the output format (one-line verdict + link) and input constraints, and annotations cover safety. Minor omission: not explicitly stating the tool is US-specific, though the schema implies it via stateCode.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the description adds minimal extra meaning beyond saying 'Accepts only numbers and enums'. The baseline of 3 is appropriate as the schema already explains each parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the hourly rate a freelancer needs to bill to match a given salary after self-employment tax and lost benefits, which is a specific verb+resource. It distinguishes from siblings like 'job_offer_worth_it' by focusing on rate floor calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for freelancers comparing salary to hourly rate but does not explicitly state when to use this tool versus alternatives like 'job_offer_worth_it'. No exclusion criteria or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
job_offer_worth_itIs this job offer worth it?ARead-onlyIdempotentInspect
Is this job offer worth it? — Compares two jobs on real take-home pay after federal, state, FICA, 401(k) and commute, and says which wins and by how much. Returns a one-line verdict plus a link to the full interactive page with the numbers pre-filled. Accepts only numbers and enums.
| Name | Required | Description | Default |
|---|---|---|---|
| offer | Yes | ||
| current | Yes | ||
| options | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, meaning it is safe and idempotent. The description adds that it accepts only numbers and enums and returns a one-line verdict plus a link, which is transparent about the output. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first explains the core functionality and comparison logic, second describes the output and input constraints. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, inputs, and output adequately. It does not detail the optional 'options' parameter, but the schema provides full detail. For a tool with nested objects and many fields, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (each property has clear descriptions). The description simply states 'Accepts only numbers and enums', which adds little beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool compares two jobs (current vs. offer) on real take-home pay after deductions, returning a verdict and link. It is distinct from siblings which cover filing status, freelance rates, raise valuation, and retirement accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when evaluating a job offer against a current job, but does not explicitly state when to avoid using it or suggest alternatives. However, sibling tool names are sufficiently distinct that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
raise_bonus_valueRaise / Bonus True ValueBRead-onlyIdempotentInspect
Raise / Bonus True Value — Shows how much of a raise or bonus you actually keep after marginal tax and lifestyle inflation. Returns a one-line verdict plus a link to the full interactive page with the numbers pre-filled. Accepts only numbers and enums.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | One of: raise, bonus. | |
| year | No | Tax year, e.g. 2026. Omit to use the current tax year. | |
| stateCode | Yes | Two-letter US state code, e.g. CA, TX, NY. | |
| raiseAmount | Yes | A non-negative number (US dollars unless the field name says otherwise). | |
| filingStatus | Yes | One of: single, married_joint, married_separate, head_of_household. | |
| currentSalary | Yes | A non-negative number (US dollars unless the field name says otherwise). | |
| annualInflationPercent | No | Percentage from 0 to 100. | |
| lifestyleInflationPercent | No | Percentage from 0 to 100. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description only adds the behavior of returning a one-line verdict and a link. This is useful but minimal. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short, front-loaded with the title and purpose, and includes key information like return type (one-line verdict + link). Efficient use of words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description partially compensates by stating the return format. However, it does not explain the verdict content or edge cases. With 8 parameters and no output schema, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only adds that the tool 'Accepts only numbers and enums', which is already evident from the schema. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the true value of a raise or bonus after tax and lifestyle inflation. The verb 'Shows' and resource 'raise or bonus' are specific. It does not explicitly distinguish from sibling tools, but the purpose is unique enough among financial calculators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like best_filing_status or job_offer_worth_it. It only describes what the tool does, not the context of use or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
roth_vs_traditionalRoth vs TraditionalARead-onlyIdempotentInspect
Roth vs Traditional — Compares Roth vs Traditional retirement contributions: the break-even retirement tax rate and which to choose. Returns a one-line verdict plus a link to the full interactive page with the numbers pre-filled. Accepts only numbers and enums.
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | A non-negative number (US dollars unless the field name says otherwise). | |
| year | No | Tax year, e.g. 2026. Omit to use the current tax year. | |
| accountType | No | One of: 401k, ira. | |
| yearsToGrow | No | A non-negative number (US dollars unless the field name says otherwise). | |
| filingStatus | Yes | One of: single, married_joint, married_separate, head_of_household. | |
| annualReturnRate | No | Decimal fraction, e.g. 0.07 for 7%. Must be between 0 and 1 (do not pass a whole-number percent). | |
| currentGrossIncome | Yes | A non-negative number (US dollars unless the field name says otherwise). | |
| afterTaxContribution | No | A non-negative number (US dollars unless the field name says otherwise). | |
| expectedRetirementIncome | Yes | A non-negative number (US dollars unless the field name says otherwise). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no further behavioral details beyond stating the output format and input constraints. It does not disclose any side effects or prerequisites, but also does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action and result, and includes necessary clarifications (output type, input constraints). Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description adequately describes the output (verdict + link) but could elaborate on the format or content of the verdict. For a tool with complex inputs, it provides enough context for the agent to understand the function and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The description only adds 'Accepts only numbers and enums' which is already implied by the schema. It does not explain the meaning or purpose of specific parameters beyond what the schema provides, thus adding minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool compares Roth vs Traditional retirement contributions, calculates break-even tax rate, and returns a verdict plus link. This clearly differentiates it from siblings (best_filing_status, freelance_rate_floor, etc.) which address different financial decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for comparing retirement contribution types but does not explicitly state when to choose this over alternatives or when not to use it. The sibling tool names provide context, but no direct guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!