Server Quality Checklist

Tool Scores

• market_historyB
  3.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the full behavioral burden. It does add the valuable operational context that CLUBY_INDEXER_URL is required, which is not visible in the schema. However, it leaves out output format, error behavior, and whether the operation is purely read-only.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The core data fields and scope are front-loaded, and the environment prerequisite is stated concisely at the end. Every sentence 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?

  For a two-parameter tool, the description names the returned concepts and the external requirement, which provides a reasonable baseline. However, with no output schema, no annotations, and sinceUnix left undocumented, an agent cannot fully anticipate the return shape or time-range semantics.

  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 0%, so the description should compensate. It gives some meaning to market by saying 'for one market,' but sinceUnix is never explained, including its units or whether it is an epoch timestamp. The description only partially compensates for the missing parameter documentation.

  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 identifies the resource as historical supply, borrow, utilization, and price data for a single market. It distinguishes itself from list_markets and get_market by emphasizing 'over time,' though it lacks an explicit verb like 'fetches' or 'returns.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is implied: an agent should use this tool when it needs time-series metrics for one market. However, it does not explicitly name alternatives such as get_market or list_markets, nor does it explain when not to use this tool. The CLUBY_INDEXER_URL requirement is operational, not a usage selector.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_marketB
  3.4/5.0
  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 promises 'in detail' without explaining what fields are returned, whether it is a current snapshot, or what happens for invalid or missing keys.

  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?

  One compact sentence states the scope and provides illustrative examples with no filler. The most important information is front-loaded.

  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?

  Adequate for a simple single-parameter read tool: the schema covers the key parameter and examples clarify the format. However, without an output schema or explicit guidance on what 'detail' includes, an agent cannot fully predict the return shape or know when to prefer this over market_history.

  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 documents the 'key' parameter with 100% coverage. The description adds value by giving realistic key examples, including short-instrument formats like NVDA-SHORT, which clarifies the expected key shape beyond the generic schema text.

  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 identifies a single-market lookup by key, with concrete examples (NVDA, SPY, ETH, NVDA-SHORT). It distinguishes itself from list_markets by emphasizing 'one market' and from market_history by focusing on 'detail', though it does not explicitly say 'get' or name an 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 usage context is implied: use this when you need detailed information for one known market key. However, it does not explicitly state when not to use it or mention alternatives like list_markets for overviews or market_history for time-series data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_positionB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full responsibility for behavioral transparency. It does disclose the content of the returned position, which is useful given there is no output schema. However, it does not explicitly state that this is a read-only operation, describe potential failure modes, or clarify units and formatting of the returned values.

  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, dense sentence with no filler. The primary object ('a borrower's position in one market') is front-loaded, followed by a concise list of the returned fields. Every word contributes useful information.

  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 two-parameter read with fully documented parameters, the description adequately states the return content and the per-market scope. The absence of an output schema and minor ambiguity around units or liquidation-price denomination leave small gaps, but the tool is still selectable and invocable based on this description.

  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?

  Both parameters are fully described in the schema: 'Market key' and 'Borrower address', with address format further constrained by a regex. The description adds no parameter-specific details beyond the overall borrower-position context. Baseline 3 is appropriate because schema coverage is 100%.

  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 identifies the resource as a borrower's position in one market and enumerates the returned data: collateral, debt, health factor, and liquidation price. It lacks an explicit verb like 'retrieves,' but the tool name supplies that action. The per-borrower, per-market scope helps distinguish it from list_vaults and get_market.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus siblings such as list_vaults, get_market, or quote_borrow. The phrase 'in one market' hints at scope but does not explicitly direct the agent to alternatives or exclusions. No prerequisites or typical use cases are mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• protocol_factsB
  3.4/5.0
  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 lists informational content but never states whether the call is read-only, has side effects, or how the data is returned. The word 'facts' weakly implies a safe reference 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact phrase with no filler, and every listed topic adds meaningful information. It is appropriately short for a zero-parameter tool, though the fragment style lacks a leading verb and is more of a topic list than a structured statement of behavior.

  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 tool with no parameters and no output schema, the description provides enough information to invoke it correctly and anticipate the general content. Gaps include a missing explicit read-only statement and no indication of output format, but the low complexity of a zero-parameter reference tool lowers the completeness burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema has no properties, so there is nothing for the description to explain about inputs. The topic list is still useful for interpreting what the unparameterized call will return.

  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 enumerates concrete protocol topics — addresses, fee split, LLTV tiers, and flash-loan instructions — so an agent can tell this is the static protocol-reference tool rather than a market or transaction tool. It lacks a direct verb like 'provides' or 'returns,' but the content list makes the resource and scope clear.

  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 this tool: whenever a user needs protocol-level facts such as addresses, fee splits, or LLTV tiers. However, it never explicitly states when to use it versus alternatives, nor does it mention sibling tools like list_markets or get_market, so some inference is required.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• quote_borrowB
  3.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly signals a non-executing quote operation and names the expected outputs, which is meaningful transparency for a read-only simulation tool. It could still mention that it does not modify state more explicitly, but the pre-signing framing largely covers this.

  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, tightly worded sentence that front-loads the purpose and lists the key outputs without any waste. It is immediately scannable and to the point.

  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 no output schema, no annotations, and a required under-documented market parameter, the description is too sparse. It names three output concepts but does not describe return shape, parameter constraints beyond schema, or how to handle cap-related errors, leaving an agent without enough information to confidently invoke and interpret the result.

  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 covers borrowAmount and collateralAmount semantics, but market has no description. The tool description adds no parameter-level meaning and does not clarify what market refers to, leaving a required parameter under-specified with only 67% schema coverage.

  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 indicates that this tool produces a pre-signing quote for a borrow action, listing health factor, liquidation price, and cap compliance. It distinguishes the operation from the sibling quote_multiply by focusing on borrowing rather than multiplying, though it does not explicitly name the 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 phrase 'before it is signed' implies this tool is for simulating a borrow without executing it, which gives useful context. However, it does not explicitly state when to prefer quote_borrow over quote_multiply or other siblings, nor does it mention exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_vaultsA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden of behavioral disclosure. It only describes the output contents and never states that the operation is read-only, whether any side effects exist, or whether authentication is needed. The agent must infer safety from the tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, short phrase with no filler words; it front-loads the domain and then lists the key output dimensions. 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?

  For a zero-parameter list tool with no output schema, the description covers the essential output content: vaults, assets, fee, and timelock. It could be more complete by explicitly saying 'lists all vaults' and noting it is read-only, but no invocation-critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and an empty schema, so the baseline is 4 and no parameter documentation is needed. The description's itemization of vault details is useful output context rather than parameter explanation, and there is no schema gap to compensate for.

  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 identifies the resource (vaults) and the returned data (holdings, fee, timelock), and 'Earn side' hints at a distinct domain from the market and borrow siblings. It lacks an explicit verb like 'lists' or 'returns' and does not name sibling tools, so it does not fully meet the 5-level bar.

  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 Earn side' provides a contextual hint that this tool is for Earn vault information, which implicitly differentiates it from list_markets and other lending/borrowing tools. However, there is no explicit guidance about when to choose this tool over alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• quote_multiplyA
  3.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It communicates that this is a projected quote for an unopened position and lists the returned metrics, strongly implying a read-only, non-mutating operation. It does not mention auth or error behavior, but the core behavioral context 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single compact sentence with a colon-separated list of outputs; it is front-loaded with the key context and contains no filler. Starting with a verb like 'Returns' would improve clarity, but as written it is concise and scannable.

  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 listed output fields partially compensate for the absence of an output schema, and the required parameters are all present in the input schema. However, the description does not clarify how quote_multiply differs from quote_borrow or what valid market values are, leaving the context minimally sufficient rather than 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 adds no input parameter meaning beyond the schema. Market remains an opaque string, and the description does not explain how equityUsd and leverage relate to the resulting exposure, debt, or liquidation price. Since schema coverage is only 67%, the description should have compensated, but it does not.

  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 names the resource ('a leveraged position before it is opened') and enumerates the computed fields (exposure, debt, LTV, health factor, liquidation price), so an agent can infer this is a pre-trade quote tool. It lacks an explicit verb like 'quotes' or 'calculates' and does not explicitly contrast with quote_borrow, but the resource and output list are specific enough.

  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 'before it is opened' provides a clear context for when to use this tool: when assessing a leveraged position before actually opening it. It does not name alternatives or state when not to use it, which prevents a 5, but the timing and purpose are reasonably explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• recent_liquidationsA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the behavioral burden and does disclose two useful behaviors: the tool requires CLUBY_INDEXER_URL and returns an empty list when it is missing. It also implies a read-only observation via 'has seen,' which is appropriate given the nature of the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences: the first states the resource, the second covers the prerequisite and failure mode. There is no filler or redundant restatement of the tool name.

  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 zero-parameter list tool, the description tells the agent what it returns and how it behaves when the indexer URL is absent. It does not describe fields, ordering, or 'recent' semantics, but the low complexity and lack of an output schema make this a minor gap rather than a critical one.

  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?

  There are zero parameters and schema coverage is complete, so the baseline of 4 applies. The only external dependency, CLUBY_INDEXER_URL, is mentioned separately and is not an input-schema parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies the resource ('liquidations') and the source ('the indexer'), which clearly distinguishes it from sibling tools about markets, vaults, positions, and quotes. It lacks an explicit verb such as 'list' or 'returns', but the meaning is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to choose this tool over alternatives. It only states an environmental prerequisite, CLUBY_INDEXER_URL, but does not mention siblings like market_history or get_market that might be considered for similar lookups.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_marketsA
  3.8/5.0
  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 adds useful context such as 'live price' and 'whether it exists on chain yet', signaling that markets may be unlaunched and data is current. However, it does not mention ordering, pagination, data source, or explicit read-only status, though 'list' implies a read operation.

  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 immediately states scope ('Every Cluby market') and then efficiently lists the returned data fields. There is no filler or duplicated schema 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?

  For a simple list tool with one optional parameter and no output schema, the description gives enough field-level detail for an agent to know what the response will contain. It falls slightly short of 5 by not addressing side-filtering behavior, though the schema covers the parameter itself.

  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 schema already documents the side parameter with its enum and default. The description does not mention side or how it filters results, so it adds no parameter-level meaning beyond what the schema provides. 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 names a specific verb and resource ('Every Cluby market') and enumerates the contained data: collateral, loan asset, liquidation LTV, live price, rates, and on-chain status. This clearly distinguishes it from sibling get_market, which is for a single market.

  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 phrase 'Every Cluby market' implies this is the broad listing endpoint, and the sibling get_market hints at a more targeted alternative, but the description never explicitly says when to choose this over get_market or how the side parameter affects usage. Usage is implied rather than stated.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.