Bridge MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (create/get/list per entity). There is no overlap between customers, wallets, virtual accounts, transfers, external accounts, webhooks, and exchange rates, making selection unambiguous.
Naming Consistency5/5
All tools follow a consistent bridge_verb_noun pattern. Verbs are limited to create, get, and list, and nouns are consistently singular for get/create and plural for list operations, except for exchange_rates which is naturally plural.
Tool Count4/5
With 18 tools, the server is slightly above the typical 3-15 range but each tool corresponds to a necessary operation across seven distinct resource types. The count is justified for a payment-focused API, though it feels a bit heavy.
Completeness3/5
Core create/get/list operations are covered for most resources, but update and delete actions are missing across the board. Notably, webhooks only have create and list, lacking get and delete. These gaps could hinder full lifecycle management for an agent.
Average 3.5/5 across 18 of 18 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'create a transfer' without mentioning fees, idempotency, dry_run validation, or that funds may actually move. For a financial mutation tool, this is a critical gap.
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 a single, front-loaded sentence with no wasted words. It efficiently communicates the core purpose, though it could be too brief for the tool's complexity, slightly reducing structure effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 17 parameters, no output schema, and no annotations, the description is severely underspecified. It lacks combination rules, payment rail constraints, address requirements, fee behavior, and dry_run semantics, making it incomplete for safe invocation.
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?
The input schema provides full descriptions for all 17 parameters (100% coverage), so the description adds no additional parameter context. The schema already covers the semantics, so a baseline score of 3 applies.
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 clearly states the action (Create), resource (transfer), and scope (fiat-to-crypto, crypto-to-fiat, or crypto-to-crypto). This distinguishes it from sibling create tools like bridge_create_wallet or bridge_create_external_account, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only states the basic purpose without context for scenarios like payment rail selection or on_behalf_of ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention authentication requirements, error handling, the need for both customer_id and wallet_id, or what happens if the wallet is not found. The description adds no behavioral context beyond the obvious read action.
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 a single, focused sentence, 'Get a wallet by ID,' which is direct and free of unnecessary details. It effectively communicates the core action with high efficiency, scoring well on conciseness even if it lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is not sufficiently complete. It fails to explain why both customer_id and wallet_id are required, what the response contains, or any prerequisites. The minimal description leaves the agent with only the raw schema to infer usage, which is inadequate for a tool with these parameters.
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?
The input schema provides basic descriptions for both parameters (wallet_id, customer_id). Schema coverage is 100%, so baseline is 3. The description adds no additional meaning about the role of customer_id (e.g., scoping or authorization) or how the parameters interact, but does not need to repeat what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (wallet) with a lookup key (by ID), indicating a single-item retrieval. It is distinct from list operations like bridge_list_wallets, but it does not explicitly mention alternatives or contrast with sibling tools, so it slightly misses the highest level of differentiation.
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?
There is no guidance on when to use this tool versus alternatives such as bridge_list_wallets or bridge_get_customer. The description only repeats the tool's basic function without providing contextual criteria, prerequisites, or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'with optional pagination', which merely restates the schema's optional limit/cursor parameters. It does not disclose return format, default pagination behavior, authentication needs, or any side effects.
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 a single, efficient sentence that immediately conveys the core function. There is no fluff or repetition; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two fully described optional parameters, the description is minimally adequate. However, with no output schema and no annotations, it lacks information about the response envelope, default page size, how cursors are used, or any operational constraints, making it only partially complete.
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?
The input schema already provides clear descriptions for both parameters (limit and cursor), achieving 100% schema_description_coverage. The description adds no extra semantic meaning beyond confirming that pagination is optional, which is already evident from the 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 clearly states the action ('List') and the resource ('all customers'), and explicitly mentions optional pagination. It distinguishes from sibling tools like bridge_create_customer and bridge_get_customer by being the only general list operation for customers.
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 guidance is provided on when to use this tool versus alternatives such as bridge_get_customer or bridge_list_wallets. There is no mention of use cases, exclusions, or behavior differences from other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral transparency. It only mentions 'Link an external bank account' without disclosing side effects such as creating a persistent financial record, irreversibility, or any verification prerequisites. The schema reveals an idempotency_key, but the description does not elaborate on retry safety or other behavioral implications.
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 a single, straightforward sentence with no redundant wording or filler. It is appropriately sized and front-loaded with the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, conditional fields, no output schema) and lack of annotations, this description is insufficient. It does not explain prerequisites (e.g., customer must exist), validation behavior, or what the response contains. The one-sentence description leaves significant gaps for an AI agent attempting to invoke this tool effectively.
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 description coverage is 100%, so the parameters are fully explained in the schema itself. The description adds minimal parameter context beyond stating the purpose ('for payouts'), but does not clarify field relationships like IBAN vs. account_number depending on account_type. Baseline 3 is appropriate since the schema already handles parameter semantics.
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 action ('Link an external bank account') and the resource ('to a customer for payouts'). It distinguishes this tool from siblings like bridge_get_external_account and bridge_create_virtual_account by specifying the target resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('for payouts') but does not explicitly mention when to use this tool versus alternatives like bridge_create_virtual_account or bridge_create_wallet. There is no exclusions or comparison, so usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions auto-conversion to stablecoins, but omits details on prerequisites (e.g., need for an existing wallet), fees, reversibility, or idempotency behavior. As a creating tool with side effects, this lacks sufficient depth.
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?
A single, focused sentence that conveys the tool's purpose and key feature. There is no wordiness or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear, the description does not address the tool's 8-parameter complexity, including the mutually exclusive bridge_wallet_id/destination_address options, or what output to expect. No output schema and no annotations leave the description insufficient for complete usage guidance.
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 coverage is 100% with descriptive parameter texts, so the baseline is 3. The description adds no extra semantics beyond the schema, merely restating the high-level purpose without elaborating on parameters or their relationships.
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 'Create a virtual account (fiat deposit address) that auto-converts to stablecoins', which clearly identifies the action (create), resource (virtual account), and core behavior (auto-conversion). It effectively distinguishes this tool from sibling tools like bridge_create_wallet or bridge_create_transfer by specifying 'fiat deposit address'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a virtual account for fiat deposits but provides no explicit guidance on when to choose this over alternative tools or any exclusions. Context is minimal, relying on the tool's name and general purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for disclosing behavior. It only states the operation is a 'get', implying read-only, but does not mention response format, error behavior, or access requirements.
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 a single concise sentence with no wasted words. It is immediately readable and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter getter, the description is adequate: it identifies the tool and its input. It does not elaborate on return values, but there is no output schema and the tool's purpose is straightforward.
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 coverage for the single parameter is 100%. The description adds no meaning beyond the schema's 'The transfer ID', so the baseline of 3 is appropriate.
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 (Get) and the resource (a transfer by ID). It distinguishes itself from siblings like list_transfers by specifying that it retrieves a single transfer based on an ID.
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 guidance is provided about when to use this tool instead of list_transfers or create_transfer. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose pagination behavior (though limit/cursor params exist), sort order, response format, or permission requirements. Only the optional customer filter is noted.
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?
Single sentence, directly states action and resource, no unnecessary words. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema or annotations, the description does not explain pagination semantics, response shape, or how cursor/limit are used. It leaves important operational gaps for an AI agent.
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 description coverage is 100%, so the baseline is 3. The description adds that customer_id enables optional filtering, matching the schema, but provides no extra context about limit/cursor usage or parameter interactions.
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 uses specific verb 'List' and resource 'transfers', with optional customer filter clearly stated. It distinguishes from siblings like bridge_get_transfer (single transfer) and bridge_list_customers/wallets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing transfers and mentions optional filtering by customer, but does not explicitly state when to use this tool over alternatives (e.g., bridge_get_transfer for a single transfer) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions KYC/KYB onboarding, hinting at a compliance workflow, but it does not disclose side effects, required prerequisites, conditional fields based on customer type, or post-creation steps. This is a significant gap for a mutation tool.
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 a single, focused sentence that immediately conveys the tool's purpose. Every word earns its place, and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, conditional requirements (first_name/last_name for individual, business_name for business), no output schema, and no annotations, the description is far too sparse. It does not explain the distinction between individual and business fields, idempotency behavior, or what to expect after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 58%, with several parameters like city, state, country, postal_code, and street_line_1 lacking descriptions. The tool description adds no parameter guidance beyond echoing the 'type' enum values already present in the schema. It does not compensate for the undocumented 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 action (create), the resource (customer), and the scope (individual or business for KYC/KYB onboarding). This distinguishes it from sibling create tools like bridge_create_wallet or bridge_create_transfer.
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 about when to use the tool: creating a customer for KYC/KYB onboarding. It does not explicitly mention exclusions or alternatives, but the scope is self-evident given the create operation and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It clearly indicates a write operation ('Create'), but does not mention potential side effects, requirements like existing customer, idempotency behavior, or what is returned. The description is too minimal to inform the agent of important behavioral implications.
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 a single, compact sentence that immediately states the action and key context. There is no redundancy or filler, and it is appropriately front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (3 parameters, no output schema, no annotations), the description covers the core action but omits useful context such as required customer existence, whether the operation is idempotent by default, or what a successful response looks like. It is adequate for a basic create operation but leaves notable 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 coverage is 100%, so the schema fully documents all three parameters. The description does not add any new meaning beyond what is in the schema, such as how idempotency_key works or the implications of choosing a specific chain. It earns the baseline score of 3 for a well-covered 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 uses the specific verb 'Create' with a clear resource ('custodial wallet') and specifies the context ('for a customer on a specific blockchain'). It clearly distinguishes this from sibling tools like create_virtual_account or get_wallet by naming the wallet creation action and its custodial nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a wallet needs to be created for a customer on a blockchain, but it does not explicitly state when to use it over alternatives such as create_virtual_account or list_wallets. There is no mention of exclusions, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it simply restates the tool's name and adds no context about response format, error behavior, or side effects. The description is essentially a tautology of the tool name.
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 a single, concise sentence that front-loads the key information without waste. It earns every word and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter, the description is minimally viable but leaves gaps. There is no output schema, no explicit behavior about not-found cases, and no mention of related data or response structure. Given the lack of annotations, a bit more context would improve completeness, but the tool is simple enough that the current description is not inadequate.
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?
The schema already provides a description for customer_id ('The customer ID'), giving 100% schema coverage. The tool description adds no additional meaning beyond what the schema provides, so the baseline 3 applies.
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 'Get a customer by ID' uses a specific verb and resource, clearly distinguishing it from sibling tools like bridge_list_customers (list) and bridge_create_customer (create). It precisely states the operation and the identifying input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single customer via customer_id, but provides no explicit guidance on when to choose this over list or other customer-related tools. There is no mention of exclusions or alternatives, making the guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Get', which implies a read-only operation, but does not disclose potential error behavior (e.g., 404 if not found), authentication requirements, or return format. This is a significant gap given the absence of annotations.
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 a single, concise sentence that front-loads the verb and object. Every word earns its place, and there is no redundant information. It follows best practices for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with a clear input schema, but the description is minimal and does not provide usage guidance or behavioral context beyond the bare action. Given that there is no output schema and no annotations, the description is adequate for basic selection but leaves gaps in understanding error handling and when to choose this over list_virtual_accounts. It is minimally complete but not rich.
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 description coverage is 100%, with both parameters (customer_id and virtual_account_id) already described in the input schema. The description adds no additional meaning to the parameters beyond what the schema provides. It does not explain why customer_id is needed or how the two IDs relate, but the schema covers the basic semantics, so the baseline of 3 is appropriate.
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 action (Get), the resource (virtual account), and the specific method (by ID). This distinguishes it from sibling tools like bridge_list_virtual_accounts, which retrieves multiple accounts. The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you have a specific virtual_account_id and need its details. However, it does not explicitly state when to use this tool versus alternatives like bridge_list_virtual_accounts, nor does it mention any exclusions or prerequisites. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the operation is a read-only list scoped to a customer, but it does not mention pagination, return format, authorization requirements, or empty-result behavior.
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 a single, front-loaded sentence with no wasted words. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is adequate but minimal. It does not explain the return payload or any pagination behavior, which is more noticeable given the absence of an output schema and annotations.
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 coverage is 100% and customer_id is described as 'The customer ID'. The tool description adds that the list is scoped 'for a customer', which ties the parameter to the filtering behavior, but no additional format or constraint details are provided.
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 the specific verb 'list', names the resource 'wallets', and scopes the action with 'for a customer', clearly distinguishing it from get_wallet and other list tools.
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 alternatives such as get_wallet or list_virtual_accounts. The only implied usage is from the description itself, and there are no exclusions or when-not-to-use notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It only states 'Create a webhook endpoint' without mentioning what happens on creation (e.g., whether it's immediately active, if a webhook secret is returned, or any persistence details). This lacks depth for a mutating operation.
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 a single, front-loaded sentence with no redundant information. It efficiently conveys the core action and resource, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with fully described parameters, the description is largely complete in context. It could mention the return value or side effects, but the core purpose is clear, and the schema fills in parameter details. Given no output schema, a bit more context on response would help, but it's not essential.
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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning about parameters, but the schema already explains url, event_epoch, idempotency_key, and event_categories adequately.
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 'Create' and the resource 'webhook endpoint', and adds the purpose 'to receive Bridge events'. This distinguishes it from sibling tools like create_customer or create_wallet, which target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating webhooks but provides no explicit guidance on when to use this vs. alternatives like list_webhooks. It does not mention exclusions or prerequisites, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'current' exchange rates, but does not disclose return format, possible base currency, or whether it is a read-only operation. This is minimal 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?
The description is a single, clear sentence that is front-loaded with the action and resource. It is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns. It does not specify whether the rates are for all currencies, the base currency, or the structure of the response. This leaves important gaps for an agent to understand the tool's full behavior.
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 there is no parameter semantics to add. A score of 4 is appropriate as the baseline for 0 params, and the description does not need to explain any input details.
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 'Get current exchange rates between currencies' clearly identifies the specific action (get) and resource (exchange rates). It is easily distinguished from sibling tools that deal with customers, wallets, transfers, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving exchange rates but does not explicitly state when to use this tool or mention alternatives. Since it is the only tool related to exchange rates among siblings, the context is sufficient, but no explicit guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all virtual accounts' and does not mention return format, pagination behavior, empty results, or any other operational characteristics. The lack of detail leaves significant uncertainty for an agent.
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 a single, front-loaded sentence that conveys the essential purpose without any unnecessary words. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations. The description fails to mention what the response contains (e.g., an array of virtual account objects), pagination, or any error scenarios. For a complete understanding, the agent would need more details about the return value, especially since the output schema is absent.
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 schema describes customer_id simply as 'The customer ID', but the description adds context by stating the accounts are 'for a customer', clarifying that the parameter identifies whose virtual accounts to retrieve. This goes beyond the schema's minimal description.
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 action ('List'), the resource ('virtual accounts'), and the scope ('for a customer'). It distinguishes itself from sibling tools like bridge_list_wallets (different resource) and bridge_get_virtual_account (singular vs plural).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a customer' implies that the customer_id parameter is required and that this tool is appropriate when needing all virtual accounts for a specific customer. However, it offers no explicit guidance on when to prefer this over alternatives like bridge_get_virtual_account or bridge_list_wallets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, how results are returned (e.g., list format, pagination), or error behavior. The description essentially restates the tool's name without adding behavioral context.
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 a single, front-loaded sentence with no unnecessary words. It efficiently conveys the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description gives the core purpose but omits return format and behavior details. Without an output schema, the agent might not know what to expect as a response, though the action is straightforward.
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?
The schema already covers the customer_id parameter with a description. The tool description adds no extra meaning about the parameter, so the baseline of 3 applies given 100% 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 action ('List'), the resource ('external accounts'), and the scope ('for a customer'). It is distinct from sibling tools like get_external_account (singular) and create_external_account, and from list_wallets/list_customers.
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 context is clear: this tool lists all external accounts for a customer, implying it should be used to retrieve a collection rather than a single account. It does not explicitly mention alternatives or exclusions, but the intended usage is evident from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all webhook endpoints', which essentially restates the tool name with the word 'all'. It does not mention return format, pagination, authentication, or any other behavioral traits, offering little value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action and resource. It contains no fluff or repetition, making it highly concise and effective for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should ideally clarify what is returned, but it omits any return value details. Given the tool's simplicity (zero params, clear list action), the description is minimally viable but has clear gaps around response format and potential behavioral nuances.
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?
There are zero parameters, so the baseline is 4 per the rubric. The description's inclusion of 'all' reinforces that no filters are available, which adds a small semantic layer beyond the empty schema. No parameter details are needed.
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 'List all webhook endpoints' uses a specific verb (List), a clear resource (webhook endpoints), and the scope 'all', distinguishing it from sibling create_webhook. It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied by the verb 'List' and the resource, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention the sibling create_webhook. There is no direct exclusion or alternative guidance, so it is merely adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately implies a read operation but does not disclose error behavior, permissions, or return format, which are relevant for a get tool.
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 a single clear sentence with no unnecessary words, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is largely adequate. It has two well-documented parameters and no output schema, and while it does not explicitly mention return value, the expected behavior of a get-by-ID operation is implicit. Slight gap in not specifying that the external account is scoped to a customer, but the schema covers this.
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 description coverage is 100%, with both parameters clearly described. The description adds no extra semantic detail beyond referencing 'by ID', but the schema already provides sufficient meaning.
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 'Get' and the resource 'external account' with the qualifier 'by ID', which distinguishes it from list and create sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 alternatives. The purpose implies usage when a specific external account ID is known, but it does not mention exclusions or alternatives.
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:

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

Score Badge

Copy to your README.md:

[![bridge-mcp MCP server](https://glama.ai/mcp/servers/lnflash/bridge-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lnflash/bridge-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/lnflash/bridge-mcp'

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