Money Manager MCP Server

by shahlaukik

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: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity, as they are organized by resource types (asset, card, dashboard, init, summary, transaction, transfer) and specific actions (create, list, update, delete, get, export). The descriptions further clarify unique functions, such as dashboard_get_asset_chart for chart data versus dashboard_get_overview for overview data, ensuring agents can easily differentiate between tools.
Naming Consistency4/5
The naming follows a consistent pattern of resource_action or resource_action_additional_detail using snake_case throughout, with minor deviations like init_get_data and summary_export_excel that slightly break the verb_noun convention but remain readable. Overall, the naming is predictable and aids in understanding tool purposes across the set.
Tool Count5/5
With 18 tools, the count is well-scoped for a money management server, covering assets, cards, transactions, transfers, dashboards, summaries, and initialization. Each tool earns its place by providing necessary CRUD operations and additional functionalities like exporting and dashboard views, without being excessive or insufficient for the domain.
Completeness5/5
The tool surface offers complete CRUD/lifecycle coverage for key resources (assets, cards, transactions, transfers), along with dashboard insights, summary statistics, data export, and initialization. There are no obvious gaps; agents can perform all essential financial management tasks, from creating and updating records to analyzing trends and exporting data, ensuring no dead ends in workflows.
Average 3/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 passing
This repository is licensed under MIT License.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Modifies' implies a mutation operation, but it doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens to unspecified fields, or any rate limits/constraints. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words ('Modifies an existing asset'), with zero wasted language. It's front-loaded with the core action and resource. While arguably too brief for a mutation tool with no annotations, it earns full marks for conciseness as every word serves a purpose.
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?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'modifies' entails, what fields are updatable, what permissions are needed, or what the response contains. The agent would need to infer too much from the parameter names alone, making this description inadequate for the tool's complexity.
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 description coverage is 100%, so the schema already documents all 7 parameters with basic descriptions. The description adds no additional parameter semantics beyond the generic 'modifies an existing asset' statement. This meets the baseline of 3 when schema coverage is high, but doesn't provide extra value like explaining relationships between parameters or usage patterns.
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 'Modifies an existing asset' clearly states the action (modifies) and resource (asset), distinguishing it from create/delete operations. However, it doesn't specify what aspects of an asset can be modified or how this differs from other update tools like card_update or transaction_update, making it somewhat vague about its specific scope.
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 provides no guidance on when to use this tool versus alternatives like asset_create or asset_delete, nor does it mention prerequisites such as needing an existing asset ID. While the required parameters imply assetId must be provided, there's no explicit usage context or exclusions stated in the description itself.
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 provided, the description carries full burden for behavioral disclosure. It states 'Updates an existing transaction,' implying a mutation operation, but doesn't specify required permissions, whether changes are reversible, error handling (e.g., for invalid IDs), or response format. This is inadequate for a tool with significant mutation potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, though it could benefit from more detail given the lack of annotations and output schema.
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?
For a mutation tool with 13 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for the agent to infer. More context is needed given the tool's complexity.
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 description coverage is 100%, so all parameters are documented in the schema. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., it doesn't explain relationships between fields like mcid and mbCategory). Baseline score of 3 is appropriate as the schema does the heavy lifting.
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 'Updates an existing transaction' clearly states the action (update) and resource (transaction), but it's generic and doesn't differentiate from sibling tools like transaction_create or transaction_delete beyond the verb. It's not misleading but lacks specificity about what aspects of a transaction can be updated.
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 transaction_create or transaction_delete. The description doesn't mention prerequisites (e.g., needing an existing transaction ID) or contextual factors (e.g., use for modifying details vs. creating new ones). This leaves the agent with minimal direction.
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 provided, the description carries full burden for behavioral disclosure. It indicates a creation operation but fails to mention required permissions, whether this is idempotent, what happens on duplicate assets, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficiently front-loaded.
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?
For a creation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what an 'asset/account' represents in this system, how creation affects other entities, or what to expect upon success/failure. The context signals indicate significant complexity that isn't addressed.
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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, such as explaining relationships between parameters (e.g., assetGroupId vs assetGroupName) or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('creates') and resource ('new asset/account'), making the purpose immediately understandable. However, it doesn't distinguish between 'asset' and 'account' or clarify how this differs from sibling tools like card_create or transaction_create, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like card_create or transaction_create, nor does it mention prerequisites or constraints. It simply states what the tool does 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Removes' implies a destructive mutation, but it doesn't specify whether deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., cascading deletions). This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Removes an asset.') with zero wasted words. It's front-loaded and gets straight to the point, making it efficient for an agent to parse.
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?
For a destructive tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after deletion (e.g., confirmation message, error handling), nor does it address behavioral aspects like permissions or irreversibility, leaving critical gaps for agent understanding.
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 description coverage is 100%, with the single parameter 'assetId' clearly documented in the schema. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 verb ('Removes') and resource ('an asset'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'transaction_delete' or specify what type of asset is being deleted (e.g., financial asset vs. digital asset).
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 provides no guidance on when to use this tool versus alternatives like 'asset_update' or 'transaction_delete'. There's no mention of prerequisites (e.g., asset must exist), consequences, or typical use cases, leaving the agent to infer usage context.
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 provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as permissions needed, whether creation is irreversible, error conditions, or typical response format. For a mutation tool with financial implications, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a tool with good schema coverage, making it easy to parse quickly.
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?
For a mutation tool with financial data and no annotations or output schema, the description is inadequate. It doesn't cover behavioral aspects like side effects, authentication needs, or return values, leaving critical gaps for agent understanding despite good schema coverage.
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 description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying credit card creation, which aligns with the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('creates') and resource ('new credit card'), making the purpose immediately understandable. It distinguishes from siblings like card_list (read) and card_update (modify), though it doesn't explicitly contrast with asset_create which creates different resources.
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. The description doesn't mention prerequisites (e.g., needing linked assets), exclusions, or comparisons to sibling tools like asset_create or transaction_create that might handle related financial operations.
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 provided, the description carries full burden for behavioral disclosure. 'Modifies' implies a mutation operation, but it doesn't address critical aspects like required permissions, whether changes are reversible, potential side effects, error conditions, or what the response contains. This leaves significant gaps for a tool that alters financial data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's perfectly front-loaded, immediately conveying the core purpose without any fluff or unnecessary elaboration.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after modification, potential constraints, error handling, or relationship to other tools. Given the complexity of updating financial assets and the lack of structured behavioral information, this leaves too many unknowns for reliable agent operation.
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 description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond the general concept of modification. This meets the baseline expectation when the schema handles parameter documentation completely.
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 action ('Modifies') and resource ('an existing credit card'), making the purpose immediately understandable. It distinguishes from siblings like card_create (creation) and card_list (listing), but doesn't specify what aspects of the card can be modified beyond the general concept.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing card), exclusions, or comparisons to sibling tools like asset_update or transaction_update, leaving the agent to infer usage context entirely from the tool name and schema.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Retrieves historical chart data,' implying a read-only operation, but doesn't specify permissions, rate limits, data format, time ranges, or what 'historical' entails. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, with every part contributing essential information.
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 complexity of retrieving historical data and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'historical chart data' includes (e.g., time periods, chart types, data format), which is crucial for an agent to use this tool effectively. The high schema coverage helps with parameters, but overall context is insufficient.
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?
The input schema has 100% description coverage, with 'assetId' documented as 'Asset ID.' The description adds no additional parameter details beyond implying it's for a 'specific asset,' which aligns with the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding.
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 action ('Retrieves historical chart data') and resource ('for a specific asset'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'dashboard_get_overview' or 'summary_get_period', which might also retrieve dashboard-related data, so it doesn't reach the highest clarity level.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'dashboard_get_overview' and 'summary_get_period' that might retrieve related dashboard or summary data, there's no indication of context, prerequisites, or exclusions for this specific chart retrieval tool.
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 provided, the description carries full burden for behavioral disclosure. While 'Creates' implies a write/mutation operation, the description doesn't mention permission requirements, whether the operation is idempotent, what happens on validation errors, or what the response looks like. For a creation tool with 12 parameters, this leaves significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core purpose without unnecessary words. It's perfectly front-loaded with the essential information. Every word earns its place, making this an excellent example of conciseness.
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?
For a creation tool with 12 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what validation occurs, or what the return value contains. The agent must rely entirely on the parameter schema without understanding the broader transactional context or behavioral expectations.
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?
The input schema has 100% description coverage, providing clear documentation for all 12 parameters including enum values for 'inOutCode'. The description adds no parameter-specific information beyond what's already in the schema. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
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 verb ('Creates') and resource ('new income or expense transaction'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'transfer_create' or 'card_create' which also create financial records, leaving some ambiguity about when to choose this specific creation tool.
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 provides no guidance about when to use this tool versus alternatives like 'transfer_create' or 'card_create'. There's no mention of prerequisites, constraints, or typical use cases. The agent must infer usage from the tool name alone, which is insufficient for optimal tool selection.
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 provided, the description carries the full burden of behavioral disclosure. While 'Deletes' implies a destructive mutation, the description doesn't specify whether deletions are permanent/reversible, require specific permissions, have rate limits, or affect related data. For a destructive tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion tool and front-loads the essential information ('Deletes one or more transactions').
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?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what happens after deletion (confirmation, error handling), whether deletions cascade to related records, or what permissions are required. The combination of destructive operation + minimal structured data demands more descriptive context.
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?
The schema description coverage is 100%, with the single parameter 'ids' clearly documented in the schema as 'Array of transaction IDs to delete'. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for high schema coverage without adding value.
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 action ('Deletes') and resource ('one or more transactions'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'asset_delete' or explain what differentiates transaction deletion from asset deletion, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives like 'transaction_update' or 'asset_delete'. There's no mention of prerequisites, consequences, or appropriate contexts for deletion versus other operations on transactions or related resources.
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 provided, the description carries full burden for behavioral disclosure. It states it 'Lists transactions' which implies a read-only operation, but doesn't address permissions needed, pagination behavior, rate limits, or what format the list returns. For a tool with 4 parameters and no output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward listing tool and front-loads the essential information.
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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the list returns, how results are formatted, whether there are limits on date ranges, or authentication requirements. The minimal description leaves too many contextual questions unanswered.
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 description coverage is 100%, so all parameters are documented in the schema. The description mentions 'date range' which aligns with startDate and endDate parameters, but doesn't add meaningful context beyond what the schema already provides about mbid or assetId. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('Lists') and resource ('transactions') with scope ('within a date range'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'transaction_create' or 'transaction_update', but the listing function is distinct enough from creation/modification operations.
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 provides no guidance on when to use this tool versus alternatives like 'transaction_create' or 'transaction_update'. There's no mention of prerequisites, constraints, or comparative context with other transaction-related tools in the sibling list.
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 provided, the description carries full burden for behavioral disclosure. While 'Transfers money' implies a write/mutation operation, the description doesn't address critical behavioral aspects like authorization requirements, whether the transfer is immediate or scheduled, what happens if assets don't exist, or what confirmation/response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and doesn't contain any unnecessary information or repetition.
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?
For a financial transfer tool with 8 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address the tool's behavior, error conditions, response format, or relationship to sibling tools, leaving significant gaps in understanding how to use it effectively.
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?
With 100% schema description coverage, all 8 parameters are documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions, so it meets the baseline expectation but doesn't provide additional value.
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 action ('Transfers money') and resources ('between two assets'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'transfer_update', which could also involve money transfers between assets.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'transaction_create' and 'transfer_update' available, there's no indication of when this specific transfer creation tool is appropriate versus other financial operations.
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 provided, the description carries full burden but only states retrieval without details on permissions, rate limits, or what 'hierarchical structure' entails. It lacks behavioral traits like whether it's safe, paginated, or has side effects, leaving significant gaps for an agent.
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, efficient sentence that front-loads the purpose without unnecessary words. It could be slightly more structured by including usage hints, but it's appropriately sized for its 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 annotations, no output schema, and a simple tool with 0 parameters, the description is minimal. It states what it does but lacks completeness in behavioral context, return format, or integration with siblings, making it inadequate for full agent understanding.
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?
The tool has 0 parameters with 100% schema description coverage, so no parameter info is needed. The description doesn't add parameter semantics, but this is acceptable as there are no parameters to document, aligning with the baseline for zero parameters.
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 action ('Retrieves') and resource ('all credit cards'), specifying a hierarchical structure. However, it doesn't differentiate from sibling 'asset_list' or 'transaction_list' tools, which also retrieve lists but for different resources, so it misses explicit sibling distinction.
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 provides no guidance on when to use this tool versus alternatives, such as 'asset_list' or 'transaction_list', nor does it mention any prerequisites or context for usage. It's a basic statement of function without operational context.
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 provided, the description carries the full burden of behavioral disclosure. It mentions the output is 'in a hierarchical structure,' which adds some context about the return format, but fails to address critical aspects like whether this is a read-only operation, potential performance impacts for large datasets, authentication requirements, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what an 'asset' is in this context, the format of the hierarchical structure, or any limitations (e.g., pagination, sorting). For a data retrieval tool with no structured support, this leaves significant gaps for an AI agent.
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?
The tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter documentation in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent parameters.
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 verb ('Retrieves') and resource ('all assets'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'card_list' or 'transaction_list' that also retrieve lists of different resource types, so it falls short of a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention why you'd choose 'asset_list' over other list tools like 'card_list' or 'transaction_list', nor does it specify any prerequisites or contextual triggers for its use.
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?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data, implying a read-only operation, but does not disclose behavioral traits such as authentication needs, rate limits, error conditions, or data freshness. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded with the core action and immediately specifies the data included, making it easy for an agent to parse and understand without unnecessary details.
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 lack of annotations and output schema, the description is incomplete. It does not explain the return format, structure of the overview, or any behavioral context needed for reliable use. For a data retrieval tool with no structured support, more detail on output and constraints is warranted.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the data retrieved. A baseline of 4 is applied as it compensates for the lack of parameters by describing the output scope.
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 verb ('Retrieves') and resource ('dashboard overview'), specifying what data is included ('asset trends and portfolio breakdown'). It distinguishes from siblings like 'dashboard_get_asset_chart' by indicating a broader overview rather than a specific chart, though not explicitly contrasting them.
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 provides no guidance on when to use this tool versus alternatives like 'dashboard_get_asset_chart' or 'summary_get_period'. It mentions the data retrieved but does not specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from context.
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?
No annotations are provided, so the description carries the full burden. It states it 'retrieves' data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or what 'initial' means in context (e.g., one-time setup vs. cached data). This leaves gaps for a tool that likely serves critical configuration data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('retrieves') and lists the data components clearly. There is no wasted verbiage, and it directly communicates the tool's purpose without redundancy.
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?
Given the tool's moderate complexity (retrieving multiple data types for application setup), no annotations, no output schema, and 100% schema coverage, the description is minimally adequate. It specifies what data is retrieved but lacks details on behavior, output format, or error handling. For a setup tool with no structured output, more context would be helpful, but it meets the baseline for a read operation.
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 description coverage is 100%, with one optional parameter 'mbid' documented as 'Money book ID.' The description adds no parameter-specific semantics beyond implying it retrieves 'multi-book configuration,' which loosely relates to 'mbid.' Since the schema covers the parameter adequately, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
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 verb 'retrieves' and specifies the resources: 'initial application data including categories, payment types, asset groups, and multi-book configuration.' It distinguishes itself from siblings by focusing on initial setup data rather than CRUD operations on specific entities like assets or transactions. However, it doesn't explicitly contrast with sibling tools like 'dashboard_get_overview' or 'summary_get_period' which might also retrieve data.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., when initial data is needed), exclusions, or comparisons to sibling tools like 'dashboard_get_overview' or 'summary_get_period' that might retrieve overlapping data. The agent must infer usage from the name and description alone.
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 provided, the description carries the full burden of behavioral disclosure. While 'retrieves' implies a read-only operation, it doesn't specify whether authentication is required, what format the statistics are returned in, whether there are rate limits, or if the data is cached. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information about what the tool does.
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?
For a simple read operation with 2 well-documented parameters and no output schema, the description is minimally adequate. However, it doesn't explain what 'financial summary statistics' includes or the return format, which would be helpful given the lack of output schema. The absence of annotations means the description should do more to cover behavioral aspects.
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?
The schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds the context that these parameters define a 'date range' for the financial summary, but doesn't provide additional semantic meaning beyond what the schema already specifies about date format and requirements.
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 with a specific verb ('retrieves') and resource ('financial summary statistics'), and specifies the scope ('for a date range'). It distinguishes itself from siblings like summary_export_excel by focusing on retrieval rather than export, but doesn't explicitly differentiate from dashboard tools that might also provide summaries.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to dashboard_get_overview or summary_export_excel, nor does it specify any prerequisites or constraints beyond the date range requirement implied by the parameters.
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 provided, the description carries the full burden of behavioral disclosure. It reveals important behavioral traits: the server returns HTML-based Excel format, auto-correction of .xlsx to .xls with warnings, and file saving behavior. However, it doesn't disclose whether this is a read-only operation, what permissions are required, whether it's destructive, rate limits, or what happens if the output path already exists.
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 appropriately concise with three sentences that each add value: core functionality, format clarification, and compatibility guidance. It's front-loaded with the main purpose, though the second sentence about HTML-based format could potentially be integrated more smoothly. No wasted words or redundant information.
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?
For a 6-parameter export tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the core functionality and format details well, but lacks information about the return value (beyond format type), error conditions, authentication requirements, or how the exported data relates to other tools. Given the complexity and lack of structured metadata, more behavioral context would be helpful.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it only reinforces the .xls extension recommendation for outputPath that's already in the schema. No additional parameter semantics, constraints, or relationships are explained in the description beyond what the schema provides.
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: 'Exports transaction data to Excel file.' It specifies the resource (transaction data) and action (export to Excel), but doesn't distinguish it from potential sibling tools like summary_get_period or transaction_list that might also retrieve transaction data. The mention of HTML-based Excel format adds specificity but doesn't create clear differentiation.
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 provides no guidance on when to use this tool versus alternatives. While it mentions file extension compatibility details, it doesn't explain when to choose this export tool over other data retrieval tools like summary_get_period or transaction_list, nor does it mention prerequisites or specific use cases for Excel export versus other formats.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It excellently describes critical behavioral traits: the server creates a new transfer with a new ID (not in-place update), the old ID will no longer exist after update, and the need to use transaction_list to retrieve the new ID. This covers mutation behavior, side effects, and workflow implications beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise with just three sentences. The first states the purpose, the second provides critical behavioral warnings, and the third gives practical usage guidance. Every sentence earns its place with essential information, and the warning is appropriately front-loaded.
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?
For a mutation tool with no annotations and no output schema, the description does an excellent job covering behavioral aspects, side effects, and workflow implications. However, it doesn't mention what happens to the old transfer record (whether it's archived, deleted, or marked inactive) or describe the response format, leaving some gaps in completeness.
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 description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide important context about how the 'id' parameter relates to the tool's behavior (old ID vs new ID), which adds some semantic value.
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 specific action ('Modifies an existing transfer') and resource ('transfer'), distinguishing it from sibling tools like transfer_create (creates new) and transaction_update (updates transactions, not transfers). The verb 'modifies' is precise and differentiates from creation or deletion operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: it warns that this creates a new transfer with a new ID instead of updating in-place, and explicitly mentions using transaction_list to get the new ID if needed. This gives clear context about the tool's behavior and prerequisites.
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:

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

Score Badge

Copy to your README.md:

[![money-manager-mcp MCP server](https://glama.ai/mcp/servers/shahlaukik/money-manager-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shahlaukik/money-manager-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/shahlaukik/money-manager-mcp'

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