DorkFiMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools are distinct, but get_position, get_user, get_global_user, and get_health_factor all return overlapping user position data with only subtle differences, which can confuse an agent. Market-level getters and transaction builders are clearer, but the user-data cluster creates real selection ambiguity.
Naming Consistency5/5
The naming is highly consistent: read operations use the get_ prefix (except is_paused) and transaction builders use the _txn suffix. This predictable pattern makes the tool surface easy to navigate.
Tool Count3/5
At 21 tools, this server sits in the heavy 16-25 range, which feels like more than a typical MCP surface. The count is defensible given the depth of lending operations, but some user getter tools could be consolidated to reduce redundancy.
Completeness5/5
The tool set covers the full lending lifecycle: market data, user positions, deposits, borrows, repayments, withdrawals, liquidation, and admin/keeper actions like syncing and reserve withdrawals. There are no obvious dead ends for the stated purpose.
Average 4/5 across 21 of 21 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns unsigned base64-encoded transactions for signing, which is a key behavioral trait. However, with no annotations, it does not mention whether the operation is safe, whether position must exist, or any side effects. It provides basic transparency 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 contains no extraneous words. 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?
The tool is moderate complexity with four parameters fully documented in the schema, and the description explains the output format. However, the lack of usage guidelines and sibling differentiation leaves room for incompleteness in a context with many similar tools.
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 all four parameters with descriptions, so the baseline is 3. The description adds no additional meaning beyond 'repay borrowed tokens', which is already expressed in the schema. No param details are enriched.
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 unsigned transactions to repay borrowed tokens to a DorkFi lending market, which is specific and actionable. However, it does not distinguish between this and sibling tools like repay_on_behalf_txn or repay_all_txn, which also repay borrowed tokens.
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 conditions for use, prerequisites, or exclusions. For a tool with many sibling repayment-related tools, this is a notable gap.
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. It discloses the mechanism (calling pool contract's get_user ABI method via algod simulate), which implies a read-only simulation. However, it doesn't disclose what happens if the market is paused, what the return data contains, or any side effects (likely none). The phrase 'via algod simulate' gives some transparency about the simulation nature, but more context on output or errors would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise and includes the essential action and method. It is not overly verbose, but could be slightly improved by adding a brief note on usage without bloating.
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 has three simple parameters with full schema coverage, so the description doesn't need to explain return values (no output schema exists, but the description could mention what 'position data' includes). Contextually, it's complete enough for a straightforward getter, but the lack of output schema and minimal description of the return payload leaves some ambiguity about what exactly is returned and how to interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for all three parameters. The description itself doesn't add much beyond the schema, but that's acceptable because the schema already documents each parameter. The description does clarify that the tool targets a DorkFi lending market, which gives context to the symbol parameter, but this is minimal added value.
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 retrieves a user's on-chain position data for a DorkFi lending market, specifying the contract call and method (get_user) and the simulation via algod. It distinguishes from siblings like get_markets and get_market by focusing on a user's position, though it doesn't explicitly mention 'get_position' which might be a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need a specific user's position in a specific market, but it doesn't provide explicit when-to-use versus alternatives like get_position or get_health_factor. Sibling names suggest overlapping functionality, but no guidance is given on choosing among them.
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 adds the meaningful detail that health factor <=1.0 means liquidatable, but leaves ambiguity about what 'per pool' means (e.g., returns per-pool list?) and does not disclose return format, error behavior, or whether it is purely read-only (though 'get_' implies so). This is a notable 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?
Two sentences, front-loaded with the verb and resource, no wasted words. The second sentence adds essential interpretation without elaboration. Excellent 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?
No output schema exists, so the description should clarify the return shape. It states the tool checks health factor and risk level, but does not specify whether the output is a single value or per-pool breakdown, nor the type/format of 'risk level'. Given the simple 2-param signature, the description is adequate but incomplete for a no-output-schema 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 100%: both 'chain' and 'address' have clear descriptions and chain has an enum. The description adds no parameter-level details, but the schema already fully documents them, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a user's health factor and risk level per pool, using a specific verb ('check') and resource. It also provides the key threshold interpretation (<=1.0 means liquidatable), which distinguishes it from nearby getter tools like get_position or get_user.
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 health factor or liquidation risk is relevant, and it explains the threshold context. However, it lacks explicit guidance on when to choose this tool over siblings (e.g., get_liquidation_candidates, get_position) and does not mention any exclusions or prerequisites.
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. It mentions using 'algod simulate' which implies a safe, read-only operation, and specifies the returned data (collateral and borrow values). However, it does not disclose error behavior, rate limits, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and method. There is no redundant information 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?
For a simple getter with no output schema, the description adequately explains what the tool returns and the underlying mechanism (ABI method via algod simulate). It covers the essential context needed for correct invocation, though it could mention return format or units.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully described in the schema. The description adds context by explaining the address is for a user and the values are aggregated across pools, but does not provide new parameter-specific details 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 the tool retrieves aggregate collateral and borrow values for a user across all pools, using a specific verb and resource. It distinguishes itself from siblings like get_user by emphasizing the 'aggregate' and 'across all pools' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_user or get_position. The phrase 'across all pools' implies a contrast but does not explicitly state exclusions or alternative recommendations.
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. It notes the call uses 'algod simulate', suggesting a read-only simulation, but does not explicitly state there are no side effects, potential failure modes, or expected latency. This is adequate for a simple getter but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose. It includes technical implementation details (call via algod simulate) that add context but could be considered slightly verbose for an agent that mainly needs to know what it does.
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?
With no output schema, the description's 'full on-chain data' is vague and does not enumerate what fields or structure to expect. It also omits error conditions and network specifics. For a simple two-parameter getter, this is minimally sufficient 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 provides 100% coverage with both 'chain' and 'symbol' having descriptions. The description adds no additional semantic detail beyond what the schema already states, so it meets the baseline but does not elevate it.
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 a single DorkFi lending market's full on-chain data via a specific ABI method. It explicitly uses 'single', distinguishing it from the sibling 'get_markets' tool, and specifies the resource (DorkFi lending market) and action (get).
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 a single market, contrasting with get_markets for plural. However, it does not explicitly state when not to use it or mention alternatives beyond the implicit 'single' vs 'plural' distinction.
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 data fields returned and the optional symbol filter, but does not mention side effects, read-only behavior, pagination, or error conditions. The 'List' verb implies a read operation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the primary action 'List DorkFi lending markets' and immediately provides the key output details. No redundant or irrelevant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool with only two parameters and no output schema, the description adequately covers purpose and output. It could mention that 'chain' is required or note the absence of pagination, but the simplicity makes this minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema, only restating the optional symbol filter. It does not explain the 'chain' requirement or elaborating on parameter formats.
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 DorkFi lending markets with live data including rates, deposits, borrows, and prices. The plural 'markets' distinguishes it from the sibling tool 'get_market', and the optional filter by symbol adds scope.
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 this tool is for listing multiple markets, but it does not explicitly contrast with alternatives like 'get_market' for a single market. It provides no when-to-use or when-not-to-use guidance, leaving differentiation to inference from sibling 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 transparency burden. It discloses that the tool uses algod simulate (suggesting a read-only simulation) and returns pause status per pool. However, it does not describe error behavior or what 'paused' means. This is adequate for a simple read 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 a single, front-loaded sentence that states the purpose, method, and return value. It is concise with no filler 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?
For a simple tool with one parameter and no output schema, the description covers what it does, how it does it, and what it returns. It lacks explicit usage guidance (covered in a separate dimension) but is otherwise complete for this 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?
The schema fully covers the single parameter (chain) with an enum and description, so the description adds no additional parameter meaning. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('DorkFi lending pool contracts are paused'). It also mentions the method ('calling the is_paused ABI method via algod simulate'), distinguishing it from sibling tools as the only pause-status checker.
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 (to check whether pools are paused) but does not explicitly state when to use this tool versus alternatives or provide exclusions. No alternatives are mentioned, so guidance is only implied.
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 transparency burden. It conveys a read-only behavior through 'Find' and 'Returns', and adds a useful behavioral trait by specifying 'pre-indexed health data', implying a precomputed index rather than real-time queries. This goes beyond the schema and name, providing useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the primary action and then summarizes the return criterion. Every word earns its place, making it appropriately sized and easy to parse.
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?
With no output schema and no annotations, the description should explain what is returned. It says 'Returns those below the health factor threshold' but doesn't specify whether 'those' are account addresses, objects, or how the optional parameters interact. The basic intent is covered, but return format and edge cases are missing, making it minimally 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 description coverage is 100%, so the baseline is 3. The description mentions 'health factor threshold', which aligns with the 'threshold' parameter, but doesn't add further insight beyond the schema for 'chain', 'limit', or 'addresses'. No additional value to raise the score.
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 ('Find') and resource ('accounts eligible for liquidation'), and distinguishes itself from sibling tools like get_health_factor (checks a specific user) and liquidate_txn (executes liquidation). It clearly states the condition (below health factor threshold) and the data source (pre-indexed health data), making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you want to find liquidation candidates) but does not explicitly mention alternatives or exclusions. Sibling tools like get_health_factor or liquidate_txn could be contrasted, but the description doesn't guide the agent on choosing between them. Usage context is present but underdeveloped.
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 for behavioral disclosure. It explains the return format ('Returns TVL per market and aggregate totals'), but it does not explicitly state read-only behavior, potential side effects, data freshness, or rate limits. The 'Get' verb implies a non-mutating operation, but the description does not make this explicit, leaving room for ambiguity.
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 front-load the purpose and then specify the output. Every word earns its place, with no redundant information or filler. It is concise and clearly structured.
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 simple tool with one optional parameter and no output schema, the description is complete. It states what the tool does, the scope (all DorkFi lending pools), and what it returns (per-market and aggregate TVL). This provides sufficient context 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 schema description coverage is 100%, with a single optional 'chain' parameter that has an enum and a clear description ('Filter by chain, or omit for all chains'). The tool description does not add any additional context about this parameter, but the schema already fully documents it, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get total value locked (TVL) across DorkFi lending pools' with a specific verb and resource. It also distinguishes itself from sibling tools like get_markets and get_market by focusing on TVL specifically, and it notes the return types (per market and aggregate totals).
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 TVL metrics. However, there is no explicit guidance on when to prefer this over alternatives, nor any exclusions or related tool mentions. The description provides clear context but no direct comparison to sibling 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 burden. It explicitly discloses that the tool returns base64-encoded unsigned transactions for signing, and that sufficient collateral is required. This is meaningful behavioral context beyond the basic purpose, though it does not cover failure modes or validation 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 main purpose, and every sentence adds necessary information. No redundant or filler content exists.
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 structure with four fully described parameters and no output schema, the description covers the primary purpose, the output format, and the key precondition. It is complete enough for an agent to invoke correctly, though it omits error-handling 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 provides descriptions for all four parameters, giving 100% coverage. The description adds no parameter-specific meaning beyond what the schema already offers, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds unsigned transactions to borrow tokens from a DorkFi lending market. This distinguishes it from sibling transaction builders like deposit_txn or repay_txn by specifying the borrow action and the protocol.
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 borrowing tokens and notes the collateral requirement, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools cover other operations, yet no direct comparison is offered.
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 via 'Get' and describes the return, but it does not explicitly state that it is read-only or mention any side-effect-free guarantee. This is adequate but not fully transparent.
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 contains no redundant information. Every word 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 tool is relatively simple, and the description covers the main output (health factors and portfolio summary). However, there is no output schema or mention of error conditions, which could be useful if the address is invalid or the chain is unsupported. Still, it is sufficiently complete for most use cases.
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 has 100% description coverage, so the schema already explains chain, address, and symbol. The description adds no extra parameter details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a user's DorkFi lending positions across all markets, with specific verb and resource. It distinguishes itself from siblings like get_health_factor by explicitly mentioning per-pool health factors and portfolio summary.
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: it is for fetching a user's positions across all markets. It does not explicitly mention when to use alternatives like get_health_factor or get_market, but the scope is clear enough that an agent can infer when 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses sorting behavior and output fields but does not mention potential performance issues, pagination, or that it requires the chain parameter (though schema covers that). It's a read-only operation, but no safety details are 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 two concise sentences that front-load the purpose and sorting order. Every word adds value, with 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?
The tool is simple with one documented parameter and no output schema. The description provides the core output fields and sorting, which is sufficient for an agent to invoke it correctly. It lacks any caveats about data volume or chain-scoping, but those are minor given the 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 description does not mention the chain parameter, but the schema fully documents it (100% coverage), so the baseline of 3 applies. The description adds no additional parameter meaning 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 uses the specific verb 'List' and identifies the resource 'DorkFi users' with the exact output fields (health factors, collateral, borrows, risk levels) and sorting order. This clearly distinguishes it from sibling tools like get_user (singular) or get_health_factor.
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 this tool: to get an overview of all users with risk metrics, sorted by health factor. However, it does not explicitly mention alternatives or exclusions, such as preferring get_user for a single user, so it lacks explicit usage guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it builds unsigned transactions, calls fetch_price_feed(uint64) on the pool contract, and returns base64-encoded transactions for signing. This clarifies that the tool does not execute transactions itself, which is essential 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 only two sentences, front-loads the purpose, and includes the key behavioral details without any fluff. 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 no output schema, the description adequately explains the return value (base64-encoded transactions) and the underlying operation. It omits any mention of error handling or how to use the signed transactions, but is sufficient for a simple transaction builder with 100% schema coverage.
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 already has a description in the schema. The tool description adds no additional parameter-level semantics beyond the contract call context, keeping it at the 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 it builds unsigned transactions to fetch the latest oracle price for a DorkFi lending market, specifies the contract function called, and distinguishes itself from sibling read-only getters and other transaction builders.
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 is for building transactions rather than directly querying price, and notes the output is for signing. However, it does not explicitly mention alternatives like get_market or when not to use this tool, so it lacks full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose key behaviors itself. It does so by stating that transactions are unsigned and that the output is base64-encoded for signing, which is critical for an agent to understand the tool's non-executing nature. It also clarifies the sender/borrower roles, though it does not cover every possible edge case.
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 exceptionally concise, consisting of three sentences that front-load the main purpose and immediately follow with role clarification and output format. There is no redundant or unnecessary wording.
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 sufficient context for an agent to understand the tool's purpose, how it works, and what it returns. It lacks an output schema but compensates by explicitly stating the base64-encoded output for signing. It could mention prerequisites or error conditions, but those are not essential for basic understanding.
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 provides 100% parameter coverage, so the description adds little semantic value. It only reinforces the sender/borrower relationship already defined in the schema, and does not provide additional details like amount formatting or edge cases. A score of 3 is 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 that the tool builds unsigned transactions to repay another user's borrowed tokens to a DorkFi lending market. The verb 'repay' and resource 'another user's borrowed tokens' are specific, and the description distinguishes from sibling repay tools by emphasizing 'on behalf of the borrower'.
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 that the sender pays on behalf of the borrower, making it obvious when to use this tool. However, it does not explicitly name alternatives like repay_txn or state when not to use, 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.
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 transparently states that the tool builds unsigned transactions and returns base64-encoded transactions for signing, and it discloses the underlying contract call (sync_market(uint64)). It does not detail permissions or potential errors, but the safety of building an unsigned transaction is clear.
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 with no redundancy: the first sentence defines the purpose, the second sentence gives the contract call and return format. It is front-loaded and 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?
For a transaction-building tool with no output schema, the description sufficiently covers the purpose, implementation, and return format. It lacks an explicit usage alternative comparison, but the core information needed to invoke the tool correctly is present. The sender and chain parameters are in the schema, and the return type is described.
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 all three parameters with descriptions (100% coverage), and the description does not add additional semantic detail beyond what the schema provides. The mention of 'interest accrual, index updates' in the description gives context to the symbol parameter, but the schema's description already covers the idea of the market. Thus, the description adds minimal 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 clearly states the tool's purpose with a specific verb ('Build') and resource ('unsigned transactions to sync a DorkFi lending market's state'), and specifies the on-chain call (sync_market(uint64)) and return format. This distinguishes it from the sibling sync_user_market_for_price_change_txn by focusing on market-level state rather than user-level.
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 on the tool's function—syncing market state (interest accrual, index updates)—and mentions the contract call. However, it does not explicitly state when to use this versus alternatives, such as sync_user_market_for_price_change_txn, or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the transactions are unsigned and returned base64-encoded for signing, which is a key safety trait. It also explains the effect (updates collateral and borrow values). It doesn't cover prerequisites or failure modes, but the core behavior is transparent.
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 core purpose and then the output format. Every word earns its place, 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 explains what the tool does and its output format, which is adequate for a transaction builder with a rich schema. It could mention that multiple transactions may be returned or prerequisites like needing a recent price feed, but overall it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the description doesn't need to repeat parameter details. The description implicitly references 'user' and 'symbol' but adds no extra semantic meaning 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 clearly identifies the action (builds unsigned transactions), the target (user's market position), and the trigger context (after oracle price change). It distinguishes from the sibling 'sync_market_txn' by focusing on the user's position rather than the market itself.
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 a clear trigger context ('after an oracle price change') and states the purpose, which is sufficient for most use cases. However, it does not explicitly mention when not to use it or name alternatives like 'sync_market_txn' or 'liquidate_txn', 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool 'Build unsigned transactions' (not directly executing) and that it 'Returns base64-encoded transactions for signing', indicating the output format and non-mutating nature. The 'Owner/admin only' constraint is also disclosed. This provides meaningful behavioral context beyond a simple action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action ('Build unsigned transactions to withdraw accumulated reserves'), followed by essential constraints. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the key aspects: the action, the target resource, access restrictions, output format, and non-execution behavior. The absence of an output schema is compensated by the explicit mention of base64-encoded transactions. Minor gaps like potential failure conditions or prerequisites are not critical for this transaction-builder context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters with descriptions. The description does not add extra parameter semantics, which is acceptable per the baseline. While it omits details like the relationship between 'amount' and 'accumulated reserves', the schema already explains the parameters 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 states a specific verb and resource: 'Build unsigned transactions to withdraw accumulated reserves from a DorkFi lending market.' It clearly distinguishes from sibling tools like 'withdraw_txn' by using 'reserves' and 'Owner/admin only', making the scope 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 with 'Owner/admin only' and 'accumulated reserves', which implies this tool is for administrative reserve withdrawals rather than regular user withdrawals. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of full 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 explaining side effects. It explicitly states that transactions are unsigned and base64-encoded for signing, making clear that no on-chain mutation occurs. This is a key behavioral disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with no wasted words. It front-loads the primary action and includes the return format without excessive detail.
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 4 well-documented parameters and no output schema, the description adequately covers purpose and return format. It lacks edge case information (e.g., insufficient balance) but is sufficient for the tool's simplicity. Given the sibling context, it's clear when to use it.
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 covers all four parameters with descriptions, so the baseline is 3. The description adds minimal parameter detail, though it clarifies that 'symbol' refers to supplied tokens, which is a slight enhancement over the schema's generic wording.
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 and resource: builds unsigned transactions to withdraw supplied tokens from a DorkFi lending market. It also specifies the output as base64-encoded transactions, distinguishing it from other transaction builders like deposit_txn or borrow_txn.
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 the appropriate use case: when a user wants to withdraw tokens previously supplied to a DorkFi market. It does not explicitly name alternatives, but the sibling tools and the verb 'withdraw' make the context clear. Missing exclusions like requiring an existing position prevent a 5.
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 full behavioral disclosure. It states that transactions are unsigned and returned as base64-encoded for signing via UluWalletMCP, clarifying that this tool does not execute on-chain actions. This is valuable context beyond just the schema, though it doesn't mention permissions or prerequisite balances.
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, resource, and output format with no wasted words. Every phrase is informative.
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?
With no output schema, the description explains the return value (base64-encoded transactions) and the external signing flow. Given the low complexity and rich input schema, this is fully sufficient for an agent to correctly 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 100%, with each parameter already having a clear description. The tool description adds no additional meaning beyond restating the purpose, so it does not elevate above the schema 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 states a specific action ('deposit (supply) tokens') and resource ('DorkFi lending market'), distinguishing it from sibling transaction builders like borrow_txn and withdraw_txn. The verb 'Build unsigned transactions' further clarifies its exact role.
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 clearly implies the use case: when the user wants to deposit or supply tokens, this tool is appropriate. It doesn't explicitly name alternatives or state when not to use it, but the context is strong enough to avoid confusion with withdraw, borrow, or repayment 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?
No annotations are provided, so the description carries the full burden. It transparently discloses that the tool builds unsigned transactions, returns base64-encoded output for signing, and explains the economic mechanism (debt repayment + collateral bonus). This goes beyond the bare minimum, though it doesn't enumerate risks or edge cases.
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 purpose, and every clause contributes. It states what it does, explains the mechanism, and specifies the return format with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers the return format (base64-encoded transactions) and operational context. Combined with the rich 100% schema coverage, the tool is well defined for an agent to select and invoke 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?
Schema coverage is 100% with descriptions for all 6 parameters, so the schema does the heavy lifting. The description reinforces that 'amount' refers to debt, but doesn't add semantic detail beyond what the schema already provides, making the baseline 3 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 uses a specific verb and resource: 'Build unsigned transactions to liquidate an undercollateralized position.' It clearly distinguishes from sibling transaction builders like repay_txn or deposit_txn by focusing on liquidation, so an agent can easily identify when to use it.
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 clearly implies usage for undercollateralized positions, stating the liquidator repays debt and seizes collateral. While it doesn't explicitly list alternatives or when-not-to-use, the liquidation context is distinct enough from normal repayment or other operations to serve as clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses the step-by-step process (queries borrow amount, wraps tokens if needed, calls repay_all), the output format (base64-encoded transactions for signing), and that it does not execute transactions itself. This is thorough 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?
Two concise sentences: the first states purpose, the second outlines process and output. No filler words, front-loaded with the most important information, and every sentence earns its place.
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?
The description fully covers the tool's operation: purpose, internal steps, and return format. Given the simple schema (3 required params) and no output schema, this is complete. It also differentiates from the partial repay sibling by highlighting 'entire borrow balance'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a small behavioral detail (wrapping tokens if needed) but does not expand on parameter formats or constraints beyond what the schema already provides. The schema descriptions for chain, sender, and symbol are sufficient.
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 unsigned transactions to repay a user's entire borrow balance for a DorkFi lending market. The verb 'repay' plus scope 'entire borrow balance' distinguishes it from sibling tools like repay_txn and repay_on_behalf_txn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the goal is to repay the full outstanding balance, emphasizing 'entire borrow balance' and 'calls repay_all'. It does not explicitly compare to alternatives, but the context is clear enough to guide selection without exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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/NautilusOSS/DorkFiMCP'

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