monobank-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between monobank-bank-currency and monobank-bank-currency-rate, and between monobank-personal-client-info and monobank-personal-accounts. The descriptions clearly differentiate these, so an agent can choose correctly.
Naming Consistency4/5
All tool names use the 'monobank-' prefix and lowercase hyphens, but the pattern is not fully consistent: data retrieval tools use noun phrases (e.g., monobank-personal-statement), while webhook tools use verb-noun phrases (e.g., monobank-set-webhook). This is a minor deviation from a fully uniform convention.
Tool Count5/5
With 8 tools, the server is well-scoped for a personal finance integration, covering currency rates, client information, accounts, statements, and webhook management without unnecessary redundancy.
Completeness4/5
The tool surface covers the essential read operations (rates, client info, accounts, statements) and the full webhook lifecycle, which matches the server's informational purpose. Minor gaps exist, such as no way to fetch a single account's details directly, but the accounts list provides a workaround.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 39 commits in the last 12 weeks
- Last stable release on June 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety profile is covered. The description adds valuable field-level behavior: conditional presence of rateSell/rateBuy versus rateCross, and the ISO 4217 explanation, which goes 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a concise intro followed by a bulleted list of response fields. Each line is informative and necessary, avoiding tangents. It is slightly longer than minimal but earns its length by clarifying field semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description fully compensates by documenting all response fields, including conditional presence and meaning. For a zero-param read-only tool, this is complete and self-sufficient; the agent can confidently invoke it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter semantics because none exist; it appropriately focuses on response fields instead. Schema coverage is trivially 100% with an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Returns Monobank exchange rates for all supported currencies,' providing a specific verb, resource, and scope. This clearly distinguishes it from sibling 'monobank-bank-currency-rate' which likely targets a single rate or pair.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the sibling 'monobank-bank-currency-rate'. The description implies broad coverage ('all supported currencies') but does not state exclusions or alternative conditions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral detail that an empty string means no webhook is set, which is valuable beyond the annotations and helps the agent interpret the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, direct sentences. It front-loads the verb and resource, then adds the crucial empty-string clarification. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a parameterless read tool with no output schema. The description fully explains what the agent receives (the webhook URL) and handles the special empty-string case. Given the sibling context and simplicity, there are no missing behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description doesn't need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: it returns the currently configured webhook URL for the Monobank token. The verb 'Returns' is specific, the resource ('webhook URL') is clear, and the scope ('for this Monobank token') distinguishes it from sibling tools like set/unset webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a read operation for the current webhook configuration and adds the important empty-string semantics. It doesn't explicitly say 'use this before setting/unsetting a webhook', but the intent is obvious given the sibling tools are mutations, so a 4 fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; description adds meaningful context by specifying token scoping, the distinction between accounts and jars, and field meanings such as 'goal (0 if no target set).' This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a compact field list; the opening sentence front-loads purpose and usage. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only list tool, the description covers what it returns (accounts and jars), how to use the results (accountId for statement), and field details. No output schema exists, but the inline field breakdown fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and an empty input schema, so the baseline is 4 under the rubric. The description instead documents the output fields, which is the relevant semantics for this parameterless read tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Returns a compact list of all Monobank accounts and jars linked to this token,' a specific verb+resource statement. The follow-up 'Use this to discover accountId values before calling monobank-personal-statement' distinguishes it from sibling tools by tying it to the statement workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly instructs when to use: 'Use this to discover accountId values before calling monobank-personal-statement,' naming the dependent sibling. It does not spell out exclusions or contrast with client-info/currency tools, so it falls short of a full when-not-to-use map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable context beyond these: field-specific details (e.g., webhookUrl is empty string if unset, permissions array shows granted scopes, managedClients only present for business tokens, amounts already divided). This enriches the agent's understanding of response semantics without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states the purpose, then top-level fields, accounts, and jars are each introduced with clear bullet-like sections. Every sentence adds meaningful detail (e.g., currency code format, cashback types, conditional fields), and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description carries the full burden of explaining return values. It thoroughly covers all returned sections: client identity, permissions, managedClients, each account's fields, and each jar's fields, including edge cases like 'goal is 0 if no target is set'. This is sufficient for an agent to interpret the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description correctly focuses on output structure rather than parameters, and there is no parameter confusion to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+object+scope: "Returns Monobank client profile: identity, token permissions, and all linked accounts and jars." It distinguishes itself from sibling tools like monobank-personal-accounts by explicitly covering the full profile including accounts and jars, not just a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is the comprehensive profile endpoint, which implies use when needing identity, token scopes, accounts, and jars in one call. It does not explicitly name alternatives or exclusion criteria, but the detailed field listing naturally differentiates it from more focused siblings like monobank-personal-accounts or webhook tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds the valuable context that 'Monobank will stop sending push notifications', which clarifies the real-world consequence of the destructive action. It also reinforces idempotency with the 'safe to call' note, going beyond just the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded. Each sentence adds necessary information: the action and the consequence, plus an idempotency note. There is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete. It explains what it does, the effect (stops push notifications), and the safety idempotency behavior. No additional context is needed for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (zero parameters), so schema coverage is 100%. With no parameters, the baseline is 4, and the description does not need to add parameter semantics. The description's focus on the token scope ('for this Monobank token') is sufficient given there are no explicit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Removes the webhook URL for this Monobank token.' This distinguishes it from sibling tools like monobank-get-webhook and monobank-set-webhook, as it explicitly indicates the removal action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to stop push notifications by removing the webhook. It also notes that it is 'Safe to call even if no webhook is currently set', giving guidance on idempotent usage. However, it does not explicitly name alternatives or state when not to use it, hence the 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly and idempotent hints, so the description need not repeat them. The description adds behavioral context beyond annotations: the performance trait ('Faster than...') and the limitation of supported currency pairs. This enriches the tool's behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with the primary purpose front-loaded and the additional usage context efficiently appended. Every sentence adds value, with no wasted words or redundant repetition of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 2 parameters, full schema coverage, and annotations, the description covers all needed aspects: purpose, when to use, defaults, and limitations. The absence of an output schema is mitigated by the simple return nature described. No critical gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, establishing a baseline of 3. The description adds extra meaning by stating the default quoteCurrency (already in schema) and the specific constraint that only EUR/USD is possible as a non-UAH pair, which is not in the schema. This provides practical usage nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and clearly identifies the resource as 'Monobank exchange rate for a specific currency pair'. It also distinguishes from sibling tool 'monobank-bank-currency' by highlighting the speed advantage for single-rate lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('when you need just one rate') and names the alternative ('monobank-bank-currency'). Also provides a concrete constraint by noting the only available non-UAH pair is EUR/USD, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits: one webhook URL per token, overwriting without confirmation, and the destructive consequence. This goes beyond the annotations' destructiveHint and adds context about the exact risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver purpose and critical warning without redundancy. The warning is placed prominently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool with annotations and no output schema, the description fully covers purpose, safety warning, and recommended pre-check, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a clear description ('HTTPS URL to receive webhook events'). The tool description does not add extra format or constraint details, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Sets' with the specific resource 'webhook URL for this Monobank token,' distinguishing it from sibling tools like get-webhook and unset-webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names an alternative (monobank-get-webhook) and provides a concrete recommendation to check the current value before setting, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantive behavior: date range limit, timestamp defaulting, sign conventions, pending holds, and counterparty fields. This greatly exceeds annotation-only transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Starts with a one-sentence summary, then groups inputs and output fields clearly. Every section earns its place, with no redundancy. The structured layout makes the length acceptable given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of explaining the return value, and it does so comprehensively: amount semantics, currency, balance, fees, MCC, hold status, and counterparty data. Input constraints and defaults are also covered, making the tool fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description fully compensates: it explains accountId source and default '0', gives ISO 8601 format examples for fromDate/toDate, and documents toDate defaulting. All parameters are meaningfully described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Returns a list of transactions for a Monobank account' — a specific verb and resource. This clearly distinguishes it from sibling tools like monobank-bank-currency and webhook management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: maximum 31-day range, accountId sourced from 'monobank-personal-client-info', and toDate defaults to now. It doesn't explicitly name alternatives, but the domain is so distinct that usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![monobank-mcp MCP server](https://glama.ai/mcp/servers/todesstoss/monobank-mcp/badges/card.svg)](https://glama.ai/mcp/servers/todesstoss/monobank-mcp)

Score Badge

Copy to your README.md:

[![monobank-mcp MCP server](https://glama.ai/mcp/servers/todesstoss/monobank-mcp/badges/score.svg)](https://glama.ai/mcp/servers/todesstoss/monobank-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/todesstoss/monobank-mcp'

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