Fluid MCP Server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation3/5
Most tools are clearly distinct by resource (fToken vs vault) and action (get vs build). However, fluid_get_vault_position and fluid_get_vault_by_nft have overlapping scopes (both take an NFT ID and return position info), and fluid_get_all_ftokens vs fluid_get_all_ftokens_details could cause confusion. Descriptions help but boundaries are not always crisp.
Naming Consistency4/5
All tools follow a fluid_verb_noun pattern with snake_case, using only two verbs (get and build). The naming is largely predictable, with minor deviations like fluid_get_vault_by_nft (preposition) and fluid_get_previews (vague object). Overall, the convention is consistent.
Tool Count3/5
At 24 tools, the server is on the high end for its scope. Some tools feel duplicative (four vault operate variants could be parameterized, and multiple get-specific vs get-all pairs exist). The count is justified by two product areas plus tx building, but it feels slightly heavy.
Completeness4/5
The tool surface covers read and write operations for both lending (fTokens) and vaults, including approvals and native variants. Minor gaps exist: no batch vault data retrieval and no direct way to fetch a user's vault positions without first getting NFT IDs. Core workflows are fully supported.
Average 3.7/5 across 22 of 24 tools scored. Lowest: 2.9/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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'build an unsigned transaction,' which implies no execution, but it doesn't specify the return format, supported operations (open/adjust/close), or any required authentication/input conditions. The parenthetical about collateral type adds domain context but not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary purpose. The parenthetical adds useful domain distinction without 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?
For a tool with 10 parameters and no output schema, the description is too minimal. It doesn't explain the operation modes (e.g., nft_id 0 opens a new position), the balance of collateral and debt, or how this tool fits into the broader vault interaction workflow. The brief description leaves the agent to infer significant context from the schema alone.
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 90%, with 9 of 10 parameters described, so the baseline is 3. The description itself adds no parameter-specific meaning beyond the schema, and it doesn't clarify the role of rpc_url (the only undocumented parameter) or the relationship between collateral amounts and debt.
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 tool builds an unsigned transaction for a Vault T2, with a specific verb+resource. It adds a brief definition of T2 (dual-asset collateral, single-asset debt), which helps differentiate from T1/T3/T4 vault types, though it doesn't explicitly name alternatives.
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 on when to use this tool versus sibling vault operate tools (T1, T3, T4) or other transaction builders. The description only states what the tool does, with no context on use cases, prerequisites, or exclusions.
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 of behavioral disclosure. It reveals that the tool returns decoded supply, borrow, liquidation status, vault config, and rates, which is useful. However, it does not explicitly state that the operation is read-only, does not mention error behavior (e.g., if NFT ID is invalid), or note the optional rpc_url behavior. The implicit 'Get' verb suggests a safe read, but the description lacks explicit safety or side-effect transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every sentence adds value. It avoids fluff and is appropriately sized for a get-by-ID tool. This is exemplary conciseness.
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?
In the absence of an output schema, the description lists key return elements (supply, borrow, liquidation, vault config, rates), which gives a good overview. However, it lacks details on result structure, potential edge cases (e.g., non-existent NFT), or the role of the optional rpc_url parameter. Given the tool's complexity, the description is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67%, with chain and nft_id described. The tool description does not add meaning beyond the schema for these parameters; it merely repeats the NFT ID concept. The optional rpc_url parameter has no description in the schema and is not mentioned in the description, so the description fails to compensate for that gap. Overall, the description provides no additional parameter semantics.
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 tool's function: 'Get a specific vault position by its NFT ID' with a specific verb and resource. It also explains the NFT representation and lists return contents, which adds context. However, it does not explicitly distinguish itself from the sibling tool 'fluid_get_vault_by_nft', which likely performs a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention criteria, prerequisites, or exclusion cases. The existence of overlapping siblings (e.g., fluid_get_vault_by_nft) makes this gap more significant, as the agent cannot determine which tool to select for a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose whether the transaction opens, closes, or adjusts a position, potential reverts, permission requirements, or that it is a builder that does not send the transaction. The phrase 'unsigned transaction' hints at the builder role but is minimal.
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 clearly communicates the core purpose without redundant words. It is front-loaded and appropriately sized for a simple, well-named tool.
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 (13 parameters, dual-asset collateral/debt, slippage ranges) and no output schema, the one-sentence description is insufficient. It fails to explain the operational meaning of the parameters (e.g., that amounts represent changes, how slippage limits work, or the overall action 'interact' performs on a T4 vault).
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 high (92%), and individual parameter descriptions already explain each field. The tool description adds no additional parameter meaning, so it does not exceed the baseline of relying on the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('build') and resource ('unsigned transaction to interact with a Vault T4'), and explicitly mentions 'dual-asset collateral, dual-asset debt', which distinguishes it from T1/T2/T3 vault builders. It is clear what the tool does and which vault type it targets.
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 explicit guidance on when to use this tool versus sibling vault builders (T1, T2, T3) or lending tools. It implies usage only through the vault type name, but does not explain selection criteria or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a read-only operation, but the description does not disclose any edge cases (e.g., behavior if user has no position), required permissions, or side effects. Since it is a getter, the risk is low, but the description adds minimal behavioral context beyond the action itself.
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 starts with the main action and resource, then lists what it returns. There is zero waste, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description provides the core purpose and return fields, which is adequate. However, it lacks context about edge cases, error conditions, or how to set up the RPC URL. Given the moderate complexity and absence of annotations, it is barely sufficient but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (three of four parameters have descriptions). The description does not add any meaningful parameter semantics beyond the schema. It mentions return values (fToken shares, underlying asset value, etc.) but does not explain 'rpc_url', which is left undocumented in the schema. Thus, the description provides little additional value for parameter understanding.
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 ('Get') and identifies the resource ('a user's position in a specific fToken lending pool'), which clearly distinguishes it from sibling tools like 'fluid_get_user_all_positions' by emphasizing 'specific'. The return values are also listed, further clarifying 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It does not mention that for all positions one should use 'fluid_get_user_all_positions', nor does it explain prerequisites. The context is only implied by the name and required parameters, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It only discloses that the output is an unsigned transaction, but does not explain the operational effects (e.g., collateral changes, debt changes, slippage protection) or any prerequisites like approvals. This is minimal disclosure for a transaction-building 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, focused sentence with no redundant information. It is concise, though it could be expanded with more useful detail; still, it 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?
For a complex tool with 10 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain the semantics of the vault type or how parameters relate (e.g., collateral vs debt changes), and it provides no information about the return value. This leaves significant gaps for an agent deciding when to use it and what to expect.
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 90%, so parameters like chain, nft_id, new_col, and debt_shares_min/max are already explained. The description adds no extra meaning to the parameters, only the vault type context, which is not parameter-specific. The baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Build an unsigned transaction' and the resource 'Vault T3', and it distinguishes this tool from siblings by specifying the vault type 'single-asset collateral, dual-asset debt'. This directly differentiates it from T1, T2, and T4 vault operate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for interacting with Vault T3 positions but provides no explicit guidance on when to use this tool versus alternatives (e.g., T1/T2/T4). It does not mention exclusions or specific scenarios like opening, adjusting, or closing a position.
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 clearly states the tool lists addresses and adds background on fTokens (ERC4626, lending pool share), implying a read-only operation. However, it does not disclose response format, pagination, or any error/rate-limit behavior, which is a gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the tool's purpose and scope, and the second adds useful domain context about fTokens. There is no redundant or filler content, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description is the only source for return semantics and safety. It mentions 'addresses' but not the exact structure (e.g., array of strings or objects). It also fails to differentiate from fluid_get_all_ftokens_details, and the rpc_url parameter use case is unexplained, making the tool insufficiently specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: 'chain' is described, but 'rpc_url' has no description. The description mentions 'on a chain' but does not explain the role of rpc_url or any optional parameters. It fails to compensate for the incomplete schema, leaving the agent uncertain about how to handle the rpc_url parameter.
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 'List' with a clear resource 'all fToken addresses' and scope 'on a chain'. It distinguishes from the sibling tool fluid_get_all_ftokens_details by specifying it returns addresses only, avoiding ambiguity.
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 explicit guidance on when to use this tool versus the many siblings, such as fluid_get_all_ftokens_details. It does not state any exclusions or alternative tool recommendations, leaving the agent to infer usage context.
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 implies a read-only operation and adds that the position summary is 'decoded', but it does not disclose potential failure modes, input validity requirements, or whether it queries the blockchain directly. It is not misleading, but it lacks rich behavioral detail.
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 with no filler. It front-loads the action and the expected outputs, making it easy to read and process.
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 tool returns a 'decoded position summary' but the description does not explain what that includes, and there is no output schema to fill the gap. It also does not contextualize the tool among many sibling getters, leaving an agent unsure when to choose this over similar options. The description is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes chain and nft_id; the tool description adds no new meaning for these parameters. The rpc_url parameter is undocumented in both the schema and description. With schema coverage at 67%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the vault address and decoded position summary for a specific vault position NFT ID. It uses a specific verb ('Get') and resource, and distinguishes from siblings like fluid_get_vault_data (likely by vault address) and fluid_get_user_vault_nft_ids (which lists NFT IDs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites like obtaining the NFT ID via fluid_get_user_vault_nft_ids, nor does it clarify differences from fluid_get_vault_position. The description gives no context about which scenarios favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action of getting NFT IDs, without mentioning return format, side effects (or lack thereof), limitations, or any prerequisites. The 'all' implies comprehensiveness but no further detail is given.
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 is concise and free of unnecessary words. It earns its place by clearly stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description provides adequate context: it returns all vault position NFT IDs for a user. However, it could be more complete by noting the return type or any potential edge cases, but given the simplicity, a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents two of three parameters (chain, user_address), but the tool description adds no additional meaning beyond the schema. The rpc_url parameter lacks a schema description and the tool description does not compensate, leaving this parameter under-explained.
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: to retrieve all vault position NFT IDs for a specified user address. It uses a specific verb ('Get') and resource ('vault position NFT IDs'), and distinguishes it from sibling tools that focus on other aspects like vault type or individual positions.
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 implicitly indicates when to use it (when you need a user's vault NFT IDs) but does not explicitly state when not to use it or mention alternatives. Given the sibling tools are contextually available, the usage context is clear but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context by noting the 'single call' efficiency and listing returned fields (names, rates, TVL, underlying assets). However, it omits operational details such as response format, potential size limits, or any prerequisites, which are pertinent for a tool that retrieves all records.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence that front-loads the core action and returns a clear value proposition. The second phrase ('Perfect for a lending dashboard') adds minimal fluff but does not detract. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description partially explains return values (names, rates, TVL, underlying assets) but leaves out the precise structure or any pagination details. It is adequate for a simple bulk-getter but lacks completeness in terms of response format expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'chain' has a description in the schema, but 'rpc_url' is undocumented. The description does not compensate for the undocumented parameter; it only references 'chain' generically and does not explain rpc_url's purpose or relation. Since the description adds no parameter-level meaning beyond the schema, the score is below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get details for ALL fTokens on a chain in a single call — names, rates, TVL, and underlying assets.' It specifies the verb ('Get'), the resource ('ALL fTokens'), and scope ('on a chain in a single call'), distinguishing it from sibling tools like fluid_get_all_ftokens (likely just token list) and fluid_get_ftoken_details (single token).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case ('Perfect for a lending dashboard') but does not explicitly state when to use this tool versus alternatives or mention any exclusions. It implies usage for bulk detail retrieval but lacks explicit when-to-use/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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states what the tool returns ('combined fToken details and user position data') but does not disclose any side effects, permissions, error conditions, or the fact that it is a read-only operation. The description adds no behavioral context beyond the tool's name and basic return type.
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 that directly state the tool's function and return content with no redundant words or filler. Each sentence earns its place, and the information is front-loaded with the primary action.
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 read tool with no output schema and no annotations, the description is somewhat minimal. It mentions the return type ('combined fToken details and user position data') but does not elaborate on the status of the optional 'rpc_url' parameter or any constraints on the chain parameter. The tool is simple, so the description is adequate but leaves room for more detail on expected outputs or usage prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (two of three parameters have descriptions), but the description adds no extra parameter semantics. It does not explain the undocumented 'rpc_url' parameter, and its mention of 'across all fTokens on a chain' merely restates the existing chain description. The description provides no value beyond the schema's parameter explanations.
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 verb ('Get') and resource ('all of a user's lending positions'), scoping it to 'across all fTokens on a chain'. It explicitly distinguishes from siblings like 'fluid_get_user_lending_position' (singular) and 'fluid_get_all_ftokens' (just fToken list) by adding the combination of fToken details and user position data.
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 for when to use the tool: to retrieve all lending positions for a user across fTokens. It does not explicitly name alternative tools or state when not to use it, but the 'all positions' vs 'single position' differentiation is implied by the wording and sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that the transaction is unsigned and that the operation deposits underlying assets to mint shares, but it omits important details such as whether an approval is required beforehand, the resulting transaction object, or any chain-specific behavior. This is moderate transparency for a transaction-builder tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core action. Every word adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a complex transaction builder with no output schema, so the description needs to explain return behavior, but it does not mention what the built transaction looks like or any prerequisites. The sibling toolset suggests multiple similar builders, and while the description gives the main purpose, it leaves out key contextual details like approval handling and output format. Overall it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters documented), so the baseline is 3. The description adds context around 'shares' and 'underlying assets', but it does not clarify the role of the optional rpc_url parameter, which lacks any schema description. It does not compensate fully for that gap.
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 builds an unsigned transaction to mint fToken shares by depositing underlying assets. The verb 'mint' and resource 'fToken shares' are specific, and it distinguishes itself from sibling tools like fluid_build_lending_deposit by focusing on exact-share minting.
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 when an agent needs to construct a mint transaction for fToken shares, but it does not explicitly mention when to use this over the deposit tool or any alternatives. It lacks explicit 'when-to-use' versus 'when-not-to-use' guidance, which is partially mitigated by the clear action verb.
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?
The description discloses that the tool builds an 'unsigned transaction', which is important behavioral context (it does not send or execute transactions). However, with no annotations provided, the description carries the full burden and does not disclose other behaviors like prerequisites (e.g., whether the owner needs to have approved the fToken shares) or what the returned transaction object contains. It provides minimal but non-misleading information.
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 sentence that is front-loaded with the verb 'Build' and the key object 'unsigned transaction'. It contains no fluff or redundant content, and every word contributes to understanding the tool's core function.
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 description gives a basic understanding of the tool's purpose but omits crucial context given there is no output schema and no annotations. It does not state what the returned unsigned transaction looks like, what parameters are optional (e.g., rpc_url), or any preconditions (like having fToken shares). For a simple builder tool, this is adequate but leaves gaps in behavioral and return-value expectations.
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 83%, with only 'rpc_url' lacking a description, so the schema already explains most parameters. The tool description adds no additional parameter-meaning beyond what is in the schema (e.g., 'amount' in wei is already described). Therefore, the description does not compensate or add value beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Build an unsigned transaction to withdraw native ETH from a Fluid fToken lending pool.' The verb 'Build' and resource 'unsigned transaction' are specific, and the term 'native ETH' distinguishes it from siblings like 'fluid_build_lending_withdraw' which likely handles non-native tokens. This is a clear, purpose-driven statement.
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 native ETH withdrawals, but does not explicitly mention when to use this tool versus alternatives such as 'fluid_build_lending_withdraw' or 'fluid_build_lending_deposit_native'. No exclusions or alternative conditions are provided, so the usage guidance is only implied through the tool name and mention of 'native ETH'.
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 transparency burden. It states the output (vault addresses and types) but does not disclose any potential caveats like pagination, rate limits, or whether the list is complete across all chains. It is adequate for a simple read-only list operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and output. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool without an output schema, the description is mostly sufficient, but the undocumented rpc_url parameter and lack of any behavioral notes make it slightly incomplete. An agent might need to guess what rpc_url is for and whether the tool requires it for certain chains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the 'chain' parameter has a description, but 'rpc_url' is undocumented. The description does not add meaning for either parameter; it only mentions 'on a chain' generically. It fails to clarify the purpose of rpc_url or how it interacts with chain, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Fluid vault addresses on a chain, with a specific verb (list), resource (vault addresses), and scope (on a chain). It also mentions the return includes vault types (T1-T4), which differentiates it from sibling tools like fluid_get_all_ftokens and fluid_get_vault_data.
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 gives clear context: use this tool to get all vault addresses for a given chain. It doesn't explicitly mention when not to use it or name alternatives, but the purpose is well-defined enough that an agent can infer when it is appropriate, especially compared to more specific vault tools.
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 provided, so the description carries the full burden for behavioral disclosure. The description makes it clear this is a read operation ("Get") and lists the output fields, but it does not mention any authorization needs, rate limits, or error behavior. It adds some value beyond the tool name by detailing what data is returned, though not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, followed by a list of data fields to expect. There is no fluff or redundancy.
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 simple read-only nature and absence of an output schema, the description's enumeration of returned fields provides useful expectations. However, it omits guidance on when to choose this over sibling tools and does not explain the optional rpc_url, leaving slight gaps for an agent deciding or invoking the tool.
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 2 of 3 parameters with descriptions (chain and ftoken_address), and the description does not add extra context for those. The rpc_url parameter has no description in the schema and is not clarified in the description, leaving ambiguity about its purpose. Overall, the description contributes little to parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information about a specific fToken and enumerates the fields returned (name, symbol, underlying asset, rates, totals). The word 'specific' distinguishes it from sibling tools like fluid_get_all_ftokens and fluid_get_all_ftokens_details, which operate on all ftokens.
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 usage context is implied: use this tool when you need details for a single fToken. However, it does not explicitly mention when not to use it or point to alternatives like fluid_get_all_ftokens_details, and there is no guidance on prerequisites such as RPC URL usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Get'), which implies no state changes, but it does not disclose any additional behaviors such as return format details, error handling, or whether the count might be expensive. It is neither contradictory nor richly 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 entire description is one concise, front-loaded sentence that conveys the essential purpose without any filler. It is immediately understandable and uses no unnecessary words.
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 with no output schema, the description should clarify the return type (e.g., integer) and any prerequisites or caveats. It states 'total number' which implies a numeric result, but it does not explain whether the count is aggregated across all vaults with zero positions, nor does it address the optional rpc_url. Given the simplicity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'on a chain', which ties to the required 'chain' parameter, but it completely ignores the 'rpc_url' parameter. Schema description coverage is only 50% (chain has a description, rpc_url does not), and the description does not compensate for the missing rpc_url semantics. No parameter guidance is added beyond what the schema provides for chain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('total number of vault positions (NFTs)'), and the scope ('across all vaults on a chain'). This distinguishes it from sibling tools like fluid_get_vault_position (which fetches a single position) and fluid_get_all_vaults (which lists vaults). The inclusion of 'total number' and 'NFTs' adds specificity.
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 phrase 'across all vaults' provides clear context for when to use this tool: when a global count is needed rather than details for a specific vault or user. However, it does not explicitly name alternatives or exclusions (e.g., 'for per-user positions, use fluid_get_user_all_positions'), so it falls short of the top score.
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 discloses the output mapping (T1=10000, etc.), which is useful, but does not mention whether it is read-only, error behavior, or any side effects. For a simple getter, the disclosure is acceptable but not comprehensive.
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 sentence that efficiently states the purpose and includes the type mapping. Every word contributes value, and it is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with three parameters and no output schema, the description provides essential context about the return values (the numeric mapping). It does not explain the response structure or error cases, but it is largely complete for the tool's simplicity.
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 describes chain and vault_address, but rpc_url lacks a description. The tool description doesn't add parameter details; it only explains the return value encoding. Given 67% schema coverage, the description does not compensate for the missing rpc_url context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the type of a specific vault, listing the possible values T1-T4 and their numeric equivalents. This distinguishes it from sibling tools that retrieve other vault data, positions, or build transactions.
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 purpose implies when to use it (when you need the vault type), but there is no explicit guidance on when not to use it or which sibling tools to prefer. For example, unlike get_vault_data, this focuses solely on the type, but this differentiation is not stated.
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 behavioral burden. It discloses that the transaction is unsigned and needs no approval, but it does not mention potential reverts, return format details beyond 'unsigned transaction', or behavior specific to native ETH across supported chains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the key action and the critical qualification ('No approval needed') efficiently.
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 return value ('unsigned transaction') and the main use case. However, with no output schema and no annotations, it could optionally clarify the meaning of 'native ETH' on non-Ethereum chains (e.g., Polygon) and possible failure conditions.
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 80%, so the baseline is 3. The description reinforces that 'amount' is ETH in wei and 'ftoken_address' must be an ETH-based fToken, but adds no new parameter-level detail beyond what the schema already provides.
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 and resource: 'Build an unsigned transaction to deposit native ETH into a Fluid fToken lending pool.' It clearly distinguishes this tool from the sibling 'fluid_build_lending_deposit' by specifying 'native ETH' and 'No approval needed.'
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 phrase 'for ETH-based fTokens' and 'No approval needed' convey when this tool is appropriate: for native ETH deposits that do not require an allowance step. It implies the alternative (a regular deposit requiring approval) without naming it explicitly, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly discloses that it burns fToken shares and returns an unsigned transaction (implying no immediate state change). This is useful context about the tool's side effects and execution path, though it omits additional details like authorization requirements or output format.
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 concise sentences with no filler. It front-loads the core action and adds a key detail (burning shares) in the second sentence. 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 tool's moderate complexity (6 params, no output schema, no annotations), the description explains the purpose and core mechanism well. However, it could improve by clarifying the difference from the sibling 'redeem' tool or noting that the output is an unsigned transaction object. Still, the essential context is present.
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 high (83%), so the schema already documents most parameters. The description adds no extra parameter-level details beyond the general purpose (e.g., that the amount is underlying assets), which is already stated in the schema. The missing field in schema (rpc_url) is self-explanatory, so no compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb+resource: 'Build an unsigned transaction to withdraw underlying assets from a Fluid fToken lending pool.' It also names the key action (burning fToken shares), which distinguishes it from sibling tools like deposit, mint, or native versions.
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 by describing the withdrawal context ('withdraw underlying assets from a Fluid fToken lending pool'), but it does not explicitly state when to choose this over alternatives like fluid_build_lending_redeem or the native withdraw tool. No exclusions or alternative guidance are provided.
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 discloses that the transaction is unsigned (not sent) and is a prerequisite for deposit/supply, but offers no details about return format, gas implications, or the potentially irreversible nature of the approval. Satisfies minimum transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and a clear usage prerequisite. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with 5 parameters, no output schema, and no annotations, the description covers the core action and prerequisite. It lacks details about return value or edge cases, but these are less critical for an unsigned tx builder. Overall sufficient context for an agent to select and invoke the tool.
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 80% (4 of 5 parameters have descriptions), so the baseline is 3. The description adds minimal semantic value beyond the schema, merely restating the spender types (fToken, vault, DEX pool) already implied by the spender parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds an unsigned transaction to approve an ERC20 token for spending by Fluid contracts, specifically mentioning fToken, vault, DEX pool. This distinguishes it from sibling getter and other build tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is required before deposit/supply operations, giving clear context for when to use. Does not list alternative tools or exclusions, but the placement among siblings and the 'required before' phrasing provide sufficient 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'preview' strongly implies a read-only estimation, but the description does not explicitly state whether this is a pure read operation, whether it requires an RPC connection (indicated by the undocumented rpc_url parameter), or what side effects (if any) exist. It adds context about the operation types but lacks depth on 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 two concise sentences, front-loaded with the core action and scoping. Every word adds value, with no redundancy or filler. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preview/get tool, the description provides the essential purpose and usage context. Given the moderate complexity of 5 parameters and no output schema, it is reasonably complete; however, it lacks guidance on parameter selection (assets vs shares) and the output shape, which would be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 80% of parameters with meaningful descriptions, so the baseline is 3. The tool description itself adds no parameter-specific detail, particularly failing to explain the relationship between assets/shares and the operation types (e.g., assets for deposit/mint, shares for withdraw/redeem). The undocumented rpc_url parameter is not compensated for either.
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 ('get') and clearly identifies the resource ('conversion previews') for deposit/mint/withdraw/redeem operations on an fToken. It distinctly differentiates this from sibling tools like fluid_get_ftoken_details or fluid_build_lending_deposit by focusing on previews rather than details or transaction building.
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 phrase 'Useful for estimating output before transacting' provides clear context for when to use this tool—before executing a transaction—which implicitly contrasts with the fluid_build_* tools that are for actually constructing transactions. However, it does not explicitly state exclusions or alternative tools, so it falls 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 must disclose behavioral traits itself. 'Get' implies a read operation and the listed return data gives insight into output, but it does not explicitly state that it is read-only, mention any prerequisite RPC usage, or describe error behavior. The missing rpc_url semantics are a transparency 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, well-structured sentence that front-loads the core action and resource, followed by a detailed list of returned data. Every element is informative, with no fluff or repetition.
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 provides a thorough list of return fields, which is essential given the lack of an output schema. However, the unexplained rpc_url parameter and lack of error handling or optionality details mean it is not fully complete for all usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes chain and vault_address, and the description reinforces the notion of a 'specific' vault, but adds no new parameter meaning. rpc_url has no description in either the schema or the description, leaving a gap for that optional parameter.
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 retrieves comprehensive data for a specific Fluid vault, enumerating supply/borrow tokens, rates, collateral factor, LTV limits, and availability. This specific resource and verb distinguish it from sibling tools that handle all vaults or user positions.
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 phrase 'for a specific Fluid vault' establishes a clear context for single-vault queries, implying this is for individual vault lookups rather than batch operations. However, it does not explicitly name alternative tools like fluid_get_all_vaults or state exclusions, so it falls short of full when/not guidance.
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?
Without annotations, the description carries the burden of behavioral disclosure. It explicitly states the tool builds an unsigned transaction that must be signed and sent by the agent's wallet, setting expectations about its non-sending nature. It also discloses the underlying ERC4626 deposit() method. This covers key behavioral traits, though it does not mention prerequisites like token approvals or failure modes, which are secondary for a transaction builder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, return behavior, and underlying method. It is front-loaded with the core action and contains no redundant or filler content. The structure is clean and appropriately sized for a transaction builder tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description covers the essential context: it builds an unsigned transaction, returns data for signing, and uses a specific method. It doesn't describe the return format in detail, but that is often unnecessary for a builder tool. The schema covers most parameters, making the description sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 4 out of 5 parameters (80% coverage), so the baseline is 3. The description adds no additional parameter-specific meaning; it doesn't explain chain, amount, receiver, or ftoken_address beyond what the schema already states. The undocumented rpc_url parameter is not addressed in the description, but the high schema coverage mitigates the need.
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: building an unsigned transaction to deposit assets into a Fluid fToken lending pool. It uses a specific verb and resource (build + deposit) and differentiates itself from siblings by explicitly naming the ERC4626 deposit() method, distinguishing it from mint, redeem, and native deposit variants.
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 for when to use the tool (when depositing assets into an fToken lending pool) and specifies that it returns unsigned transaction data. It does not explicitly mention alternatives or exclusions, but the method name and context implicitly guide the agent. Sibling tools' names (e.g., deposit_native) further clarify distinctions, so no explicit 'when not to use' is necessary.
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 of behavioral disclosure. It explicitly states that the tool 'build[s] an unsigned transaction' (indicating no execution) and that the underlying function is 'payable', both useful behavioral details. It does not mention return format or side effects, but for a transaction-builder, these disclosures are significant.
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, front-loaded with the core purpose, and includes only essential additional context (payable). Every word serves a purpose; there is 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 adequately covers the tool's purpose and key behavioral trait for its complexity. While there is no output schema, the description implicitly states the output is an unsigned transaction. The schema handles parameter details, and the description gives enough context to use the tool correctly for T1 vault interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for 6 of 7 parameters (86% coverage), so the description does not need to elaborate on parameter semantics. The description adds no additional parameter-level meaning beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Build') and resource ('unsigned transaction to interact with a Vault T1'). It further distinguishes from sibling tools by specifying 'single-asset collateral, single-asset debt', setting it apart from T2/T3/T4 vault operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when interacting with a Vault T1. It implies this is the appropriate tool for T1 vaults via the explicit 'T1' designation and the collateral/debt definition. However, it does not explicitly state exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the transaction is unsigned (no execution) and that shares are burned, which are key behavioral traits. It does not mention prerequisites like RPC URL usage or return format, but the disclosed traits are valuable.
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, front-loaded with the core action, and the second sentence adds a valuable user hint about share semantics. It contains zero filler and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction builder with no output schema and no annotations, this description covers the essential context: what it builds (unsigned transaction), what it redeems (fToken shares), and the key input nuance (shares to burn). The tool's purpose and behavior are adequately conveyed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 83% of parameters with descriptions. The description adds the crucial semantic that the 'shares' parameter is the input to burn rather than the output asset amount, clarifying input/output relationships beyond the schema. This additional nuance justifies a score above baseline 3.
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 builds an unsigned transaction to redeem fToken shares for underlying assets, using specific verbs and resources. It also distinguishes from sibling tools by emphasizing the redeem action and the share-burning mechanic, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is used when redeeming fToken shares for underlying assets, which is a distinct operation from minting or depositing. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusion guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/ahmadmardeni1/fluid-mcp-server'

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