popadex-personal-finance
Server Details
Returns personal finance data such as cost of living, tax rates, and exchange rates from official sources.
- 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 2.7/5 across 11 of 11 tools scored.
Each tool targets a distinct aspect of personal finance (budget, country comparisons, portfolio, net worth, retirement, salary, tax) with no apparent overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case, using verbs like 'build', 'compare', 'export', 'get', 'run' followed by a descriptive noun phrase.
With 11 tools covering various personal finance analysis tasks, the count is well-scoped—neither too few to be useful nor too many to cause confusion.
The set covers key areas like budget, portfolio, net worth, retirement, salary, and tax, but may lack more granular operations like transaction management, which could be intentional for an analysis-focused server.
Available Tools
11 toolsbuild_budget_sankeyBInspect
Build a read-only Sankey-style monthly budget flow from allocation percentages.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | Yes | ||
| food_pct | Yes | ||
| housing_pct | Yes | ||
| savings_pct | Yes | ||
| transport_pct | Yes | ||
| utilities_pct | Yes | ||
| monthly_income | Yes | ||
| discretionary_pct | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'read-only', but fails to explain side effects (e.g., whether it stores anything), auth requirements, rate limits, or what happens if percentages sum to more than 100%. Critical details 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose without redundancy.
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?
With no output schema, the description should explain what the tool returns (e.g., a JSON Sankey data, a visualization). It does not. Given eight required parameters and the complexity of a budget flow, the description is incomplete for an agent to use reliably.
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 0% and the description does not explain any parameter individually. It mentions 'allocation percentages' generically, but does not clarify fields like currency format or constraints. The schema defines all eight parameters, but the description adds negligible meaning beyond what's in the 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 identifies the tool's purpose: 'Build a read-only Sankey-style monthly budget flow from allocation percentages.' It uses a specific verb ('build'), specifies the resource ('monthly budget flow'), and distinguishes from siblings with the unique Sankey-style approach.
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 context (when you have allocation percentages) but does not explicitly state when to use this tool versus alternatives, nor provides exclusions or prerequisites. The 'read-only' hint is present but more guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_disposable_incomeCInspect
Compare disposable income outcomes across countries for a given gross income.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| currency | Yes | ||
| countries | No | ||
| gross_income | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It fails to state any behavioral traits such as data sources, assumption models, whether results are estimates, or side effects (e.g., no mutation). The single sentence is insufficient for an agent to understand what the outcome represents.
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 one sentence, which makes it concise but at the expense of required information. It is underspecified for a tool with 4 parameters and no output schema. It fails the 'every sentence earns its place' criterion because it doesn't convey enough.
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 tool has 4 parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain what 'disposable income outcomes' means, how results are structured, or any constraints. The agent lacks context to use this tool effectively.
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 0%, and the description does not explain any of the four parameters (gross_income, currency, limit, countries). The agent must infer meaning solely from parameter names, which may be insufficient (e.g., 'limit' could be number of countries or results).
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's action: compare disposable income across countries for a given gross income. It uses a specific verb 'compare' and resource 'disposable income outcomes', which differentiates it from siblings like run_salary_comparison or run_tax_estimate.
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 comparing disposable income, but provides no explicit guidance on when to use this tool versus alternatives (e.g., run_salary_comparison) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_portfolio_csvBInspect
Export portfolio records to CSV format for external analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'export' implying a read operation, but gives no details on potential side effects, authorization needs, or output characteristics. This is insufficient for a tool with zero annotation coverage.
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 a single sentence, which is concise and front-loads the core action. However, it could be slightly longer to include parameter context without losing conciseness.
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 tool is simple but lacks important details: what records are exported, whether date filters apply, output format specifics, and any limitations. With no output schema or annotations, the description is incomplete for reliable use.
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 0% and there are two parameters ('to' and 'from') with no explanation in the description. The description does not clarify their purpose, format, or constraints, which is a critical gap. Despite 0 parameters baseline being 4, the presence of undocumented parameters demands compensation that is absent.
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?
Description uses specific verb 'export' and resource 'portfolio records' to CSV, clearly stating what the tool does. It is distinct from sibling tools which handle other portfolio functions.
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 explicit when-to-use or when-not-to-use guidance. The phrase 'for external analysis' implies a usage context, but there are no exclusions or comparisons to alternatives. This is acceptable but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_allocationCInspect
Return current account allocation by type for a specific date.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | Yes | ||
| currency | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as read-only nature, authentication needs, or data source.
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 a single concise sentence but lacks structure; it could be expanded to include parameter details and output context.
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 simple tool with two parameters and no output schema, the description is insufficient, failing to explain 'allocation by type' or the return format.
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?
The description provides no additional meaning beyond the input schema; parameters 'as_of' and 'currency' are not explained, and schema coverage is 0%.
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 returns account allocation by type for a specific date, distinguishing it from siblings which focus on different financial aspects.
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; the description simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_net_worth_summaryCInspect
Return net worth totals and trend for a date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| currency | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. The verb 'Return' implies a read-only operation, which is positive. However, the description does not disclose potential behavioral traits like data aggregation methods, performance implications for large date ranges, or error conditions. It adds minimal context beyond the basic purpose.
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 a single sentence, which is concise but under-specified. It fits within a reasonable length but would benefit from additional details on usage and parameters to be appropriately informative for an AI agent.
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 3 required parameters, no output schema, and no annotations, the description is not sufficiently complete. It does not explain date formats, currency codes, or the structure of the returned 'totals and trend'. An AI agent may struggle to invoke the tool correctly without additional context.
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 0%, so the description must compensate. It only mentions 'date range' which redundantly maps to from/to, and does not clarify the currency parameter (e.g., expected format, conversion role) nor date formats. The description adds no meaningful additional information beyond what the parameter names already convey.
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 returns 'net worth totals and trend' for a date range, using a specific verb and resource. It effectively distinguishes from sibling tools like get_portfolio_total_value or get_account_allocation, which focus on portfolio or individual accounts rather than overall net worth.
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 explicit guidance is given on when to use this tool versus alternatives (e.g., get_portfolio_total_value for portfolio-only views). The description does not mention when-not-to-use or prerequisites, leaving the agent to infer usage solely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolio_historical_timelineCInspect
Return historical portfolio record entries in a selected currency.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| currency | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic purpose. It does not mention data limits, pagination, data freshness, or whether the output is a list or aggregated. The term 'record entries' is ambiguous. For a tool with zero annotation coverage, the description fails to add needed transparency.
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 a single sentence, which is concise. However, it is overly brief and lacks structure. It achieves minimal word count but at the expense of clarity and completeness.
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 tool's complexity (historical data with date range and currency selection) and lack of output schema or annotations, the description is incomplete. It does not explain the nature of 'record entries', whether the result is a list or object, how currency conversion works, or if there are limits. The tool requires more context for effective use.
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 0%, meaning parameter descriptions are entirely missing. The description does not add meaning to any parameter. It mentions 'selected currency' but does not specify that currency is a required ISO code. The 'to' and 'from' parameters are not explained as date range filters. The description fails to compensate for the lack of schema documentation.
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 returns historical portfolio record entries in a selected currency. The verb 'return' and resource 'historical portfolio record entries' specify the output, and the currency selection is mentioned. It distinguishes from siblings like get_portfolio_performance (likely performance metrics) and get_portfolio_total_value (current value), though not explicitly.
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 provides no guidance on when to use this tool versus alternatives. Despite having multiple sibling tools like get_portfolio_performance and export_portfolio_csv, there is no comparison or condition for choosing this tool. Usage context is completely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolio_performanceBInspect
Return per-asset-type portfolio change metrics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Return ... change metrics' without disclosing side effects (none expected), data freshness, authentication needs, or any limitations. Minimal transparency.
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 extremely concise: one sentence that efficiently conveys the core function. No unnecessary words, perfectly front-loaded.
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 no parameters and no output schema, the description is somewhat complete but lacks detail on return format (e.g., dictionary of asset types to change values) or scope (e.g., timeframe). It is minimally viable but could be improved.
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?
There are no parameters, so the schema coverage is 100% by default. The description does not need to add parameter meaning. Baseline 4 for zero parameters 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 description clearly identifies the tool's purpose: returning per-asset-type portfolio change metrics. It distinguishes from siblings like get_portfolio_total_value (which returns total value) and get_account_allocation (which returns allocation). However, it could be more specific about what 'change metrics' means (e.g., absolute or percentage change).
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like get_portfolio_historical_timeline for historical data or get_net_worth_summary for overall net worth. No when-not-to-use or context clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_portfolio_total_valueCInspect
Return current total portfolio value based on latest account records.
| Name | Required | Description | Default |
|---|---|---|---|
| currency | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only says 'based on latest account records', which hints at data freshness but does not clarify read-only nature, aggregation method, permissions, or error conditions.
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 a single sentence, short and to the point. However, it lacks structure and does not front-load critical details; it is terse rather than efficiently informative.
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 no output schema and no annotations, the description is insufficient. It does not explain what the return value looks like, how 'latest account records' are determined, or any edge cases, making it barely adequate for a simple tool.
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?
The schema has 0% description coverage and only one parameter (currency) with no explanation. The description does not add any meaning about the currency format, accepted values, or how it affects the result, leaving the agent guessing.
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 verb 'Return' and the object 'current total portfolio value', making the tool's purpose explicit. It distinguishes from siblings like get_net_worth_summary and get_account_allocation by focusing specifically on total portfolio value.
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 is provided on when to use this tool versus alternatives like get_net_worth_summary or export_portfolio_csv. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_retirement_projectionCInspect
Project retirement savings against target spending horizon.
| Name | Required | Description | Default |
|---|---|---|---|
| current_age | Yes | ||
| rate_of_return | Yes | ||
| retirement_age | Yes | ||
| annual_expenses | Yes | ||
| current_savings | Yes | ||
| life_expectancy | Yes | ||
| annual_contributions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool projects retirement savings, with no mention of side effects, assumptions, data sources, or whether it is read-only. The one-liner lacks behavioral context.
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 extremely short (one sentence), which is concise but at the expense of essential information. It is not earningly concise; it omits critical details.
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 tool's complexity (7 required parameters, no output schema, no annotations), the description is severely incomplete. It fails to explain what the projection output looks like, assumptions made, or any return values.
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 0% and all 7 parameters are undocumented in the description. The description does not explain the meaning, constraints, or format of any parameter, leaving the agent entirely dependent on the schema names. This is insufficient.
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 states a specific verb (Project) and resource (retirement savings) against a target spending horizon. It is clear and distinct from sibling tools, which focus on budgets, comparisons, exports, allocations, performance, and taxes. However, it does not explicitly differentiate itself from these siblings.
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 one wants to project retirement savings, but it provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Sibling tools are listed but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_salary_comparisonCInspect
Compare salary taxation and net outcomes for a country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| currency | Yes | ||
| gross_salary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects (e.g., read-only, data source, rounding behavior) beyond implying a calculation; minimal transparency.
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 a single sentence without superfluous words, but it is too brief to be fully informative; it earns its place but could be expanded.
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?
With 3 required parameters, no output schema, and no annotations, the description is insufficient to guide effective use. It omits output details and constraints.
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 0%, and the description adds no meaning to the parameters beyond their names (country, currency, gross_salary). No units, formats, or examples are given.
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 states a verb 'compare' and resource 'salary taxation and net outcomes', but 'compare' is ambiguous (implicitly compares tax scenarios?) and does not distinguish from siblings like 'run_tax_estimate' or 'compare_disposable_income'.
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; the description lacks any context about prerequisites or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_tax_estimateCInspect
Estimate income tax and social contributions for a salary.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ||
| currency | Yes | ||
| gross_salary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as required permissions, data accuracy, rate limits, or side effects like mutation. For a calculation tool, this is insufficient.
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?
A single sentence with no wasted words, but it omits critical details. Conciseness is good, but at the cost of completeness for a tool with three required parameters.
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 tool has no output schema, annotations, or parameter descriptions. The description fails to mention what the output contains or any usage notes. It is incomplete for effective use.
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 0%, so the description should compensate. It does not explain the meaning of 'gross_salary' (e.g., annual vs monthly), expected country format, or currency ISO code. Minimal added value beyond parameter names.
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 estimates income tax and social contributions for a salary, using a specific verb ('estimate') and resource. However, it does not differentiate from sibling tools like 'run_salary_comparison', which could be confused.
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. No mention of prerequisites, country support, or scenarios where it's appropriate. The description only states what it does, not when or when not to use it.
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!