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.5/5 across 16 of 16 tools scored.
Each tool targets a distinct resource and action: transaction categories have create/archive/edit/list; transactions have save/get/edit/delete; budgets have set and status; plus distinct tools for org management, invitations, and user context. No overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_transaction_category, delete_transaction, get_budget_status). No mix of styles or vague verbs.
With 16 tools covering categories, transactions, budgets, org setup, invitations, and feedback, the count is appropriate for a personal finance server. Each tool serves a clear purpose without being overwhelming.
The tool surface covers core CRUD for transactions and categories, budget management, and org administration. Minor gap: no tool for managing accounts (e.g., create/update) beyond what's returned in get_user_context, but this may be by design for external account linking.
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, and the description adds context: archiving preserves history and is reversible at the DB level, which goes beyond annotations. No contradiction with annotations; readOnlyHint=false is consistent.
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 three sentences, each serving a distinct purpose: stating the action, providing usage guidance, and issuing a warning. No wasted words, front-loaded with the main purpose.
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 only 2 required parameters, a clear purpose, and an output schema, the description covers all necessary aspects: behavior, usage, and constraints. It is complete for effective selection and 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 100%, so the schema already explains both parameters. The description does not add significant extra detail about parameters beyond what the schema provides, meeting the 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?
The description clearly states the action ('retire a category'), the resource ('category'), and the effect ('no longer appears in active lists'). It distinguishes from siblings like 'delete_transaction' or 'edit_transaction_category' by focusing on archiving behavior.
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 says when to use ('when a category is no longer relevant'), provides an alternative ('prefer over deletion'), and gives a reason (reversible). It also includes a negative instruction ('do not archive if you intend to reclassify its transactions first').
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?
Annotations provide basic flags (readOnlyHint=false, etc.). Description adds that caller is owner and returns refreshed workspace context, which is helpful 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 sentences, front-loaded with purpose and condition, then ownership and output. No 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?
Tool has reasonable complexity; schema fully describes 4 parameters with outputs noted; description covers when to use and what to expect. Complete for a creation 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 has 100% parameter coverage with individual descriptions (e.g., 'Org display name.'). Description adds no additional parameter detail beyond what 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?
Description clearly states 'Create a Zen household/personal org' with specific conditions (when none exists or user needs another). Distinguishes from sibling tools which are mostly transaction-related.
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 says when to use: when no org exists or user needs another. Implicitly suggests not to create duplicates unnecessarily. Also notes caller becomes owner and returns refreshed context.
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?
The description discloses key behavioral traits: slug normalization to lowercase/permanence, only display metadata editable later, and that archiving frees the slug for reuse. Annotations (readOnlyHint=false, etc.) do not contradict, and the description adds significant value beyond annotations by explaining side effects and constraints.
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?
Three sentences, each earning its place: first defines purpose, second gives usage context, third explains slug behavior and archival. No redundancy, front-loaded with the key action.
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 7 parameters (3 required), 1 enum, and an output schema, the description covers the essential context for selection: when to use, what side effects exist, and how it relates to siblings. With full schema coverage, no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters adequately. The description does not add additional per-parameter meaning beyond what is in the schema, thus a score of 3 is appropriate (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 the tool's function ('Create a household-specific transaction category') with a specific verb and resource. It distinguishes itself from sibling tools like list_transaction_categories and archive_transaction_category by advising to check for duplicates and noting the archive mechanism, making it clear when to use this tool.
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 guidance: check list_transaction_categories first to avoid duplicates, and use archive_transaction_category to retire a category. This tells the agent when to use the tool and when not to, with clear alternatives.
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 declare destructiveHint=true, so the destructive nature is known. The description adds valuable behavioral context: each deletion is committed independently, meaning partial success is possible. This goes 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 very concise: four sentences that start with the main action, then add key limits, use cases, and behavioral notes. 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?
With annotations and output schema presumably covering return values, the description is complete for understanding the tool's main behavior and typical use. Minor lack of when-not-to-use guidance, but still solid.
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 parameters are already well-documented in the schema. The description adds marginal context (e.g., 'up to 500 transaction IDs' is also in schema) but 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 deletes transactions, specifies it can handle up to 500 IDs, and gives concrete use cases like removing duplicated statement imports. This distinguishes it from sibling tools such as edit_transaction or 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?
The description provides explicit use cases (removing duplicates, fixing direction errors), but does not explicitly state when not to use or name alternatives. The context is clear enough for an agent.
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 (slug or UUID), 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) — the results array states the outcome per item; retry only items with ok=false. For income<->expense direction flip, delete the wrong row and save a new one. tags: null=no change, []=clear all tags, [name,...]=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?
Description adds significant behavioral context beyond annotations: partial success ('each edit is committed independently'), results array indicating outcome per item, retry guidance, and tag handling (null, [], list). No contradiction with annotations (readOnlyHint=false, destructiveHint=false).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but front-loaded with core purpose. Could be more structured (e.g., bullet points), but every sentence adds value and is efficiently written.
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 all key aspects: batch size limit (500), partial success, retry strategy, tags special values, direction flip workaround. Output schema exists, so return value details are unnecessary. Complete for this complex 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 coverage is 100%, but description enriches each parameter: date timezone handling, tag null/array semantics, amount required positive, category must match kind, description/counterparty empty string vs null. Adds meaning beyond schema 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?
Description clearly states 'Edit one or more saved Zen transactions in a single call.' It identifies the resource (transactions) and action (edit), distinguishing from siblings like delete_transaction (deletion) and save_transaction (likely single save).
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 use case: 'Useful after bad imports where many rows need the same correction.' Advises on retry (only items with ok=false) and workaround for income/expense direction flip (delete and re-save). Does not explicitly mention when not to use, but context is clear.
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?
Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness. Description adds specific behavioral context: which fields are updatable and that slug/kind remain unchanged. This goes beyond annotations but lacks details on permissions or reversibility, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states action and scope, second provides usage context and alternatives. No waste, front-loaded, and 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?
Given 6 parameters (2 required), no enums, and presence of output schema, the description fully covers purpose, usage, constraints (slug/kind unchanged), and parameter behavior. It is complete and sufficient for correct tool 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 has 100% coverage with descriptions for all 6 parameters. Description adds semantic value by tying parameters to use cases (localization, classification guidance) and clarifies optionality (omit/null to keep current, pass empty to clear). This enriches understanding beyond schema 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?
Description clearly states the tool updates a category's display label, description, examples, or aliases. It specifies the verb 'update' and the resource 'category', and distinguishes from create+archive for changing kind, differentiating it from sibling tools like 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?
Description explicitly says when to use: to localize category names or improve classification guidance. It also states when not to use (to change slug or kind) and suggests an alternative (create + archive). This provides clear usage context.
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
MANDATORY for any budget-vs-actual question ('are we over budget', 'how are the budgets doing'). ALWAYS call this tool before discussing budget performance — never answer from chat memory; saved data may have changed. NOT for full month reviews: use get_monthly_summary for those. 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 and destructiveHint, so the bar is lower. The description adds value by warning against relying on chat memory (data may have changed) and advising incomplete coverage language. 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?
Three concise, front-loaded sentences with no wasted words. Each sentence serves a distinct purpose: usage mandate, exclusion, and language guidance.
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 parameters are fully described in schema, annotations are present, and output schema exists, the description adds the remaining context: when to use, behavioral notes, and language tips. The tool is fully specified for agent selection and 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 coverage is 100% with clear descriptions for all three parameters. The description does not add extra meaning beyond what is in the schema, but the baseline of 3 is appropriate given full schema 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 explicitly states the tool is for budget-vs-actual questions and distinguishes it from get_monthly_summary for full month reviews. It uses a specific verb ('get budget status') and resource, and the sibling tool list confirms no overlap.
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 clear when-to-use (budget questions) and when-not-to-use (full month reviews) with explicit instructions to always call before discussing budget performance and to use 'mapped so far' language.
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
MANDATORY for any monthly review or summary request ('how did we do', 'monthly review', 'show me May', 'made/spent/saved'). ALWAYS call this tool — NEVER answer monthly-review questions from chat memory or earlier tool results: the family dashboard UI renders ONLY when this tool is actually invoked, and saved data may have changed since the last call. Returns curated Made/Spent/Saved, prior-month comparison, category/budget drivers, bursts, and transactions. 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?
Beyond annotations (readOnly, idempotent), the description discloses that the dashboard UI only renders upon invocation and that data may have changed, adding critical behavioral context for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise paragraph with key instructions front-loaded, no extraneous content, and 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?
Given no output schema, the description lists the key return fields (curated metrics, comparison, drivers, bursts, transactions), which sufficiently sets expectations for the agent.
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 clear descriptions for all three parameters. The description does not add parameter details, so baseline 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 explicitly states the tool returns a monthly summary with specific metrics (Made/Spent/Saved, comparison, drivers, etc.) and distinguishes it from sibling tools by mandating its use for any monthly review request.
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 provides explicit when-to-use instructions ('MANDATORY for any monthly review or summary request') and clear exclusion ('NEVER answer from chat memory or earlier tool results'), guiding the agent away from alternatives.
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, and to verify an import right after save_transaction (compare the saved month against the source document); 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 timestamp. Sent without an offset, the household's jurisdiction timezone is applied. Defaults to now if omitted. | |
| start_date | No | Inclusive ISO 8601 start timestamp, e.g. '2026-05-01T00:00:00-03:00'. Sent without an offset, the household's jurisdiction timezone is applied. 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 (readOnlyHint, idempotentHint, destructiveHint) already convey safety. Description adds that results are 'mapped so far', indicating potential staleness or incompleteness, which is useful behavioral context 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 sentences: first states purpose, second provides usage guidance and a caveat. No wasted words, front-loaded with essential 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?
With output schema present, return values are covered. Description covers purpose, usage, and a key limitation (mapped, not complete). Sufficient for a read tool with clear annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in schema. Description reinforces 'one org/date range' but does not add new parameter-level details. 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 tool reads saved transaction lines for a specific org and date range. It differentiates from siblings like get_monthly_summary by noting results are 'mapped so far, not complete financial truth'.
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 specifies when to use: before analysis, before fixing user-reported wrong data, and to verify imports after save_transaction. Also clarifies what it is not (complete financial truth), aiding in appropriate selection.
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?
Description adds context beyond annotations (e.g., advisor skill as operating guide). Annotations already cover safety (readOnlyHint, idempotentHint) so 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, front-loaded with purpose, no wasted words. 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?
Given zero params and existing output schema, description sufficiently covers what the tool returns and its role. No gaps.
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?
No parameters in input schema (0 params, 100% coverage). Base rating is 4; description does not need to add parameter info.
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 tool returns saved household context and advisor skill, positioning it as a starting point. It distinguishes from sibling tools which focus on transactions.
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 says 'Start here for Zen requests', indicating primary use case. While no explicit 'when not to use', context implies it's for initial setup.
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, idempotentHint, and destructiveHint. Description adds context about checking duplicates and inspecting archived categories, but no new behavioral traits 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?
Four short sentences, front-loaded with the primary action. Every sentence adds value; 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?
With 2 well-documented parameters, an output schema, and rich annotations, the description covers purpose, usage, and alternatives completely for a list 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 coverage is 100% with detailed parameter descriptions. The description adds slight usage context for the status parameter, but does not significantly enhance meaning 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 lists org-level transaction categories. It distinguishes from the sibling tool get_user_context by specifying when to use each.
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 when to use: before creating a category to check for duplicates, or when inspecting archived categories. Also advises preferring get_user_context for active categories, providing clear when-not guidance.
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 are sparse (readOnlyHint=false, etc.), so the description carries the burden. It states 'Write-only surface: inserts into feedback_reports' and warns against including sensitive data. However, it does not elaborate on failure modes, idempotency, or rate limits, which would improve 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?
Three sentences, each earning its place: purpose, usage guidance, and behavioral note. Front-loaded with the action verb. No filler, highly 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 11 parameters and a write-only output (presumably a confirmation), the description covers the essential context: what to file and when. It lacks detail on the output schema or error handling, but those are less critical for a feedback tool. Minor gap in explaining potential 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?
Schema description coverage is 100%, so baseline is 3. The description adds minimal parameter meaning beyond the schema, e.g., reminding to avoid sensitive data. It does not explain individual parameters, but the schema already does that 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 tool's purpose: 'File a concise, non-sensitive product observation from this session — bugs, gaps, praise, or feature ideas.' It uses a specific verb ('file') and identifies the resource ('product observation'). No sibling tool offers feedback reporting, so it is well-differentiated.
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?
Explicit guidance is provided: 'Use proactively when you notice a product limitation, tool mismatch, or missing capability; do not wait for the user to ask.' It also warns that 'no read tool exists today,' setting clear expectations. This helps the agent decide when and why to use this tool.
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 indicate a mutation (readOnlyHint=false), and the description details the effect: 'Accept creates a named member with role member', which adds behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple tool with two well-described parameters and an existing output schema. It could be slightly richer, but remains complete enough.
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 clear descriptions for both parameters. The description does not add new meaning beyond what the schema already provides, so 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 'Accept or deny' and resource 'pending invitation', and distinguishes it from the sibling 'invite_member' by referencing 'get_user_context.invites'.
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 specifies that the invitations come from 'get_user_context.invites', implying the prerequisite step, but does not explicitly exclude other uses or state when not to use this tool.
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. Send whole statements in one call with expected_count set; the response lists saved and not_saved rows — if ok is false, check not_saved, fix ONLY those rows, and resend ONLY them. Rows in saved are already persisted: never resend them.
| 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 (the org name also works). | |
| 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 (slug like 'groceries' from get_user_context). Send the full statement in ONE call (up to 500 rows) and set expected_count so payload truncation is detected. 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, tags. | |
| expected_count | No | ALWAYS set this to the number of transaction rows you intend to send. If the server receives a different number (the client truncated your payload), it saves NOTHING and tells you how to resend safely. | |
| operation_date | No | ISO 8601 timestamp for the operation, e.g. '2026-05-31T00:00:00-03:00'. Include the UTC offset when known; sent without an offset, the household's jurisdiction timezone is applied (e.g. BR → America/Sao_Paulo). 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?
The description discloses multiple behavioral traits beyond annotations: grouping lines under one operation, cashflow attribution to operation_date month, expected_count mechanism, response structure (saved/not_saved), and instructions for resending only failed rows. Annotations are consistent (readOnlyHint=false), so 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?
The description is well-structured and dense with information, starting with core purpose then usage guidelines. It is somewhat long but each sentence adds necessary context for a complex tool. Minor verbosity keeps it from a 5.
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 (9 parameters, output schema exists), the description covers error handling, batch processing, credit card rules, and idempotency concerns. It explains the expected workflow comprehensively, including how to handle failures and resend only necessary rows.
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 baseline is 3. The description adds value by integrating parameter usage into a coherent workflow (e.g., how expected_count works, operation_date rules for credit cards). While schema already explains each parameter, the tool description provides higher-level guidance, making it slightly above baseline.
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: 'Persist income/expense lines as saved Zen data.' It identifies the verb (persist/save) and resource (transaction lines) and distinguishes from sibling tools like edit_transaction, providing strong purpose 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 this tool ('after reading a user-provided statement, PDF, or described transactions') and when not to use it ('not to correct existing rows'), naming direct alternatives (edit_transaction, delete + recreate). This provides excellent usage guidance.
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 (referenced by slug, e.g. 'groceries'). 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 (slug like 'groceries'; UUID also accepted) 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?
Beyond annotations (idempotentHint, readOnlyHint), the description adds behavioral context: history is captured automatically, and the agent should explain the effective month. 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 a single, front-loaded sentence that communicates the core action and key behavioral notes (history, user explanation). 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?
The description covers main functionality and side effects (history, user instruction). Given the tool's simplicity (3 params, no nesting) and presence of an output schema, it is nearly complete. Could mention prerequisites like category existence.
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 (100%), but description adds value by explaining slugs (e.g., 'groceries') and the effective month concept, linking to the 'valid_from' parameter. This enriches understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'saved Zen monthly budgets', mentioning categories by slug. It distinguishes from sibling tools like 'get_budget_status' by its write nature.
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 explicit guidance on when to use this tool versus alternatives (e.g., 'get_budget_status' for checking, 'edit_transaction' for transactions). It lacks when-not-to-use conditions.
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!