AI Expense Tracker MCP for logging expenses, searching transactions, and generating budget reports from chat.
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.
Average 3.8/5 across 13 of 13 tools scored. Lowest: 2.7/5.
Tools are mostly distinct with clear purposes. Potential confusion between get_report and get_summary or log_transaction and record_expense is mitigated by detailed descriptions explaining their specific use cases.
All tools follow a consistent verb_noun pattern in snake_case (e.g., delete_transaction, get_report, parse_expense_text), making the set predictable and easy to navigate.
With 13 tools covering CRUD operations, account management, and utility functions, the count is well-scoped for a personal expense tracking server without being excessive.
The tool surface covers essential expense lifecycle operations (create, read, update, delete, restore) and account settings, though a direct get_transaction by ID or bulk operations are missing but not critical.
delete_transactionDelete transactionASoft-delete an existing transaction by ID so it no longer appears in normal spending summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| deleted_reason | No | ||
| transaction_id | Yes | ||
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveness and idempotence hints. Description adds 'soft-delete' nuance and effect on spending summaries, which is valuable beyond structured data.
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?
Single sentence, direct, front-loaded with key action and effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Presence of output schema compensates some gaps. Could mention reversibility via restore_transaction and scope of visibility change. Still fairly complete given tool complexity.
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 low (33%) but description adds no parameter details. Only client_request_id has a schema description; deleted_reason and transaction_id lack context in schema and description.
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 clearly states 'soft-delete an existing transaction by ID' and explains effect on normal spending summaries. Specific verb+resource, distinguishes from restore_transaction which is the undo operation.
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. Siblings like restore_transaction and undo_last_transaction exist but description doesn't differentiate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_connected_accountGet connected accountAReturn the PocketLedger account linked to this chat session, including profile details and connected AI apps. Call when the user asks who they are logged in as, which account is connected, or which apps have access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds value by specifying the scope 'linked to this chat session' and the nature of returned data (profile details, connected AI apps). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose in the first sentence. Every word contributes value with no redundancy. It is maximally concise while covering purpose, usage, and scope.
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 no parameters, strong annotations, and an output schema (signaled), the description is complete. It explains what the tool returns and when to use it, covering all necessary context for this 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?
There are no parameters, so schema description coverage is 100%. The description adds meaning by specifying what the tool returns, which goes beyond the schema. For 0 parameters, a baseline of 4 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 uses a specific verb 'Return' and clearly identifies the resource as 'the PocketLedger account linked to this chat session, including profile details and connected AI apps.' No sibling tool performs this function, so it fully distinguishes from 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 explicitly states three scenarios when to call: 'when the user asks who they are logged in as, which account is connected, or which apps have access.' While it does not specify when not to use or alternatives, the context is clear and sufficient for such a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reportGet spending reportAReturn a grouped expense spending report by category, merchant, day, week, month, or currency, with chart-ready structured data. Do not use the natural-language query as a keyword filter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional natural-language report intent for display/context only. | |
| period | No | Preset reporting period. Use 'custom' only together with date_from and date_to. | |
| date_to | No | ||
| category | No | Expense category name selected from list_categories when possible. | |
| currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| group_by | No | ||
| merchant | No | Merchant or payee name in plain text, preferably in English when the user asks to save in English. | |
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| date_from | No | ||
| chart_type | No | ||
| keyword_filter | No | Explicit keyword filters requested by the user. Do not derive this from the general query text. | |
| reporting_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by stating the output is 'chart-ready structured data' and clarifying the query parameter's role (display/context only), providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the core functionality. Every word serves a purpose, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, 0 required), the description is somewhat minimal. It lacks guidance on parameter interactions (e.g., using date_from/date_to with custom period) and default behavior when no group_by is specified. Output schema exists, so return values are covered, but more context on how parameters combine would improve usability.
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?
With 67% schema description coverage, the description adds important nuance for the 'query' parameter (not a keyword filter). While it doesn't detail every parameter, this key clarifications helps correct usage. The schema itself covers most parameters adequately.
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 resource 'grouped expense spending report', specifying grouping dimensions (category, merchant, day, week, month, currency) and output format (chart-ready structured data). It distinguishes from sibling tools like get_summary by focusing on grouped reports with multiple grouping options.
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 includes a specific instruction: 'Do not use the natural-language query as a keyword filter,' which guides proper parameter usage. However, it does not explicitly compare to sibling tools like get_summary or search_transactions to clarify when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summaryGet spending summaryAReturn a spending summary for expenses in today, yesterday, this week, this month, this year, or a custom date range. Do not create income, transfers, or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | Preset reporting period. Use 'custom' only together with date_from and date_to. | |
| date_to | No | ||
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| date_from | No | ||
| reporting_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns a spending summary and warns against creating records, providing some behavior beyond annotations but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: the first defines the core function, the second sets boundaries. No fluff or 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?
Despite having an output schema, the description omits guidance on using custom date ranges, timezone, or reporting_currency. For a tool with 5 parameters, more context is needed to ensure correct invocation.
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 60%. The description adds no parameter-level meaning beyond what the schema provides (e.g., date_from and timezone lack details). It does not compensate for the missing parameter descriptions.
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 a spending summary for expenses, listing preset periods and custom date range. This distinguishes it from sibling tools that deal with mutations, logs, or reports.
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 includes a negative instruction ('Do not create income, transfers, or financial advice') but lacks explicit guidance on when to use this tool versus alternatives. Usage is implied through the purpose but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesList categoriesAList expense categories available for classifying transactions. This only lists categories and must not be used for investment advice, income creation, or bank credential storage.
| Name | Required | Description | Default |
|---|---|---|---|
| include_custom | No | ||
| include_inactive | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive behavior; the description reinforces this and adds explicit prohibitions, providing full 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?
Two sentences with clear separation of purpose and constraints; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description provides sufficient context for correct 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?
The description does not explain the parameters include_custom and include_inactive; although their names are suggestive, the description provides no guidance on their effect.
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 uses the specific verb 'list' and resource 'expense categories', and explicitly states what the tool should not be used for, making the purpose unambiguous.
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 states the tool's limitation to listing categories and prohibitions, but does not explicitly compare to sibling tools or specify when to use this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_transactionLog transactionACreate one personal expense transaction from explicit structured fields. Expense-only: do not use for income, salary deposits, account transfers, bank credential storage, budgets, investment advice, or calendar tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| note | No | Optional short note to store with the transaction. | |
| amount | Yes | Positive decimal amount encoded as a string. Must not include currency symbols or thousands separators. | |
| source | No | ||
| category | Yes | Expense category name selected from list_categories when possible. | |
| currency | Yes | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| merchant | No | Merchant or payee name in plain text, preferably in English when the user asks to save in English. | |
| timezone | Yes | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| subcategory | No | ||
| category_color | No | ||
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. | |
| duplicate_confirmation | No | Confirmation payload used only after a duplicate transaction warning. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint true and non-destructive nature. The description adds context by reaffirming the creation action and excluding other transaction types, but does not elaborate on side effects or permissions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a distinct purpose: stating the action and setting usage boundaries. No redundant or filler text. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, nested objects) and the presence of an output schema, the description covers the essential context: purpose, scope, and notable exceptions. It could add a brief note on idempotency but is adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (67%), with most parameters having descriptive schema comments. The description adds 'from explicit structured fields' but does not enhance parameter understanding beyond what the schema provides.
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 uses a specific verb ('Create') and resource ('personal expense transaction'), and explicitly limits scope to expenses only, distinguishing it from siblings like record_expense or parse_expense_text. The negative list (do not use for income, etc.) further clarifies purpose.
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?
It clearly states when not to use the tool (income, transfers, etc.) and implies usage for creating expenses from structured fields. While it does not explicitly name sibling alternatives, the negative list provides sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_expense_textParse expense textAParse natural-language expense text without saving it, returning candidate amount, currency, merchant, category, date, and missing fields.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| locale | No | ||
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| date_context | No | ||
| default_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that it returns candidate fields, but since an output schema exists, this is marginal extra 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 a single, front-loaded sentence that efficiently conveys purpose without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema documents return values and annotations cover behavioral traits, the description provides sufficient context for a parse tool. It lacks details on error handling but is complete for its intended 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 40% (only timezone and default_currency have descriptions). The tool description does not explain any parameters (e.g., text, locale, date_context), so it fails to compensate for the low coverage.
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 action (parse), the resource (natural-language expense text), and the outcome (returns candidate fields). It explicitly distinguishes itself from sibling tools like record_expense by noting 'without saving it'.
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 when to use the tool: to preview parsed data without saving. It mentions 'without saving it', which hints at alternatives that do save (e.g., record_expense), but does not explicitly list when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_expenseRecord expenseARecord one personal expense from natural-language text. Expense-only: do not use for income, salary deposits, account transfers, bank credential storage, budgets, investment advice, or calendar tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| locale | No | BCP 47 locale hint for parsing user text. | |
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| date_context | No | Reference date in YYYY-MM-DD used to resolve relative dates. | |
| category_color | No | ||
| default_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. | |
| duplicate_confirmation | No | Confirmation payload used only after a duplicate transaction warning. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds context by mentioning the optional idempotency key (client_request_id). However, it fails to disclose the duplicate confirmation behavior (duplicate_confirmation parameter) which is a significant behavioral trait requiring user interaction. With annotations covering the base safety profile, score 3 is appropriate for the missing duplication warning 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?
Two sentences with zero wasted words. The first sentence states the core action, the second provides clear do-not-use guidance. Front-loaded and efficient.
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?
Considering the tool's complexity (8 parameters, nested objects, output schema), the description covers the main purpose and usage boundaries. It omits the duplicate confirmation flow, which is a detailed aspect. However, output schema exists to describe return values, and annotations cover base behaviors. Almost complete for a recording tool, missing only confirmation guidance.
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 75%, so the baseline is 3. The description adds value by explaining the text parameter indirectly ('natural-language text') and the overall purpose. For uncovered parameters like category_color, no additional meaning is provided. The description does not significantly enhance understanding beyond what the schema already documents.
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 'Record' and the resource 'personal expense', and specifies that input is natural-language text. It explicitly excludes non-expense use cases (income, transfers, etc.) and mentions the input format, distinguishing it from sibling tools like log_transaction.
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?
Provides explicit usage boundaries: 'Expense-only: do not use for income, salary deposits, account transfers, bank credential storage, budgets, investment advice, or calendar tasks.' This tells the agent exactly when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
restore_transactionRestore transactionARestore a previously deleted transaction by ID so it appears in spending summaries again.
| Name | Required | Description | Default |
|---|---|---|---|
| transaction_id | Yes | ||
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds that the transaction will appear in spending summaries, but does not disclose what happens if the transaction is not deleted or already restored. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is brief, direct, and contains no extraneous information. Every word earns its place.
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 presence of output schema and annotations, the description is mostly complete. It clearly states the outcome. However, it could be enhanced by explicitly noting that the transaction must have been previously deleted for the operation to succeed.
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?
With 50% schema coverage, the description does not elaborate on either parameter. The client_request_id parameter has a schema description, but transaction_id lacks one in the schema and the description does not compensate by explaining its purpose beyond the implicit ID usage.
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 'Restore', the resource 'transaction', and the effect 'appears in spending summaries again'. It distinguishes from sibling tools like delete_transaction (opposite) and undo_last_transaction (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after a transaction has been deleted, but it does not explicitly state when to use this versus alternatives like undo_last_transaction, nor does it mention prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_transactionsSearch transactionsASearch a user's saved expense transactions by date range, category, merchant, keyword, currency, deleted status, and limit. Do not use for investment advice, income creation, bank credential storage, or calendar tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| period | No | Preset reporting period. Use 'custom' only together with date_from and date_to. | |
| date_to | No | ||
| keyword | No | ||
| category | No | Expense category name selected from list_categories when possible. | |
| currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| merchant | No | Merchant or payee name in plain text, preferably in English when the user asks to save in English. | |
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| date_from | No | ||
| include_deleted | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, so the description adds no behavioral context beyond listing filter types. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, but the second sentence about prohibited uses feels slightly misplaced for this tool's core function.
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?
For a tool with 11 parameters, pagination (cursor) is not mentioned in the description, though an output schema exists. The description is adequate for basic understanding but misses key 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 description coverage is only 45%, and the main description merely lists filter categories without adding syntax, format, or parameter-specific details. Parameters like cursor, date_from, and include_deleted lack schema descriptions and are not elaborated.
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 'Search a user's saved expense transactions' with specific filter parameters, distinguishing it from sibling tools like delete_transaction, log_transaction, etc.
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 includes a negative directive ('Do not use for investment advice...'), but does not provide positive guidance on when to use this tool versus alternatives like get_summary or get_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undo_last_transactionUndo last transaction actionCUndo the most recent supported transaction action, such as create, update, delete, or restore, within the undo window.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | No | ||
| transaction_id | No | ||
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. | |
| confirmation_token | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true in annotations, the description aligns by implying mutation ('undo') but adds no additional behavioral context. It omits details like whether the undo is reversible, what happens if no recent action exists, the size/time limits of the undo window, or whether confirmation is required. The description does not enhance understanding beyond the annotation.
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, making it concise and front-loaded. However, its brevity sacrifices detail: it contains only 15 words and does not leverage structure (e.g., bullet points) to cover essential aspects like parameters or behavior. It is minimally adequate but not well-structured.
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 complexity (4 parameters, output schema, and 13 sibling tools), the description is incomplete. It does not explain what the undo window is, what the output contains, how parameters interact, or when the tool is applicable. The context signals (e.g., output schema exists) are not leveraged to reduce description burden.
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 low (25%), with only client_request_id described. The tool description adds no explanation for the four parameters: operation, transaction_id, client_request_id, and confirmation_token. The agent receives no guidance on their purpose or usage, forcing reliance on parameter names and enums alone.
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 ('undo') and resource ('most recent supported transaction action'), listing example actions (create, update, delete, restore) and specifying the scope ('within the undo window'). It effectively distinguishes from sibling tools like delete_transaction or restore_transaction by focusing on the most recent action rather than a specific transaction.
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 explicit guidance on when to use this tool versus alternatives, such as delete_transaction or restore_transaction. It does not mention prerequisites (e.g., an action must exist within the undo window) or caution against misuse, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_account_settingsUpdate account settingsAUpdate the authenticated user's PocketLedger defaults for expense currency, reporting currency, timezone, and locale. Use this for account preferences only, not transaction edits, wallet balances, payments, or subscriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| default_locale | No | BCP 47 locale used for account defaults, e.g. 'en-US', 'tr-TR', or 'fa-IR'. | |
| default_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| default_timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| reporting_currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds that the tool updates the 'authenticated user's' settings, implying authentication requirements. It does not elaborate on side effects or idempotency, but the annotations cover the key safety traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose, then usage guidance. Very concise.
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?
For a simple update tool with a comprehensive schema and output schema, the description covers purpose and usage guidelines adequately. It does not mention return values (but output schema exists) or prerequisites beyond 'authenticated user'. Minor gap: could explicitly state that only the authenticated user's settings are affected.
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 100% description coverage for all 4 parameters. The tool description adds no additional parameter meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'account settings' for PocketLedger defaults, listing specific fields (expense currency, reporting currency, timezone, locale). It also distinguishes from sibling tools by explicitly excluding transaction edits, wallet balances, payments, and subscriptions.
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 explicit when-to-use ('account preferences only') and when-not-to-use ('not transaction edits, wallet balances, payments, or subscriptions'), helping the agent decide. It does not name alternative tools directly but the exclusion list is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_transactionUpdate transactionCUpdate an existing transaction by ID, changing fields such as amount, currency, merchant, category, date, timezone, or note.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| note | No | Optional short note to store with the transaction. | |
| amount | No | Positive decimal amount encoded as a string. Must not include currency symbols or thousands separators. | |
| category | No | Expense category name selected from list_categories when possible. | |
| currency | No | ISO 4217 currency code, e.g. USD, EUR, GBP. | |
| merchant | No | Merchant or payee name in plain text, preferably in English when the user asks to save in English. | |
| timezone | No | IANA timezone used to interpret dates and relative words like today or yesterday, e.g. 'UTC'. | |
| subcategory | No | ||
| category_color | No | ||
| transaction_id | Yes | ||
| client_request_id | No | Optional idempotency key. Omit for normal one-off calls. | |
| expected_updated_at | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, so description's 'update' is consistent. But fails to explain optimistic concurrency via expected_updated_at, partial update behavior, or what happens if transaction_id not found.
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?
Single sentence, concise and front-loaded with verb and resource. Could be slightly more structured but acceptable.
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 12 parameters and output schema, description is too brief. Omits important details like partial update semantics, idempotency via client_request_id, and concurrency control.
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?
Description lists several parameters (amount, currency, etc.) but doesn't explain their significance beyond the schema. 58% schema coverage means description adds some but limited value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates a transaction by ID and lists example fields. However, it doesn't explicitly state that any field from the schema can be updated, which is inferred but not fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like delete_transaction or log_transaction. Lacks context on prerequisites or scenarios.
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.
No comments yet. Be the first to start the discussion!
