Zenfinance
Server Details
Household finance memory, budgets, transactions, and monthly reviews for AI assistants.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 16 of 16 tools scored. Lowest: 3.5/5.
Each tool targets a specific action and entity (transaction, category, budget, org, etc.). There is minimal overlap; even similar tools like get_monthly_summary and get_transactions serve different purposes (curated dashboard vs. raw data).
All tools follow a consistent verb_noun pattern using snake_case (e.g., archive_transaction_category, create_org, get_user_context). No mixing of conventions.
16 tools is well-scoped for a personal finance management server. Each tool covers a necessary function without bloat or deficiency.
The tool set covers the main domain operations: full CRUD for transactions and categories, budget management, org management, and user context. Minor gaps like account management are indirectly covered via get_user_context, but could be more explicit.
Available Tools
16 toolsarchive_transaction_categoryArchive transaction categoryADestructiveInspect
Retire a category so it no longer appears in active lists. Use when a category is no longer relevant; existing transactions keep their category link. Prefer over deletion — archiving is reversible at the DB level and preserves history. Do not archive if you intend to reclassify its transactions first.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| category_id | Yes | Category tag UUID from get_user_context.orgs[].categories[].id. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but description adds nuance by stating historical links are preserved, clarifying non-destructive nature beyond the annotation's binary indication. 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?
Single sentence with critical information front-loaded; 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?
Given 100% parameter schema coverage and presence of output schema, the description suffices for agent understanding of this straightforward 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?
Schema covers all parameters with clear descriptions; the tool description adds minimal extra meaning ('for future use'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('archive'), resource ('category'), and key effect ('preserving historical transaction links'), distinguishing it from sibling tools like delete_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?
No explicit guidance on when to use archive vs alternatives (e.g., delete or edit) is provided. The description implies use for future archival but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_orgCreate organizationAInspect
Create a Zen household/personal org when none exists or the user explicitly needs another one. Caller is owner; returns refreshed workspace context.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Org display name. | |
| purpose | No | Org purpose: household, personal, business, or other. | household |
| base_currency | Yes | ISO 4217 org base currency for goals and rollups (e.g. BRL). | |
| jurisdiction_country | Yes | ISO 3166-1 alpha-2 tax residence (e.g. BR). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the caller becomes owner and returns refreshed workspace context, adding value beyond annotations. Annotations already indicate non-readonly and non-destructive, and the description aligns with them. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly packed with essential information: purpose, condition, ownership, and return. No 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?
For a creation tool with good annotations and output schema, the description covers purpose, usage condition, ownership, and return value. It could elaborate on potential side effects or uniqueness constraints, but overall it is adequate.
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 input schema already provides detailed descriptions for 3 of 4 parameters (75% coverage). The description adds no parameter-specific meaning, 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.
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 ('Zen household/personal org'), clearly distinguishing it from sibling tools which are transaction-related. The condition 'when none exists or the user explicitly needs another one' adds further clarity.
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 when to use the tool: when no org exists or the user explicitly needs another one. This provides clear context and helps the agent decide between this tool and potential alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_transaction_categoryCreate transaction categoryAInspect
Create a household-specific transaction category. Check list_transaction_categories first — avoid creating duplicates of existing ones. The slug is normalized to lowercase and permanent; only display metadata can be edited later. Use archive_transaction_category to retire a category, which frees the slug for reuse.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Category kind: income, expense, or transfer. | |
| name | Yes | New category slug/code source. DB normalizes to lowercase [a-z0-9_], rejects duplicates, and reserves system parent names income/expense/transfer. | |
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| aliases | No | Optional classifier aliases/synonyms. Defaults to an empty list. | |
| examples | No | Optional example merchants or phrases for classification. Defaults to an empty list. | |
| description | No | Optional human-readable category description. | |
| display_name | No | Optional user-facing display name. Omit/null to use the stable slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only, not destructive, and not idempotent. The description adds useful context about slug stability and tombstoning upon archive, which is beyond annotations. However, it does not fully disclose all behaviors (e.g., duplicate handling beyond what is in param schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core action. Every sentence provides essential information without redundancy or fluff.
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 an output schema and detailed param descriptions, the description is largely complete for a creation tool. It could be improved by including usage guidance to differentiate from sibling tools.
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 86%, so the schema already documents most parameters well. The description adds no parameter-specific information beyond the schema, meeting the baseline for high 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 'Create an org-level income/expense/transfer child category', specifying the verb ('create'), resource ('category'), and scope ('org-level'), which distinguishes it from sibling tools like archive, edit, or list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creating new categories but does not explicitly state when to use this vs. alternatives (e.g., edit or archive), nor does it provide prerequisites or exclusions. The context of sibling tools is present but not leveraged in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_transactionDelete transactionsADestructiveInspect
Delete one or more saved Zen transactions in a single call. Accepts up to 500 transaction IDs. Useful for removing an entire duplicated statement import. Each deletion is committed independently (partial success is possible). Use before recreating when expense/income direction is wrong.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| transaction_ids | Yes | List of transaction UUIDs from get_transactions().transactions[].id to delete. Each deletion is committed independently — a failure on one ID does not affect others. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable detail about independent partial success and batch limit beyond the schema.
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?
Four sentences, front-loaded with purpose, no fluff. Could be slightly more concise but efficient overall.
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?
Covers limits, partial success, and usage rationale. Output schema handles return values. Adequate for a destructive batch 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?
Schema description coverage is 100% and the description adds only minor context (use case for duplicate imports). Baseline is 3; not enough extra value to raise.
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 deletes transactions and accepts up to 500 IDs, specifying the resource (transactions) and action (delete). It differentiates from siblings like edit_transaction and save_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 specific use cases: removing duplicated statement imports and fixing wrong expense/income direction. Does not explicitly state when not to use or alternatives, but the context of sibling tools covers that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_transactionEdit transactionsAInspect
Edit one or more saved Zen transactions in a single call. Accepts a list of up to 500 edits — each item targets one transaction by ID and specifies date, amount, category, description, counterparty, and/or tags. Useful after bad imports where many rows need the same correction. Each edit is committed independently (partial success is possible). For income<->expense direction flip, delete the wrong row and save a new one. tag_ids: null=no change, []=clear all tags, [uuid,...]=replace all tags.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| transactions | Yes | List of edits to apply. Each item targets one transaction by ID and specifies only the fields to change. Omit/null fields are left unchanged. Each item is committed independently — a failure on one item does not roll back others. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only show mutability and non-destructiveness. Description adds key behaviors: each edit is committed independently (partial success), field omission leaves unchanged, and precise tag_ids semantics (null, empty array, list).
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?
Five sentences with no wasted words. Front-loaded main purpose, then details. Well structured 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?
Given complexity of batch editing with partial success and multiple fields, the description covers all essential aspects: batch size, field behavior, direction flip exception, tag_ids handling, and org_id source. Output schema exists per context, so return values are handled.
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 covers 100% of parameters. Description adds value by clarifying batch limit (500), independence of edits, and tag_ids behavior. The org_id source is reinforced. Could be 5 but schema already strong.
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 ('Edit'), resource ('saved Zen transactions'), and scope ('one or more... in a single call'). It distinguishes from siblings like 'save_transaction' (single) and 'delete_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?
Explicitly suggests when to use ('useful after bad imports') and when not to use ('For income<->expense direction flip, delete and save a new one'). Also notes partial success possibility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_transaction_categoryEdit transaction categoryAInspect
Update a category's display label, description, examples, or aliases. Use to localize category names to the household's language or to improve classification guidance. Does not change the stable slug or kind — use create + archive to replace a category with a different kind.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| aliases | No | Optional replacement aliases array. Omit/null to keep current aliases; pass [] to clear. | |
| examples | No | Optional replacement examples array. Omit/null to keep current examples; pass [] to clear. | |
| category_id | Yes | Category tag UUID from get_user_context.orgs[].categories[].id. | |
| description | No | Optional replacement description. Omit/null to keep current value; pass empty string to clear. | |
| display_name | No | Optional replacement display name. Omit/null to keep current value; pass empty string to clear. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by clarifying that slug/name and kind remain unchanged. Annotations (readOnlyHint=false) are consistent with a write operation. No contradictions. Could mention update semantics (partial update) but overall good 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?
Single sentence, front-loaded with key constraint, no wasteful words. Perfectly concise for a simple edit operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With good schema, annotations, and output schema, the description covers the essential scope. Could explicitly state partial update behavior (optional fields default null) but not critical. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 6 parameters. Description does not add significant new meaning beyond confirming it's display metadata. Baseline 3 is appropriate as the schema carries the load.
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 states 'Edit category display metadata only. Slug/name and kind remain stable.' Clearly defines what is edited and what is not, distinguishing it from sibling tools like archive_transaction_category or create_transaction_category.
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?
Usage is implied by stating it edits only display metadata, but no explicit guidance on when to use this tool vs alternatives like create_transaction_category for new categories or archive_transaction_category for deactivation. Could explicitly state that it's for updating display fields only, not for changing core attributes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_budget_statusGet budget statusARead-onlyIdempotentInspect
Read saved Zen budget vs actual for a given month. Use 'mapped so far' language if account/category coverage may be incomplete.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Year of the month to analyse (e.g. 2026). | |
| month | Yes | Month of the year to analyse (1-12). | |
| org_id | Yes | Org UUID from get_user_context.orgs[].id. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds context about reading budget vs actual and the possibility of incomplete coverage, which is valuable beyond 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 concise sentences: first defines purpose, second provides a usage tip. 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?
Output schema exists, so description need not detail return values. The description, combined with annotations and schema, sufficiently covers the tool's behavior and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for all three parameters. The description does not add significant meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'saved Zen budget vs actual for a given month.' It distinguishes from sibling tools like set_budget and get_monthly_summary.
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 gives a usage hint about using 'mapped so far' language when coverage may be incomplete, but does not explicitly state when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monthly_summaryGet monthly summaryARead-onlyIdempotentInspect
Preferred Zen family-facing monthly dashboard: curated Made/Spent/Saved, prior-month comparison, category/budget drivers, bursts, and transactions. Use before ad-hoc raw analysis for month reviews; say mapped so far unless coverage is complete.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Year to analyse (e.g. 2026). | |
| month | Yes | Month to analyse (1-12). | |
| org_id | Yes | Org UUID from get_user_context.orgs[].id. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent. Description adds value by listing what the summary includes (comparison, drivers, etc.), but doesn't detail edge cases or limitations. Good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no filler. First sentence defines output, second provides usage guidance. Optimal length.
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 read-only tool with three parameters and no output schema, the description covers key outputs and usage context. Instructions on when to use ensure completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are self-explanatory. Description does not add further meaning to parameters, meeting baseline expectation.
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 it provides a curated monthly dashboard with specific metrics (Made/Spent/Saved, prior-month comparison, drivers, bursts, transactions). Differentiates from siblings like get_transactions by positioning itself as a preferred summary before raw analysis.
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?
Explicitly states 'Use before ad-hoc raw analysis for month reviews' and gives guidance on phrasing ('say mapped so far unless coverage is complete'). Clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactionsGet transactionsARead-onlyIdempotentInspect
Read saved Zen transaction lines for one org/date range. Use before analysis and before fixing user-reported wrong data; results are mapped so far, not complete financial truth.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| end_date | No | Exclusive ISO 8601 end date. Defaults to now if omitted. | |
| start_date | No | Inclusive ISO 8601 start date. Defaults to start of current month if omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, openWorldHint: true, and idempotentHint: true. The description adds valuable behavioral context: 'results are mapped so far, not complete financial truth,' indicating the data may be incomplete or preliminary. This goes beyond what annotations provide, though it does not detail other traits like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose and scope, and includes usage guidance and a caveat. There is no redundant or extraneous text.
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 an output schema (not shown but indicated) and comprehensive annotations covering read-only, open-world, and idempotency, the description is complete. It covers what the tool does, when to use it, and a key limitation. No additional context is necessary for an agent to safely invoke this 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?
Schema description coverage is 100% – all three parameters have clear descriptions with defaults and source for org_id. The description itself does not add new information about parameters beyond what the schema already provides. Therefore, a 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 'Read saved Zen transaction lines for one org/date range.' It uses a specific verb (Read), identifies the resource (saved Zen transaction lines), and specifies the scope (one org/date range). This distinguishes it from sibling tools like save_transaction, delete_transaction, and edit_transaction, which are all write operations.
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 usage guidance: 'Use before analysis and before fixing user-reported wrong data.' It also warns that 'results are mapped so far, not complete financial truth,' which helps set expectations. While it does not mention specific alternatives or when not to use, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_user_contextGet user workspaceARead-onlyIdempotentInspect
Start here for Zen requests. Returns saved household context (org IDs, categories, accounts, budgets, currencies, invites) plus the advisor skill — your operating guide for Zen's family-office mission and how to advise well.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context by specifying the exact content returned (household context, advisor skill) and its role as an operating guide, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two sentences that immediately convey the tool's purpose ('Start here') and its output. Every sentence is necessary and adds value, making it easy to parse quickly.
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 and an existing output schema, the description adequately covers what the tool does and what it returns. It mentions key contents (org IDs, categories, accounts, etc.) and the advisor skill. It is complete enough for an agent to decide to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to explain parameter semantics. The description adds no parameter information, which is acceptable since none exist. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start here for Zen requests' and lists the returned context (org IDs, categories, accounts, etc.) plus advisor skill. It distinguishes itself from sibling tools like get_transactions or save_transaction by being a context-gathering starting point.
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 advises users to 'Start here for Zen requests', indicating when to use this tool first. While it doesn't provide explicit when-not-to-use or alternatives, the instruction is clear and sufficient given the tool's role as an initial context gatherer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
invite_memberInvite organization memberAInspect
Invite a user by email to an org. Caller must be an owner; DB enforces this. Ask invitee to call get_user_context.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to invite. | ||
| org_id | Yes | Org UUID from get_user_context.orgs[].id. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-destructive operation. The description adds useful context: the DB enforces ownership and suggests a follow-up action for the invitee. This enhances transparency without contradicting 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 long, front-loads the purpose, and contains no extraneous information. Every sentence adds value.
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 invite tool with two parameters and an output schema, the description covers purpose, precondition, and post-action. It is fully adequate for an agent to understand usage and consequences.
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 100% schema description coverage, the baseline is 3. The description does not add new parameter semantics beyond the schema, which already provides adequate descriptions and constraints for both email and org_id.
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 'Invite a user by email to an org' with a specific verb and resource. It distinguishes from siblings like create_org and respond_invitation, making the tool's 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 specifies that the caller must be an owner (precondition) and advises the invitee to call get_user_context (post-action). However, it does not explicitly state when to use this tool versus alternatives, which is partially mitigated by the unique action of inviting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_transaction_categoriesList transaction categoriesARead-onlyIdempotentInspect
List org-level transaction categories. Use before creating a category to check for duplicates, or when inspecting archived categories before migrating their transactions. Read-only. Prefer get_user_context for active categories during normal workflows — use this tool when you need archived or full category detail.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| status | No | Which org-level categories to return. Use archived/all to inspect old categories before deciding whether to migrate their transactions. | active |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds the ability to include archived categories, which is consistent. No additional behavioral details (e.g., pagination, permissions) are disclosed beyond what annotations provide.
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 that immediately conveys the core purpose. No redundant words. Front-loaded with action and resource.
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 output schema exists, there is no need to describe return values. The description covers the main use case and status filter. The tool is simple, and all necessary information is provided through schema and description combined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions 'by status', echoing the status parameter but adding minimal nuance ('including archived on request'). This does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List'), resource ('org-level transaction categories'), and filtering capability ('by status, including archived categories on request'). It accurately reflects the tool's purpose and distinguishes it from sibling tools like 'create_transaction_category' or 'archive_transaction_category'.
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 implicitly indicates when to use the tool (when needing to view categories), but lacks explicit guidance on when not to use it or how it compares to alternatives like 'get_transactions' or other category tools. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
report_feedbackReport raw feedbackAInspect
File a concise, non-sensitive product observation from this session — bugs, gaps, praise, or feature ideas. Use proactively when you notice a product limitation, tool mismatch, or missing capability; do not wait for the user to ask. Write-only surface: inserts into feedback_reports; no read tool exists today.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Product area this feedback relates to: onboarding, mcp_setup, household_setup, transactions, imports, categorization, budgets, monthly_summary, privacy_trust, pricing, performance, or other. | |
| kind | Yes | Feedback type: issue, suggestion, praise, question, rating, or observation. | |
| title | Yes | Short feedback summary. | |
| client | No | Optional MCP client name, e.g. claude_desktop. | |
| org_id | No | Optional org UUID from get_user_context.orgs[].id; omit for setup feedback before an org exists. | |
| details | Yes | Markdown feedback details. Use short bullets/sections; do not include sensitive raw financial data, credentials, tokens, or full private conversation excerpts. | |
| severity | No | Issue severity: low, medium, high, or critical. | medium |
| sentiment | No | Overall sentiment: positive, neutral, negative, or mixed. | neutral |
| source_tool | No | Optional related MCP tool name, e.g. save_transaction. | |
| rating_scale | No | Optional rating scale label, e.g. nps_0_10 or stars_1_5. Must be paired with rating_score. | |
| rating_score | No | Optional numeric score, e.g. NPS 0-10. Must be paired with rating_scale. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint false) but description adds no behavioral details beyond content constraints. No mention of auth, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one sentence plus restriction), front-loaded with action. Could benefit from structured bullet points but 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?
Does not describe output or side effects. With an output schema present but not shown in description, agent lacks understanding of what filing feedback returns.
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 64%, and schema already describes most parameters. Tool description adds only a general prohibition that overlaps with 'details' field 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?
The description clearly states the verb 'file' and resource 'pilot feedback', with constraints 'concise, non-sensitive'. It distinguishes from sibling tools, none of which relate to feedback.
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 content restrictions: do not include raw financial data, credentials, tokens, or private excerpts. Lacks when-not-to-use guidance but is clear for its intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
respond_invitationRespond to organization invitationAInspect
Accept or deny a pending invitation from get_user_context.invites. Accept creates a named member with role member.
| Name | Required | Description | Default |
|---|---|---|---|
| decision | Yes | 'accept' to join the org as a member, or 'deny' to decline. | |
| invitation_id | Yes | Invitation UUID from get_user_context.invites[].id. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive write operation. The description adds that acceptance creates a named member with role 'member', but does not detail deny behavior or potential side effects. 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 focused sentences: first defines the action and source, second explains the consequence of acceptance. No redundant 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 presence of an output schema, the description adequately covers the main behavior. Could mention idempotency or error scenarios, but not essential for a simple response 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?
Schema describes 'invitation_id' as a UUID from get_user_context, and the description reinforces this. For 'decision', the description explains that 'accept' creates a member, adding meaning beyond the enum values. With 50% schema coverage, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool accepts or denies a pending invitation, with the specific consequence of creating a member on accept. Distinguishes from sibling 'invite_member' which handles creating invitations.
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?
Explicitly ties to pending invitations from 'get_user_context.invites', guiding the agent on source and prerequisite. Does not explicitly mention when not to use, but context and siblings make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_transactionSave transactionsAInspect
Persist income/expense lines as saved Zen data. Use after reading a user-provided statement, PDF, or described transactions — not to correct existing rows (use edit_transaction for that, or delete + recreate for direction flips). Groups lines under one operation; cashflow is attributed to operation_date month, not today.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | No | Bank or institution name, e.g. 'Itaú' or 'Nubank'. | |
| notes | No | Free-text notes about this operation batch; include statement period, assumptions, skipped lines, or uncertainty, not raw private statement text. | |
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| source | No | Origin of this batch, e.g. 'credit_card_pdf' or 'bank_statement_csv'. | |
| file_name | No | Original filename of the imported document, e.g. 'abril_2026.pdf'. | |
| card_last4 | No | Last 4 digits of the card if this batch is from a card statement. | |
| transactions | Yes | Transaction lines to save under one Zen operation. Each item must include direction ('income' or 'expense'), amount, and category_id from get_user_context. When a user provides many files or a full year, process them without forcing one-file-at-a-time back-and-forth; group saves by source file or statement/bill period when useful for metadata and review. Omit account_id to use the Phase 1 default account. For credit-card bills, exclude previous-bill payment/total lines, save only installments present on this bill, fold clearly linked per-item taxes/fees into the purchase amount when supported by the statement/jurisdiction, skip fee/reimbursement ONLY when BOTH the original charge AND its refund for the same amount appear on the same bill (a true pair) — a standalone credit, estorno, or reimbursement that has no matching charge on this bill must be saved as income, not skipped, and do not invent FX rates; preserve original currency/amount in notes when not normalized. Optional fields: date, account_id, description, counterparty, statement_line_id. | |
| operation_date | No | ISO date or timestamp for the operation. Drives which month the batch shows up in on monthly cashflow reports; the per-transaction date stays the actual purchase date. Rules: for a single transaction or a same-period batch, set to the transaction date so a late-recorded purchase does not drift into today's month. For a credit card invoice: if the payment date falls in a different month than the invoice period (e.g. April invoice paid in May), use the close date — this keeps the batch in the correct spending month, not the payment month; if the payment date falls within the same month as the invoice period, use the payment date (actual cashflow, no misattribution). Leave null only when truly uncertain; the server defaults to now(). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds significant behavioral context: batch processing, grouping by source/period, summarizing saved data, and asking for review/correction. This goes beyond the annotations and helps the agent understand the tool's interactive nature.
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, efficiently covering purpose and key behavior. It is front-loaded and concise. However, it could be slightly more structured for clarity, e.g., separating purpose and guidelines.
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 (8 params, nested objects), the description provides sufficient context for overall workflow: batch processing, grouping, and review. The presence of an output schema reduces the need to explain return values. The description does not cover edge cases or all schemas details, but the schema itself handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds little beyond the schema, only reiterating high-level grouping. According to the rubric, baseline is 3 when coverage is high, and the description does not significantly enhance parameter understanding.
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 it persists income/expense lines as saved data, differentiating from sibling edit/delete tools. It mentions batch processing and grouping, making the purpose evident. However, it could be more explicit about being a creation tool vs. update, and it does not explicitly compare to alternatives.
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 does not provide when-to-use or when-not-to-use guidance. It does not mention alternatives like edit_transaction or delete_transaction. The agent is left to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_budgetSet category budgetsAIdempotentInspect
Set saved Zen monthly budgets for one or more categories. History is captured automatically; explain the effective month to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | Yes | Org UUID from get_user_context.orgs[].id. | |
| budgets | Yes | Budget entries to set or update. Each item must include category_id and amount. enabled defaults to true. Use amount=0 with enabled=false to disable a category budget. | |
| valid_from | No | ISO date (YYYY-MM-DD) for the first day of the month this budget takes effect. Defaults to the first of the current month. Pass a past/future date to set budgets retroactively or in advance. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) with idempotency. The description adds value by noting that history is captured automatically and instructs the agent to explain the effective month to the user, which are useful behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the primary action. Every sentence adds value without unnecessary detail.
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 (3 parameters, nested object, output schema exists), the description covers the core purpose and adds user guidance. It could mention overwrite behavior, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides for parameters like org_id, budgets, and valid_from.
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 sets monthly budgets for categories. It uses a specific verb 'set' and distinguishes from reading tools like get_budget_status.
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 lacks explicit guidance on when to use this tool vs alternatives. It does not mention when not to use it or provide comparisons to sibling tools like get_budget_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!