persistenceone-bridgekitty

Official

by persistenceOne

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.3.9
Disambiguation5/5
Each tool targets a distinct operation: bridging (chains, tokens, quotes, execution, status, multi-hop), wallet (setup, import, status, balance), help, and onboarding. No overlapping purposes.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern with underscores (bridge_chains, wallet_balance). Minor inconsistency: 'xprt_onboard' inverts the order, but it's still readable and the overall naming is coherent.
Tool Count5/5
12 tools is appropriate for a bridge and wallet server. It covers essential operations without being overwhelming, fitting the domain well.
Completeness4/5
Core bridging workflow (chains, tokens, quote, execute, status) and wallet management (setup, import, balance) are covered. Minor gap: no tool to list supported providers explicitly, but bridge_chains provides that info indirectly.
Average 4.4/5 across 12 of 12 tools scored. Lowest: 3.9/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
- Last stable release on April 10, 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.
This repository includes a glama.json configuration file.
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.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals that the tool resolves optimal paths internally and returns ordered hops with per-hop detail. However, it omits details like latency, error behavior, or whether quotes are estimates.
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 extremely concise: three sentences plus a short note. It front-loads the purpose, gives an example, states the return format, and adds a crucial usage caveat. No waste.
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 absence of output schema and annotations, the description covers the main purpose, example, return structure, and alternative tools. It could be enhanced by mentioning that quotes are non-binding estimates, but overall it equips the agent with essential context.
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?
All 7 parameters are fully described in the input schema (100% coverage). The tool description adds no additional parameter-level information beyond the schema, so baseline 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 'Get quotes for multi-hop routes across supported EVM chains' and provides an illustrative example. It distinguishes from Cosmos-specific tools by directing users to alternatives.
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 explicitly advises against using this tool for Cosmos destinations, directing users to xprt_farm_boost or bridge_get_quote. However, it does not clarify when to prefer this over bridge_get_quote for EVM single-hop routes.
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?
With no annotations, the description carries full burden. It discloses that the tool returns 'verified token symbols, contract addresses, and decimals' and supports specific chains. It is transparent about the output format and scope, though it does not mention rate limits or error handling, which is acceptable for a read-only list 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 consists of two concise sentences with no redundancy. The first sentence states purpose and output, the second adds supported chains and a usage hint. Every sentence is essential 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 tool's simplicity (2 parameters, no output schema, no nested objects), the description adequately covers purpose, output format, supported chains, and downstream usage. It does not mention pagination or limits, but for a list of popular tokens, this is sufficient.
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 descriptions for both parameters (chain, search). The description adds no new parameter-specific information beyond the schema; it only provides broader context about output usage. Therefore, it meets the baseline expectation for a tool with 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 'List popular tokens available for bridging on a given chain' with a specific verb (List) and resource (tokens for bridging). It distinguishes from sibling tools like bridge_chains (lists chains) and bridge_get_quote (gets quotes).
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 explicitly instructs 'Use token symbols or addresses from this list in bridge_get_quote', guiding the agent on how to use the output. It also mentions supported chains (EVM, Persistence, Cosmos Hub). However, it doesn't provide when-not-to-use or alternative tools beyond the implicit differentiation from siblings.
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 full burden. It explains the tool detects state and returns a plan, implying a read-only operation. However, it does not detail potential side effects, prerequisites (e.g., wallet existence), or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential and front-loaded with the purpose. No wasted words while conveying the personalized and state-aware nature of the tool.
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 no annotations, no output schema, and zero params, the description adequately covers what the tool does and what it returns. It could be more complete by mentioning that a wallet context is required, but overall it is sufficient.
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?
With zero parameters, schema coverage is 100%. The description adds value by explaining the tool automatically uses the current wallet state, so no parameters are needed. This exceeds the baseline expectation.
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 it provides personalized onboarding for XPRT farming by detecting wallet state and returning an action plan. It uses specific verbs and resource, distinguishing it from sibling tools like bridge and wallet utilities.
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 implies usage when the user wants to start farming XPRT rewards, but does not explicitly exclude other scenarios or mention prerequisites like having a wallet connected. Context is clear but lacks exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses that symbols resolve to verified canonical addresses only, includes a failedProviders array, lists error codes, and mentions the return format (ranked options by output amount, speed, fees). It does not mention auth needs or rate limits, but the error code 'Rate limited' hints at rate limiting. Overall, good transparency for a non-destructive query tool.
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 well-structured and front-loaded with the main purpose. It covers supported chains, token resolution, return format, preconditions, and error codes in a logical order. Every sentence adds value, though the list of providers could be shortened. Still, it is appropriately sized for the complexity.
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 tool's complexity (9 parameters, cross-chain, multiple providers) and no output schema, the description covers inputs, behavior, and outputs adequately. It describes the return as ranked options by output amount, speed, and fees, plus a failedProviders array. While it lacks detailed output structure, it provides enough context for an agent to use the tool effectively.
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% (baseline 3). The description adds meaningful context beyond the schema: explains that amounts are in human-readable units, fromChain accepts names or IDs, symbols resolve to verified addresses, providers optional defaults to all, and fromAddress format depends on chain. This extra detail justifies a score of 4.
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 gets the best cross-chain bridge quote across multiple providers, listing specific providers and supported chains. It differentiates itself from sibling tools like bridge_execute (to act on a quote) and bridge_quote_multi (implied alternative). The inclusion of error codes adds to clarity.
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?
Explicitly states 'Preconditions: None for quoting' and 'Use bridge_execute to act on a quote', providing clear when-to-use guidance. However, it does not distinguish from bridge_quote_multi or mention when to avoid using this tool (e.g., for historical data). The guidance is sufficient for the primary use case.
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 must carry the burden. It states that the tool returns structured guides with recommended tool sequences and common pitfalls, which adds behavioral context. However, it does not disclose any potential side effects (though unlikely for a help tool), auth requirements, or rate limits. The description adds modest value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no wasted words. It front-loads the purpose, then lists topics and output characteristics. Every sentence provides essential information.
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 the tool's simplicity (one parameter, no output schema, no annotations), the description is complete. It explains what the tool does, which topics are available, and what kind of output to expect. There is no missing information that would hinder correct usage.
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 100% coverage with a clear description for the 'topic' parameter. The tool description adds additional context about what the returned guides contain (structured guides with sequences and pitfalls), which enhances understanding beyond the enum values.
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 provides help and guidance on BridgeKitty, listing specific topics (overview, bridging, farming, wallet, troubleshooting). It differentiates itself from sibling tools that perform actions (e.g., bridge_execute, wallet_import).
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 lists topics and indicates the default topic is 'overview'. It implies using this tool for guidance before using other tools, but does not explicitly state when not to use it or provide alternatives. However, the sibling tools are all actions, so the usage context is clear.
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?
With no annotations, the description carries the behavioral disclosure burden. It reveals important traits: overwrite behavior with a backup warning, and the multi-chain vs EVM-only outcome based on parameter choice. This transparently informs the agent of consequences, though it could mention whether the operation is reversible or requires permissions.
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 consists of four concise sentences, each adding unique value. It front-loads the core purpose and immediately provides an alternative, then explains parameter outcomes, and ends with a follow-up action. No wasted words.
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 no output schema and three optional parameters, the description adequately covers what the tool does, the effects of inputs, and a post-action suggestion. It lacks explicit mention of return value or error conditions, but for a state-modifying tool, the behavioral and usage guidance is sufficient.
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%, so baseline is 3. The description adds value by explaining what each key type provides ('Mnemonic gives EVM + Persistence + Solana; privateKey alone gives EVM only'), which goes beyond the schema's parameter descriptions. This semantic enrichment justifies a 4.
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 purpose: 'Import existing keys.' It also distinguishes itself by detailing the effects of different inputs (mnemonic vs privateKey) and mentions an alternative method (editing .env). This provides unambiguous purpose and differentiation from sibling tools like wallet_setup.
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 explicitly offers an alternative method ('edit ~/.bridgekitty/.env directly') and advises checking state with wallet_status. While it doesn't list explicit when-not conditions, this guidance effectively helps the agent choose between methods and verify outcomes.
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?
No annotations provided, but the description discloses key behaviors: lists supported chains, deduplicates, groups by ecosystem, and shows provider support. Lacks output format details but sufficient for a read-only list tool.
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?
Three sentences, front-loaded with the core purpose, and efficient wording. Could be slightly more concise but no unnecessary content.
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 tool's simplicity (one optional param, no output schema), the description covers purpose, filtering, grouping, deduplication, and usage sequence. Lacks output structure but adequate for a listing operation.
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 one optional parameter 'search' described. The description adds value by explaining its purpose (filter by name) and giving examples, going beyond the schema's bare 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 tool lists supported chains for cross-chain bridging, specifies deduplication and grouping by ecosystem, and differentiates from sibling tools like bridge_get_quote by indicating it's for discovering routes before getting a quote.
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 instructs to use the 'search' parameter for filtering and recommends using this tool before bridge_get_quote to discover available routes, providing clear usage context and alternatives.
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?
With no annotations, the description carries the full burden. It discloses automatic RPC failover, multiple chains, default tokens, and USD valuation via CoinGecko with caching. No destructive behavior is implied, which is appropriate for a read-only 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 three sentences long, each providing essential information: what the tool does, what it returns, and when to use it. No unnecessary words.
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 no output schema, the description sufficiently explains return values (per-token balance, USD value, total portfolio value) and mentions important behavior like RPC failover and caching. For a wallet balance tool, this is complete.
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 covers all 4 parameters with descriptions (100% coverage). The description adds value by explaining default behavior (default tokens, CoinGecko with 60s cache) and the purpose of the tool. It reinforces and augments schema information.
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 checks wallet balances across EVM, Cosmos, and Solana chains, returns native and key ERC-20 token balances, and provides USD values. It distinguishes from siblings by mentioning bridging operations.
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 explicitly says 'Call this before any bridging or farming operation to verify sufficient funds and gas,' providing clear when-to-use. It doesn't explicitly mention alternatives, but context from sibling tools suggests this is the balance check tool.
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?
No annotations provided, so description carries full burden. It discloses the tool is a read-only status check and lists return values. While it doesn't specify behavior when wallet is not configured, the description is sufficiently transparent for a simple status 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?
Two short sentences, no fluff. Purpose and usage guideline are front-loaded.
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 no parameters, no output schema, and low complexity, the description provides sufficient context: purpose, return info, and order of operations relative to siblings.
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% (no parameters), baseline is 3. Description does not add parameter details, but none 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?
Description clearly states the tool checks wallet configuration and returns specific fields (address, key status, config file location). It also distinguishes from siblings by advising to call this first before wallet_setup or wallet_import.
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 instructs to call this tool first before wallet_setup or wallet_import, providing clear when-to-use and alternatives context.
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?
Even without annotations, the description thoroughly discloses behavior: returns unsigned transaction(s) by default, optional signing with wallet key, preconditions (sufficient gas, approval flow), and post-use monitoring (bridge_status). It also notes a limitation: 'Solana falls back to unsigned.' This is highly transparent.
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 dense paragraph but efficiently structured: main purpose first, then details. Every sentence adds value—preconditions, modes, approval flow, post-execution step. No redundant or vague statements. Slightly long but appropriate for a complex tool.
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?
No output schema exists, so the description must explain return values and workflow. It mentions 'unsigned transaction(s)', approval transaction sequencing, and a trackingId for bridge_status. It covers preconditions, execution modes, and post-execution monitoring, making it complete for an agent to use effectively.
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%, so baseline is 3. The description adds meaningful context: explains that slippage has a default and is reserved for future overrides, describes sign_and_send behavior across chains, and clarifies that quoteId comes from bridge_get_quote. This exceeds the schema alone.
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: 'Get the unsigned transaction data to execute a cross-chain bridge transfer.' It specifies the supported providers and distinguishes from siblings like bridge_get_quote (quote) and bridge_status (monitoring). The verb 'execute' and resource 'bridge transfer' are specific and unambiguous.
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 explicit preconditions: 'Call bridge_get_quote first and pass the quoteId.' It also explains when to use sign_and_send vs unsigned mode, and mentions handling approval transactions. While it doesn't explicitly state when not to use the tool, the context is clear for an AI agent to decide.
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?
Discloses return values (status, tx hashes, times) and notes support for all providers. No annotations provided, so description carries burden; it implies a read-only operation without stating explicitly, which is acceptable for a status check.
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?
Three sentences: purpose, usage instructions, return summary. Front-loaded and free of fluff. Every sentence adds value.
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 no output schema, the description explains return values. Covers all necessary usage aspects for a status check tool with multiple optional parameters.
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?
Schema coverage is 100%, and the description adds significant meaning by explaining the two usage modes (trackingId alone vs txHash+provider+chains) and detailing return fields. This goes beyond schema descriptions.
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 it checks the status of a cross-chain bridge transfer, lists supported providers, and specifies how to identify the transfer (tracking ID or tx hash + provider). This distinguishes it from siblings like bridge_execute or bridge_get_quote.
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 explicit instructions on when to use (after bridge_execute) and how to provide identifiers (trackingId or txHash+provider). Does not explicitly state when not to use, but the context is clear.
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?
Discloses the side effect: 'Keys saved to ~/.bridgekitty/.env'. No annotations exist, so description carries full burden. Could be more explicit about overwrite behavior or idempotency, but the hint to check wallet_status mitigates.
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 front-loaded action. Every sentence adds value: first states purpose, second adds behavioral context and usage guidance.
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?
Provides prerequisite (check wallet_status) and side effect (file save). For a setup tool with no parameters and no output schema, it covers key aspects. Lacks idempotency detail but is fairly complete.
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?
Input schema has zero parameters, so description does not need to add param info. The baseline for 0 params is 4, and the description covers the tool's operation without needing parameter 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 clearly states the verb 'Create' and the specific resource 'wallets for all supported chains (EVM, Cosmos, Solana)'. It distinguishes the tool from sibling tools like wallet_status and wallet_import by specifying the scope.
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 advises to 'Use wallet_status first to check if already configured', providing clear when-to-use context and directing to a sibling tool for pre-conditions.
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:

[![bridgekitty MCP server](https://glama.ai/mcp/servers/persistenceOne/bridgekitty/badges/card.svg)](https://glama.ai/mcp/servers/persistenceOne/bridgekitty)

Score Badge

Copy to your README.md:

[![bridgekitty MCP server](https://glama.ai/mcp/servers/persistenceOne/bridgekitty/badges/score.svg)](https://glama.ai/mcp/servers/persistenceOne/bridgekitty)

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/persistenceOne/bridgekitty'

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