@blueprintaix/blueprint-mcp

Official

by BlueprintAIx

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools have clearly distinct purposes, especially the chain-specific vault operations (Solana, EVM, Sui). Minor ambiguity exists between find-tokens and fetch-tokens, and between fetch-vault-analytics and fetch-vaults, but the descriptions provide sufficient guidance.
Naming Consistency2/5
Naming is inconsistent, mixing hyphenated names (find-tokens, solana-deposit-to-vault) with underscored names (get_wallet_address, execute_intent). Also, both 'fetch' and 'get' are used as verbs, and there is no uniform pattern across chain-specific and generic tools.
Tool Count5/5
15 tools is well-scoped for a multi-chain vault management server. Each tool serves a necessary function, covering three chains with fetch/deposit/withdraw operations plus supporting utilities for tokens, analytics, wallet address, and intent execution.
Completeness4/5
The core lifecycle is covered: fetching vaults, depositing, withdrawing, and analytics. Minor gaps exist, such as the lack of a complete-withdraw tool for EVM and Sui chains (only Solana has it) and no explicit portfolio/balance tool, but agents can work around these.
Average 3.6/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden, but it only restates the basic action with no disclosure of side effects, reversibility, permissions, or post-conditions. It does not go beyond the verb 'withdraw' to explain behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the verb front-loaded and no redundancy. The word 'certain' adds little value and the phrasing is slightly awkward, but it is still appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and empty annotations, the description provides only a minimal statement. It fails to explain the interplay among amountUsd, amountNative, and percentage, which is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'USD-equivalent asset', which loosely relates to amountUsd, but adds no new semantics beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Withdraw' and the resource 'vault on Solana/SVM-chain', distinguishing it from EVM or Sui siblings. However, the phrase 'certain USD-equivalent asset' is somewhat vague about which asset, so it's not perfect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The chain name implies usage for Solana, but no explicit when-to-use or comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It only says 'deposit' without explaining that this likely executes an on-chain transaction, may be irreversible, requires wallet connectivity/approvals, or what success/failure looks like. Very limited transparency for a financial transaction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than efficiently complete. It lacks critical context about the deposit process, making it less useful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is inadequate. It does not clarify how the amount parameters work together, what the vault represents, or the transactional nature. The description is far from complete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-level meaning beyond the schema; it does not explain the relationship between amountUsd, amountNative, and percentage. The schema itself provides decent descriptions, but the placeholder 'SYSTEM PARAMETER' for requestId is unhelpful and not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deposit) and target (vault on Solana/SVM-chain), which distinguishes it from EVM and Sui deposit tools. However, 'certain USD-equivalent asset' is vague and does not specify which asset or how it is determined, slightly impairing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the chain name (Solana/SVM), but no explicit guidance is given about when to choose this tool over sibling tools like 'evm-deposit-to-vault' or 'sui-deposit-to-vault'. The description does not state prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full responsibility for behavioral disclosure. It does not mention side effects, irreversibility, authorization requirements, or what happens after completion. 'Completes' implies a state change but no further context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks crucial context such as prerequisites (e.g., a prior pending withdrawal), return values, or outcomes. Since there is no output schema, the description is insufficient for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description, so the base score is 3. The tool description adds no parameter-specific meaning, but the schema adequately explains vaultId, withdrawalId, and solanaWalletAddress.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Completes a pending withdrawal') and the resource ('specified vault on *Solana/SVM-chain*'). It distinguishes from sibling solana-withdraw-from-vault by using 'completes' rather than 'initiates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The description only defines what it does, leaving the agent to infer that it should be used after a withdrawal is pending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It only says 'deposit', which implies a write operation, but gives no details on side effects, reversibility, prerequisites, or how funds are handled. Minimal transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler or redundancy. It is appropriately front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, this 5-parameter transactional tool needs richer context. The description does not explain expected return values, the relationship between amountUsd and amountNative, or what constitutes a 'USD-equivalent asset'. It is inadequate for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds no parameter-specific context, but the high schema coverage means it does not need to compensate. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a deposit action on a vault, with an explicit chain qualifier 'Sui/SUI-chain' that distinguishes it from sibling tools for Solana/EVM. However, the phrase 'certain USD-equivalent asset' is vague about which asset is involved.
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 use for Sui vaults via the chain qualifier, which is clear context. It does not explicitly mention alternatives or exclusions, but the chain-specific wording is sufficient to differentiate from other deposit tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the action and chain scope, omitting critical details such as whether this is an on-chain transaction, permissions required, side effects, reversibility, or execution status. This is a significant transparency gap for a withdrawal 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 a single concise sentence, front-loaded with the action and resource, and efficiently lists the chain scope. While it could be considered slightly vague, it contains no unnecessary filler, earning a high score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a multi-parameter withdrawal tool. It does not explain the relationship between amountUsd and amountNative, the purpose of requestId, or any prerequisites or failure behavior. With no output schema and sparse annotations, this leaves the agent under-informed about edge cases and execution details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, and the description adds no additional meaning beyond the schema. The baseline of 3 is appropriate because the schema already documents each parameter, so the description does not need to compensate, but it also contributes nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (withdraw) and the resource (vault), and explicitly scopes it to Ethereum/EVM chains with a list of supported networks. This distinguishes it from sibling tools targeting Solana or Sui, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the supported EVM chains, which implies when this tool should be used. However, it does not explicitly mention alternatives or exclusion criteria (e.g., 'use solana-withdraw-from-vault for Solana'), so it falls short of a fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It only states the action ('withdraw') without disclosing side effects, permissions, reversibility, or what happens to the vault. This is too minimal for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the main action and resource. However, the phrase 'certain USD-equivalent asset' is slightly vague and could be more specific, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description is too brief to provide necessary context. It does not explain when to use amountUsd vs amountNative, what requestId is (beyond schema), or what the response contains. This is inadequate for a withdrawal tool with multiple optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents each parameter. The description adds no additional parameter-level guidance beyond the schema, not even clarifying the relationship between amountUsd and amountNative. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('withdraw'), identifies the resource ('vault'), and scopes it to Sui/SUI-chain, which clearly distinguishes it from sibling tools like solana-withdraw-from-vault and evm-withdraw-from-vault. The mention of 'USD-equivalent asset' further clarifies the asset type.
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 for Sui-chain vault withdrawals, providing clear context. However, it does not explicitly state when not to use it or mention alternatives (e.g., using solana-withdraw-from-vault for Solana), so it misses the 'explicit when/when-not' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It only says 'Deposit certain USD-equivalent asset' without mentioning fund movement, reversibility, approval requirements, or side effects. For a financial transaction tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action, target, and scope with a useful chain list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a deposit transaction, the description is too thin. It omits how amountUsd relates to amountNative, what 'USD-equivalent asset' means, and what the expected outcome is. With no annotations and no output schema, the description does not provide enough context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meanings are already documented in the schema. The description does not add any additional semantics (e.g., relationship between amountUsd and amountNative), so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action clearly: 'Deposit certain USD-equivalent asset to a vault on *Ethereum/EVM chains*' and lists supported networks. This distinguishes it from sibling tools like solana-deposit-to-vault (different chain) and evm-withdraw-from-vault (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description scopes the tool to EVM chains, which provides clear context for when to use it (deposits on Ethereum, Polygon, etc.). However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It merely restates the tool's name ('Fetch token details') and does not address potential side effects, error handling, authentication requirements, or the read-only nature of the operation. This leaves significant gaps for a tool with no annotation safety hints.
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 compact and front-loaded: the first line states the core purpose, and the second line gives a concise usage directive. Every sentence earns its place with no fluff or repetition, making it highly efficient.
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?
Despite lacking an output schema, the description lists the returned fields (name, symbol, decimals, USD price) and provides usage context ('before asset allocation decisions'). It does not explicitly describe error behavior for invalid token IDs, but given the simplicity of the tool and the rich schema, it is reasonably complete, earning a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for both parameters, including a detailed description of tokenIds with an array example and requestId marked as SYSTEM PARAMETER. The description adds the nuance 'exact token id' and the return fields, but these do not substantially enrich the parameter semantics beyond the schema. Thus the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch') and resource ('token details by exact token id'), and lists the specific fields returned (name, symbol, decimals, USD price). It does not explicitly contrast with sibling find-tokens, but 'exact token id' implies a distinct lookup behavior from search, giving it a 4 rather than 5.
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 instruction 'Use this tool before making any asset allocation decisions' provides a clear, specific context for when the tool should be invoked. However, it does not mention when not to use it or alternatives (e.g., find-tokens for searching), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that results include basic vault information and transactional identifiers, which is useful for downstream operations. However, it does not explicitly state read-only behavior, pagination, or that the default limit of 6 means it does not fetch 'all' unless the limit is increased.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The hint sentence provides valuable output context, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without an output schema, the description should fully explain the return format. It gives examples of fields but not a complete list, and it does not address the default limit or behavior when no limit is specified. It is adequate for a basic fetch tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'limit' parameter with a clear description and default. The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch/Search') and clearly identifies the resource ('all available vaults from across *Solana/SVM-chain*'). This distinguishes it from EVM and Sui siblings and from action-oriented tools like deposit/withdraw. The hint about result contents reinforces the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Solana/SVM vault fetching via the chain qualifier, but it does not provide explicit when-to-use guidance or mention alternatives like fetch-vault-analytics. There are no exclusions or complementary tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the operation as 'Fetch/Search all available vaults' but does not mention read-only nature, authentication, rate limits, pagination, or the effect of the 'limit' parameter. The hint about returned fields adds some context, but the description is generally thin on operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sections that are front-loaded with the main purpose. The 'Hints' bullet adds useful return-value context without excess. Every sentence earns its place and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with a single parameter and no output schema, the description covers the core purpose and some return-value details (vault name, apy, vaultId, tokenAddress). However, it omits important behavioral context (e.g., what 'all available' means with a default limit, error behavior, or whether any filtering is possible), leaving some gaps in completeness.
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% (the only parameter 'limit' has a description). The description does not add any additional meaning about parameters; it focuses on return values instead. Baseline 3 is appropriate since the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch/Search') and resource ('all available vaults') scoped to Sui/SUI-chain, distinguishing it from sibling tools like solana-fetch-vaults and evm-fetch-vaults. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly scopes the tool to Sui/SUI-chain, providing clear context for when to use it over other chain-specific fetch tools. However, it does not explicitly state exclusions or mention alternatives like 'use solana-fetch-vaults for Solana', so it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It states the primary action (fetching addresses) but omits details like whether it returns a single address or an array, any authentication requirements, or response format. This leaves ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the verb 'fetch' and no redundant words. Every word contributes meaning, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), but the description does not specify the return shape or whether addresses are chain-specific. Given the blockchain context from siblings, ambiguity about which chains or address formats are returned makes this only partially 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 tool has zero parameters, so the baseline is 4. The description adds no parameter semantics because there are none to explain. The schema already covers everything with no properties.
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 'fetch all the wallet addresses of the user' uses a specific verb (fetch), resource (wallet addresses), and scope (of the user). It clearly distinguishes from sibling tools that focus on tokens, vaults, and intent execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool when needing the user's wallet addresses. However, it provides no explicit when-to-use vs alternatives or exclusions. With no overlapping siblings, implicit guidance is sufficient but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses output contents ('basic vaults information' and 'transactional identifiers') and hints at performance behavior, but does not explicitly state read-only nature, error handling, or prerequisites. This is adequate but not rich.
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 paragraphs with no fluff. Purpose is front-loaded, the chain list is compact, and the hints section earns its place by adding practical usage advice. Every sentence contributes value.
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?
The description adequately covers the tool's purpose, network scope, and output contents (basic info + identifiers). Since there is no output schema, the mention of result fields helps the agent anticipate return values. It stops short of detailing edge cases or performance limits, but is fairly complete for a fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already well-described (e.g., limit default and personalization trigger). The description adds only a performance hint for the networks parameter, which is useful but not necessary beyond the schema. 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 the tool 'Fetch/Search all available vaults from across Ethereum/EVM chains' and enumerates supported chains, distinguishing it from the Solana and Sui fetch-vault siblings. The scope and resource are 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?
Provides clear context by encouraging batches network lists for performance optimization, but does not explicitly state when to use this tool over the sibling 'fetch-vault-analytics' or when not to use it. The EVM-specific scope implicitly differentiates from Solana/Sui variants.
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?
Annotations are empty, so the description bears full responsibility for behavioral disclosure. It makes clear this is a read-only fetch operation and mentions APY as included data, but it does not disclose return structure, potential errors, or whether any filters or pagination exist. This is adequate but not deeply informative.
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 compact and front-loaded, with the core purpose in the first sentence. The instructions are direct and actionable, adding value without redundancy. Every sentence earns its place.
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 params, no output schema, no annotations), the description is largely complete: it defines the purpose, gives usage guidance, and the schema covers parameter details. It could be improved by describing the output format, but the missing detail is not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions, including the array format for vaultIds and the system nature of requestId. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Fetch detailed analytics data for vaults' with a specific focus on 'core vault performance data such as APY.' This distinguishes it from sibling tools like solana-fetch-vaults or evm-fetch-vaults, which are likely focused on retrieving vault lists rather than analytics.
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 usage context: 'Use this tool before making any asset optimization decisions' and 'Use this tool when rebalance/compare/analyze vaults.' This gives clear when-to-use guidance, though it does not mention when not to use it or name alternatives.
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?
There are no annotations, so the description carries the full burden. It discloses the key behavior (signing and sending a transaction to the blockchain) but does not mention consequences such as irreversibility, gas costs, or required prerequisites. The description is concise but lacks additional behavioral context that would help an agent assess the impact.
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, both front-loaded with essential information. The first sentence states the purpose, the second provides usage guidance. There is no redundant or filler content; every word earns its place.
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 annotations and output schema, the description is fairly complete for a simple execution tool. It explains what it does and when to use it, and the parameter schema covers the inputs. It does not describe return values or downstream effects, but these are not critical for correct invocation.
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 description coverage is 100%, with both parameters well-described in the schema. The description adds value by clarifying that the 'intent' comes from deposit/withdraw tools, linking the parameter to the sibling tools and usage flow. This goes slightly beyond the schema's generic 'blueprint tools' phrasing.
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: 'Executes an intent by signing and sending the transaction to the blockchain.' It names a specific verb and resource (executing an intent) and distinguishes from sibling deposit/withdraw tools by explicitly stating it is used after receiving an intent from them.
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 guidance on when to use the tool: 'Use this after receiving an intent from deposit/withdraw tools.' It gives clear context and sequencing, though it does not name explicit alternatives or exclusions beyond this. The mention of deposit/withdraw tools implies the alternative (using those tools to create intents).
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 burden. It clearly signals a read-only discovery operation via 'Finds' and 'returns token details,' and explains the 'unknown/unshown' scope. It does not disclose edge cases like no results or pagination, but for a search tool this is adequate.
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 concise with a front-loaded verb and resource, followed by a single actionable usage instruction. Every sentence adds value, with no redundancy or filler.
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?
The description is complete for a search tool: it explains what it finds, when to use it, and what it returns. With no output schema, stating that it returns token details is sufficient. The schema covers parameter details, so the description does not need to repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-specific meaning beyond saying 'specified chain/network' and the general query/search purpose. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Finds') and resource ('unknown/unshown tokens on the specified chain/network'), and clarifies that it returns token details for transactional operations. This clearly distinguishes it from sibling tools like fetch-tokens, which likely handles known/shown tokens.
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 an explicit when-to-use instruction: 'Only use this tool when target/underlying token is not provided in the context / chat history yet.' This gives a clear contextual trigger and implies not to use it when the token is already known, though it does not name an alternative tool explicitly.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BlueprintAIx/blueprint-mcp'

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