On-chain treasury tools for dev teams on Base. Check vault balances, transaction history, project budgets, and trigger deposits/withdrawals/swaps via GitHub IssueOps. Soul-bound vaults anchored to GitHub ID.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 16 of 16 tools scored.
Each tool has a clearly distinct purpose: informational gets/lists, action-oriented requests with confirm_code, and a status checker. No two tools overlap in function; e.g., get_stock_price vs get_rwa_portfolio differentiate price vs holdings.
All tool names follow a consistent verb_noun pattern: get_ for retrieval, list_ for enumeration, request_ for actions requiring authorization, and check_ for status. No mixed conventions or vague verbs.
16 tools cover the full scope of Gitbank's functionality—viewing balances, portfolios, prices, transactions, and initiating deposits, withdrawals, swaps, stock trades, bounty assignments, and token launches. The count is well-proportioned for a complex financial/project management server.
The tool set provides comprehensive coverage for querying and initiating actions, but lacks a tool to cancel pending requests or to directly confirm actions (confirmation happens externally via GitHub). Minor gap, but core workflows are supported.
check_pendingACheck the status of a pending Gitbank command by its confirm_code. Returns status: pending, confirmed, executed, or expired.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm_code | Yes | The confirm_code returned by a request_* tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds value by listing the four possible status values, which is beyond annotation info. Clearly discloses what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and input, second lists outputs. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple check tool with one parameter and no output schema, the description fully explains what to provide and what to expect. The return values are explicitly listed, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and confirms the parameter description. Description adds context by stating the confirm_code comes from a request_* tool, linking it to the workflow. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'Check the status', resource 'pending Gitbank command', method 'by its confirm_code', and lists possible statuses. It distinguishes itself from sibling tools that either perform requests or retrieve other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after receiving a confirm_code from a request_* tool, but no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_project_statusAGet budget and task status for a Gitbank project. Shows total budget, spent amount, remaining, and all tasks with bounty info.
| Name | Required | Description | Default |
|---|---|---|---|
| project_name | Yes | Name of the project (as created with @gitbankbot create project) | |
| github_username | Yes | GitHub username of the project owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context on what data is returned (budget, tasks), which is valuable given no output schema. No behavioral traits beyond annotations are contradicted or omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists outputs. No unnecessary words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 2 parameters and no output schema, the description sufficiently covers the main outputs (budget, spent, remaining, tasks with bounty). No obvious gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add any additional meaning beyond what the schema already provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets budget and task status for a Gitbank project, listing specific outputs (total budget, spent, remaining, tasks with bounty). This distinguishes it from sibling tools like get_stock_price or get_rwa_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing budget/task data for a Gitbank project but provides no explicit guidance on when not to use it or alternatives. No exclusions or comparisons to siblings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rwa_portfolioAGet a GitHub user's gitStock holdings (RWA positions). Shows amount held, current value, cost basis, and P&L for each position.
| Name | Required | Description | Default |
|---|---|---|---|
| github_username | Yes | GitHub username of the portfolio owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds return field details but does not disclose any behavioral traits such as data freshness, pagination, or error handling. With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core action and return data without any unnecessary words. Every part is relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately covers the return fields. However, it lacks details on error cases (e.g., nonexistent username) and does not specify the data structure (array vs object), leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema description already explains it as 'GitHub username of the portfolio owner'. The description adds no additional meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves a GitHub user's gitStock holdings (RWA positions) and lists specific return fields (amount, value, cost basis, P&L). This distinguishes it from sibling tools like get_stock_price (single stock price) or get_vault_balance (vault balances).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to retrieve a user's RWA portfolio), but does not explicitly state when not to use it or name alternatives. The sibling list aids differentiation, but no direct exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_stock_priceAGet the live USD price of an Ondo tokenized stock from the Pyth oracle. Returns current price and timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker (e.g. NVDA, AAPL, TSLA, META, MSFT, GOOGL, AMZN, SPY, QQQ) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, providing safety profile. Description adds that it returns price and timestamp, which is consistent but does not elaborate on error handling, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, efficiently conveys purpose and output. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is nearly complete. It states return fields (price, timestamp). Minor gap: no indication of data format or precision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the ticker parameter. Description does not add additional parameter-level information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get', the resource 'live USD price of an Ondo tokenized stock', and the source 'Pyth oracle'. It distinguishes from sibling tools like list_stocks and buy/sell requests by focusing on price retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for fetching stock prices but provides no explicit when-to-use or when-not-to-use guidance. Alternatives like request_buy_stock exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transactionsAGet recent on-chain transactions (deposits, withdrawals, swaps, bounty payouts) for a Gitbank vault.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of transactions to return (default 10, max 50) | |
| github_username | Yes | GitHub username of the vault owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds specific transaction types and vault context, but does not disclose additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence of 16 words. No wasted words, clearly conveys purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers what the tool does and lists transaction types. However, since output schema is absent, details about return format, ordering, or pagination are not provided, but the tool is simple enough that the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (limit, github_username). Description does not add extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the verb 'Get', the resource 'on-chain transactions', and details types (deposits, withdrawals, swaps, bounty payouts) for a Gitbank vault. It distinguishes from sibling query tools like get_vault_balance and action tools like request_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Use is implied for reading transaction history, but no comparison to alternatives (e.g., get_vault_balance) or context on when this is appropriate versus other reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vault_balanceAGet WETH and USDC locked balance of a Gitbank vault on Base mainnet. Returns vault address and per-token balances.
| Name | Required | Description | Default |
|---|---|---|---|
| github_username | Yes | GitHub username of the vault owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds context beyond annotations: it specifies the network (Base mainnet) and the tokens (WETH, USDC), and mentions return structure (vault address and per-token balances). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the action and key details. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter, no output schema, and good annotations, the description is complete. It explains what is returned (vault address and per-token balances) and the network context. No additional information seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter github_username is fully documented in the schema. The description does not add any additional meaning beyond what the schema provides, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get', the resource 'locked balance of a Gitbank vault', and specifics: tokens (WETH, USDC) and network (Base mainnet). It distinguishes from sibling tools that deal with repos, stocks, transactions, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving vault balances but provides no explicit guidance on when to use this tool versus alternatives like get_stock_price or get_transactions. No when-not-to-use or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_reposAList GitHub accounts where the Gitbank bot is installed for a user.
| Name | Required | Description | Default |
|---|---|---|---|
| github_username | Yes | GitHub username to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's statement of 'List' is consistent. However, it adds no additional behavioral context such as response format or auth requirements, which would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words, effectively communicating the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter), the description is adequate but slightly ambiguous: 'GitHub accounts' may conflict with the tool name 'list_repos'. No output schema or mention of response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's description of 'github_username' as a string to look up.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'List' and the resource 'GitHub accounts where the Gitbank bot is installed', which is specific and distinct from sibling tools (none of which list repos/accounts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about what the tool does but provides no explicit guidance on when to use it versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_stocksAList all available Ondo tokenized stocks that can be bought via Gitbank. Each stock is backed 1:1 by real Ondo tokens on Solana and represented as a soul-bound gitStock ERC-20 on Base.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by explaining that each stock is backed 1:1 by real Ondo tokens on Solana and represented as a soul-bound gitStock ERC-20 on Base. Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's purpose and key characteristics, with no unnecessary words. Front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what is listed and the backing, but does not specify the output format or fields returned. Since there is no output schema, the description could be more complete by hinting at the structure of the returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter semantics; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all available Ondo tokenized stocks that can be bought via Gitbank, specifying the resource and action. It distinguishes from siblings like get_stock_price (price of a specific stock) and request_buy_stock (buy action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing available stocks before purchase, but does not explicitly state when to use this tool vs alternatives like get_stock_price or request_buy_stock. It provides context by mentioning 'can be bought via Gitbank.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_assign_bountyAInspectRequest a bounty assignment to a contributor for a GitHub issue. Returns a confirm_code the user must post on GitHub to authorize execution.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | GitHub repo in owner/repo format | |
| token | Yes | Token symbol: USDC or WETH | |
| amount | Yes | Bounty amount | |
| contributor | Yes | GitHub username of the contributor to assign | |
| issue_number | Yes | GitHub issue number | |
| github_username | Yes | GitHub username of the project owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by explaining the return of a confirm_code and the need for the user to post on GitHub for authorization, revealing the request's asynchronous nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no wasted words. The first sentence states the action and resource, the second adds critical return and follow-up information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has 6 required parameters and no output schema, the description covers the return value and user action. However, it lacks details on timeout, error scenarios, or what happens after posting, which could be important for a request tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions in the schema are sufficient. The tool description does not add extra parameter details beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Request') and resource ('bounty assignment for a GitHub issue'), and distinguishes from sibling tools like check_pending or get_project_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as other request tools (e.g., request_buy_stock). The description implies a two-step process but does not explicit prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_buy_stockAInspectBuy an Ondo tokenized stock using USDC from the user's Gitbank vault. Bridges USDC from Base to Solana via CCTP, swaps for Ondo stock on Jupiter, and mints a soul-bound gitStock token on Base as proof of custody. Returns a confirm_code the user must post on GitHub to authorize.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker to buy (e.g. NVDA, AAPL, TSLA) | |
| usdc_amount | Yes | Amount of USDC to spend (from vault balance) | |
| github_username | Yes | GitHub username of the buyer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) but no destructive behavior (destructiveHint=false). The description adds significant transparency: it details the bridging from Base to Solana via CCTP, swap on Jupiter, and minting of a soul-bound gitStock token. It also reveals the asynchronous authorization step (returns confirm_code for GitHub posting). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. The first sentence states the main action. The second explains the process. The third explains the return value and user action needed. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no output schema, the description covers all key aspects: input parameters (implicitly via schema), process steps, and return value (confirm_code) with required user action. It is complete for an agent to decide and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description does not add new meaning beyond confirming that usdc_amount is from vault balance, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Buy an Ondo tokenized stock using USDC from the user's Gitbank vault.' The verb 'Buy' and resource 'Ondo tokenized stock' are specific. It distinguishes from sibling tools like request_sell_stock and request_deposit by describing the unique multi-step flow (bridge, swap, mint).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: to buy stock using USDC from the vault. It does not explicitly list when not to use, but the sibling names provide contrast. The context (requires GitHub username, uses vault balance) gives clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_depositAInspectRequest a deposit into a Gitbank vault. Returns a confirm_code the user must post on GitHub to authorize execution. Supported tokens: USDC, WETH.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol: USDC or WETH | |
| amount | Yes | Amount to deposit | |
| github_username | Yes | GitHub username of the vault owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds critical behavioral context beyond annotations: the tool is non-destructive but requires external authorization via GitHub. The openWorldHint annotation is aligned, and the two-step process is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and return value. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is low with three parameters fully described. The description covers the main flow and return type. Minor gap: it doesn't mention prerequisites like vault existence, but the schema's github_username requirement implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions (100% coverage). The description adds only the supported token list, which is already partially in the schema. No additional semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Request a deposit into a Gitbank vault') and the return value ('Returns a confirm_code the user must post on GitHub to authorize execution'). It distinguishes well from sibling tools like request_withdraw and request_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies supported tokens (USDC, WETH) and implicitly that this tool is for initiating deposits. However, it could explicitly contrast with related tools (e.g., request_withdraw) to provide stronger guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_launch_tokenAInspectRequest a token launch on Base Mainnet via Clanker (MCP-exclusive launchpad). Requires a 0.01 ETH creator buy-in: the ETH buys the newly launched token and distributes it to all $GITBANK holders. Returns a confirm_code and payment instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X/Twitter profile URL | |
| link | No | Project website URL | |
| logo | No | Token logo image URL | |
| name | Yes | Full token name | |
| symbol | Yes | Token ticker symbol (2-10 chars, uppercase) | |
| ai_client | No | Name of the AI assistant calling this tool (e.g. claude, chatgpt, grok, kimi, gemini). Used in the auto-tweet after launch. | |
| description | Yes | Short token description | |
| creator_wallet | Yes | Creator's Ethereum wallet address (0x...) on Base Mainnet — must send 0.01 ETH from this address to the treasury before confirming | |
| github_username | Yes | GitHub username of the launcher |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as not read-only and not destructive. The description adds critical behavioral context by disclosing the financial requirement (0.01 ETH buy-in) and the output (confirm_code and payment instructions), which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and key requirement. Every sentence adds value with no redundancy, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description covers the essential purpose, financial requirement, and output expectation. It could be more complete by explaining the confirm_code format or post-launch steps, but it provides sufficient context for an agent to proceed correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some context about the buy-in flow but does not elaborate on parameter meanings beyond the schema descriptions. It explains that creator_wallet must send ETH and that the buy-in funds are used, which provides moderate additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool requests a token launch on Base Mainnet via Clanker, specifying the MCP-exclusive launchpad and including key details like the 0.01 ETH creator buy-in. It distinguishes from siblings by being the only token-launch tool among financial actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the prerequisite of a 0.01 ETH buy-in and the distribution mechanics, providing clear context for when to use. However, it does not explicitly state when not to use or compare to sibling tools, though sibling tools are clearly different (financial operations vs. launch).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_sell_stockASell Ondo tokenized stock back to USDC. Burns the user's soul-bound gitStock tokens on Base, sells Ondo stock for USDC on Jupiter (Solana), and bridges USDC back to the Gitbank vault via CCTP. Returns a confirm_code the user must post on GitHub to authorize.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount of gitStock tokens to sell (in stock units, 6 decimal places) | |
| ticker | Yes | Stock ticker to sell (e.g. NVDA, AAPL, TSLA) | |
| github_username | Yes | GitHub username of the seller |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations indicating destructiveness, the description details the burning, selling on Jupiter, bridging via CCTP, and the need for a GitHub confirm_code, adding significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the overall process and return value but lacks details on error scenarios, prerequisites, or the implications of the authorization step, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameter descriptions with 100% coverage, and the description does not add further meaning to the parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sells Ondo tokenized stock back to USDC, outlines the multi-step process, and distinguishes it from sibling tools like request_buy_stock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for selling stock but does not explicitly state when to use it versus alternatives, nor does it provide conditions for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_swapAInspectRequest a token swap inside a Gitbank vault (e.g. USDC to WETH). Returns a confirm_code the user must post on GitHub to authorize execution.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount to swap | |
| to_token | Yes | Destination token: USDC or WETH | |
| from_token | Yes | Source token: USDC or WETH | |
| github_username | Yes | GitHub username of the vault owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it reveals that the tool returns a confirm_code that the user must post on GitHub for authorization, explaining that execution is not immediate. This is crucial behavioral information not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences covering purpose, example, and return value/authorization. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output (confirm_code) and the required user action on GitHub. It covers essential context for a 4-parameter tool, though could mention prerequisites or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add new parameter-level details beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Request a token swap'), specifies the resource ('inside a Gitbank vault'), and includes an example ('USDC to WETH'). It also mentions the return value (confirm_code), distinguishing it from sibling tools like request_deposit or request_withdraw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (token swap in a vault) but does not explicitly state when not to use or provide alternatives. With many sibling request_* tools, explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_transferAQueue a vault-to-vault token transfer to another GitHub user on Base Mainnet. Both sender and recipient must have a Gitbank vault. Returns a confirm_code the user must post on GitHub to authorize. The GitHub account identity is verified on-chain at confirmation time — only the vault owner can authorize. Supported tokens: USDC, WETH.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol: USDC or WETH | |
| amount | Yes | Amount to transfer | |
| github_username | Yes | GitHub username of the sender (vault owner) | |
| to_github_username | Yes | GitHub username of the recipient |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations: it reveals the async nature (returns a confirm_code), security model (on-chain verification, only vault owner can authorize), and supported tokens (USDC, WETH). No contradiction with annotations (destructiveHint=true is consistent with a transfer).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states core function, second covers prerequisite and outcome, third explains verification. Every sentence carries weight, front-loaded with the most important action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, the description specifies the return (confirm_code) and mentions supported tokens. It could add failure modes or rate limits, but for a 4-parameter tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaningful context: the vault requirement and the confirm_code flow, which are not in the schema. It clarifies that the transfer is on Base Mainnet (not a parameter) and that both parties need a vault.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (queue), resource (vault-to-vault token transfer), and scope (to another GitHub user on Base Mainnet). It differentiates from siblings by specifying a transfer between vaults, contrasting with other request_* tools like request_deposit or request_swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (both sender and recipient must have a Gitbank vault) and outlines the authorization process (post confirm_code on GitHub). It does not explicitly exclude alternatives, but the context of vault-to-vault transfers makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_withdrawARequest a withdrawal from a Gitbank vault to an external wallet address. Returns a confirm_code the user must post on GitHub to authorize execution.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol: USDC or WETH | |
| amount | Yes | Amount to withdraw | |
| to_address | Yes | Destination wallet address (0x...) | |
| github_username | Yes | GitHub username of the vault owner |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior. The description adds valuable context: the two-step authorization process requiring a confirm_code posted to GitHub, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the key action and result. Every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a withdrawal request tool with 4 parameters and no output schema, the description adequately explains the return value and the prerequisite GitHub action. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add extra meaning to parameters 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (request a withdrawal), the resource (from a Gitbank vault to an external wallet address), and the outcome (returns a confirm_code). It distinguishes from siblings like request_deposit or request_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving funds out of a vault to an external wallet. It does not explicitly exclude when not to use or name alternatives, but the context is clear given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
