Synci
Server Details
Synci connects your bank, brokerage, and crypto-exchange accounts to AI assistants, read-only. Ask about balances, transactions, holdings, and spending across all your accounts in one place.
- 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.4/5 across 5 of 5 tools scored.
Each tool targets a distinct aspect of financial data: balances, accounts, connections, holdings, and transactions. No overlap in functionality.
Four of five tools use the consistent list_ prefix; get_account_balance deviates with get_, but the naming is still clear and intuitive.
Five tools is an appropriate scope for a personal finance data server, covering all major read operations without unnecessary bloat.
Core CRUD coverage for reading financial data is present. Missing write operations (create/update) are not expected for a read-only API. Minor gap: no single-tool to fetch a specific connection detail beyond listing.
Available Tools
5 toolsget_account_balanceGet account balanceARead-onlyIdempotentInspect
Get balance snapshots for one account (e.g. INTERIM_AVAILABLE, EXPECTED, CLOSING_BOOKED). as_of is when balances last synced — they can lag transactions, so caveat stale figures. For a credit account a negative CLOSING_BOOKED is the amount owed (not overdrawn). Investment/crypto accounts usually have no balance snapshots; the response then points you to list_holdings.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The id of the financial account to fetch balances for, as returned by list_accounts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | Present when the account has no snapshots; points at list_holdings for investment/crypto value. |
| as_of | No | When balances last synced (ISO 8601); balances can lag transactions. |
| balances | Yes | Newest first, at most 20 snapshots. Empty for accounts without balance snapshots. |
| account_id | Yes | |
| cash_balance | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint) already declare safety. The description adds important behavioral context: as_of can lag transactions, negative CLOSING_BOOKED for credit accounts means amount owed, and investment/crypto accounts have no snapshots. This enriches 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?
Three concise sentences: first states purpose, second adds caveat, third covers edge cases. Every sentence adds value, no fluff, front-loaded with core 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 one required parameter, no enums, existence of output schema, and rich annotations, the description fully covers purpose, caveats, and edge cases. An agent has sufficient context to invoke the tool correctly.
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?
Only one parameter (account_id) with 100% schema coverage. The schema description already explains it thoroughly. The tool description adds no additional parameter meaning, 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 tool gets 'balance snapshots for one account' and lists specific snapshot types (INTERIM_AVAILABLE, EXPECTED, CLOSING_BOOKED), distinguishing it from siblings like list_transactions or list_holdings.
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 when to use (get balance snapshots), warns about stale figures due to as_of lag, and explicitly advises using list_holdings for investment/crypto accounts. This provides clear when-to and when-not-to guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsList accountsARead-onlyIdempotentInspect
List the user's connected financial accounts (bank, investment, crypto). Each is a lean summary: name, institution, category, currency, a balance block, account health, and earliest_available_date. IMPORTANT: balances can lag transactions — check balance.as_of (the last time balances synced) and caveat stale figures. IMPORTANT: earliest_available_date is the start of the account's synced history — a query for a period before it returns nothing because the data was never synced, NOT because there was no activity, so never report a total for a window that starts before it without caveating the coverage. Investment/crypto accounts often have an empty balance (their value is in list_holdings). verbose:true returns the full record. Sensitive identifiers are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | When true, return the full account record instead of the lean summary. | |
| account_category | No | Optional. Restrict results to a single account category. |
Output Schema
| Name | Required | Description |
|---|---|---|
| accounts | Yes | Lean account summaries; with verbose:true each item is the full account record instead. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds critical behavioral context: balances may lag, earliest_available_date indicates sync start, sensitive identifiers omitted, and verbose parameter effect. 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?
Description is moderately long but front-loaded with purpose. Important caveats are highlighted in caps. Every sentence adds value, though slight verbosity remains. Structure is logical: purpose, summary details, important notes, parameter impact.
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 2 optional parameters with full schema coverage, output schema exists, annotations present. Description explains all key aspects: return format, parameters, critical caveats, and relation to siblings. No missing elements for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. Description adds value by clarifying that verbose returns 'full record' and account_category 'restricts results to a single category', which enhances 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?
Description explicitly states it lists connected financial accounts and details the fields in each lean summary. The verb 'list' and resource 'accounts' are clear. Distinguishes from siblings by noting specific fields and caveats like balance lags and investment accounts having empty balances.
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 guidance on when to use the tool (listing accounts) and important caveats: balance lag; earliest_available_date meaning; investment/crypto accounts need list_holdings for value. Does not explicitly state when NOT to use it, but the context is sufficient to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connectionsList connectionsARead-onlyIdempotentInspect
List the authenticated user's bank/provider connections and their health status (HEALTHY, FAILING, DEAD), including the institution and consent expiry.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| connections | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds authentication context but does not disclose additional behavioral traits beyond what annotations provide, so it is adequate but not enhanced.
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 of 20 words, front-loading the verb and resource, with no superfluous 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 no parameters and an output schema (not shown), the description succinctly covers the tool's purpose and return value details, which is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so baseline is 4. The description does not need to add parameter meaning.
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 'List', the resource 'bank/provider connections', and specifies returned attributes (health status, institution, consent expiry), which distinguishes it from sibling tools like list_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing connection health but does not explicitly state when to use this tool vs alternatives (e.g., list_accounts for accounts), leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_holdingsList holdingsARead-onlyIdempotentInspect
List the investment and crypto positions held in the user's brokerage and crypto-exchange accounts: symbol, asset class, quantity, latest price, market value and currency. Bank accounts have no holdings. Optionally restrict to one account.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Optional. Restrict to a single account (id from list_accounts). Omit to span all of the user's investment/crypto accounts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| holdings | Yes | Current position snapshot per holding; empty when the user has no investment/crypto positions. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds important context about bank account exclusion and effect of omitting account_id. 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?
Two concise sentences, zero wasted words. Front-loaded with core purpose and key constraint.
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 output schema exists, description sufficiently explains behavior, constraints, and parameter effect. Sibling tools provide comparison context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers account_id fully. Description adds meaning: omitting spans all accounts, and value comes from list_accounts. Exceeds baseline 3 due to additional context.
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 specifies verb 'list', resource 'holdings', and scope (investment/crypto accounts) with detailed fields. Clearly distinguishes from sibling tools like list_accounts and get_account_balance.
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?
States bank accounts have no holdings and optionally restrict to one account, providing clear context. Lacks explicit alternatives but given sibling list, it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_transactionsList transactionsARead-onlyIdempotentInspect
List the user's financial transactions in a date window, newest first, across all account types (bank, deposit, line of credit, investment). Each row is lean by default: id, date, amount (negative = money out), currency, booked, payee, description (omitted when it duplicates payee), an account {id, name, institution} ref, and — when available — mcc, category, and bank_details (raw provider metadata: transaction/purpose codes, currency-exchange info, and the MCC category text that banks put in additional_information — useful for categorising spend when enrichment is off). Pass "verbose": true for the full, raw transaction record.
Investment rows also carry: type (raw activity, e.g. BUY / SELL / DIVIDEND / CRYPTO_SEND), is_cash_flow, units, and price_per_unit (the effective per-unit price in this row's currency, = |amount| / units). IMPORTANT for "what did I spend": rows with is_cash_flow=false are asset transfers or income-in-kind (crypto send/receive, staking, stock splits) — NOT money spent; exclude them from spending totals. Use amount, units and price_per_unit for trade figures; ignore any price written into the description string (it is the provider's own and can be in a different currency).
Dates: "date" is Synci's per-account authoritative date by default (what the user sees; "spending in June" means this). Override with date_field "booking" or "value" to filter/sort/show a specific date instead. Both booked and pending transactions are returned by default; filter with status ("all" | "booked" | "pending", default "all"). Pending amounts can still change.
Coverage: meta.earliest_available_date is the date the queried accounts are synced from. If it is later than your "from", the window is only PARTIALLY covered — data before it was never synced (not absent), so any total would silently under-report. Caveat the coverage, or narrow "from" to it.
Pagination: results are bounded by the date window and "limit" (default 50, max 100). Check meta.has_more: if true, request the next page by passing meta.next_cursor as "cursor" (keyset paging, no gaps or overlap). Sensitive identifiers (IBAN, account numbers, etc.) are always omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Optional end date (YYYY-MM-DD), inclusive. Defaults to today. | |
| from | No | Optional start date (YYYY-MM-DD), inclusive. Defaults to 30 days before "to". | |
| limit | No | Optional max rows to return (1-100). Defaults to 50. Check meta.has_more and page with meta.next_cursor. | |
| cursor | No | Optional. Pass meta.next_cursor from a previous call to fetch the next page (keyset paging). | |
| status | No | Filter by settlement status. Defaults to "all" (booked + pending). | |
| verbose | No | When true, return the full raw transaction record instead of the lean shape. | |
| account_id | No | Optional. Restrict to a single financial account (id from list_accounts). Omit to span all accounts. | |
| date_field | No | Which date to filter/sort/show on. "mapped" (default) is Synci's authoritative per-account date; "booking" or "value" force a specific field. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Newest first. Lean rows omit null/empty keys; with verbose:true each item is the full raw transaction record instead. |
| meta | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds substantial behavioral details: pagination with keyset, date filtering, status filtering, lean vs verbose output, exclusion of sensitive identifiers, investment row specifics, and coverage caveats. 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?
Reasonably front-loaded with main purpose, but overall verbose with many details (e.g., investment rows, coverage warning). Could be more concise, but each 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 8 parameters, complex response shape, and no output schema shown, description thoroughly covers pagination, date handling, investment rows, spending calculation rules, and coverage limitations. Highly complete.
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 description adds extra meaning beyond schema defaults, date_field options, pagination parameters, and response field explanations (e.g., investment rows). Complements schema 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 verb 'List' and resource 'financial transactions', specifies date window, newest first, and all account types. Distinguishes from siblings like get_account_balance and list_holdings by describing scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (listing transactions) and important caveats (exclude is_cash_flow=false for spending totals, coverage warnings). Does not explicitly contrast with sibling tools but implies appropriate usage.
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!