Server Quality Checklist

Tool Scores

• GET_NEAR_SWAP_FULL_QUOTEA
  3.9/5.0
  Behavior3/5

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

  No annotations provided, so description carries full weight. Mentions it returns a unique deposit address and requires recipient/refund addresses. Does not disclose whether the call creates a pending swap or has side effects. The dry run parameter is described in schema but not highlighted in description. Lacks depth on behavioral traits like idempotency or authentication needs.

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

  Conciseness5/5

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

  Four sentences, front-loaded with the main purpose. Uses a clear step label and warns about prerequisite token discovery. Every sentence adds value with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 14 parameters and no output schema, the description explains the core workflow but omits details about the return structure beyond 'unique deposit address'. The agent is left to infer other output fields (e.g., estimated output, fees). Lacks completeness for a complex tool with many optional parameters.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The tool description adds context about requiring recipient and refund addresses, but does not elaborate on individual parameters beyond what the schema already provides. The NOTE about token names indirectly helps with originAsset/destinationAsset but does not add new semantic value.

  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 the tool gets a full quote with deposit address for a NEAR intent swap. The '[STEP 2]' prefix and mention of checking the simple quote distinguish it from sibling tools like GET_NEAR_SWAP_SIMPLE_QUOTE. The verb 'get' and resource 'full quote' are specific and 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?

  States to use this when users are ready to proceed after checking the simple quote. Provides a NOTE directing to GET_NEAR_SWAP_TOKENS for resolving token names. Does not explicitly say when not to use, but the context implies the simple quote is a prerequisite, leaving no ambiguity.

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

• GET_NEAR_SWAP_SIMPLE_QUOTEA
  3.9/5.0
  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 dry-run nature and that no addresses are required, but does not mention any behavioral aspects like rate limits, authentication, or error conditions. It is adequate but not exhaustive.

  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 front-loads the purpose and provides structured steps. However, it is slightly verbose with a step number and notes; could be more concise without losing clarity.

  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 and lack of output schema, the description covers purpose, usage hints, and parameter clarifications. It does not explain the return value, but that is acceptable for a simple quote 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 coverage is 100%, so baseline is 3. The description restates parameter examples (e.g., originAsset format) and defaults (slippage, wait time) but adds little new meaning beyond the schema. The note about token discovery is helpful context but not parameter-specific.

  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 a simple NEAR intent swap quote as a dry run without needing addresses. It differentiates from siblings by specifying 'simple quote' vs full quote and directing token name discovery to GET_NEAR_SWAP_TOKENS.

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

  Usage Guidelines4/5

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

  The description explicitly says to use this when users want to explore swap options without recipient addresses and includes a note to use GET_NEAR_SWAP_TOKENS for simple token names. However, it does not mention when to prefer a full quote or execution over this simple quote.

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

• CHECK_NEAR_SWAP_STATUSA
  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 burden. It discloses that the tool returns swap state and transaction info, implying a read-only, non-destructive polling operation. However, it does not explicitly state idempotency, rate limits, or that it doesn't modify state, which could aid agent decision-making.

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

  Conciseness5/5

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

  The description is a single sentence followed by a brief usage instruction, front-loading the core purpose. Every sentence adds value, and there is no extraneous 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?

  Given no output schema and low complexity (1 param, no enums, no nested objects), the description adequately covers the return data (states and transaction info). It could be more explicit about the format of 'detailed transaction information,' but it is sufficient for a status check 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 coverage is 100%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema provides (e.g., 'depositAddress' is explained in both). The tool description reinforces its purpose but does not compensate for missing parameter details.

  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 tool as checking the execution status of a NEAR intent swap, listing specific states (PENDING_DEPOSIT, PROCESSING, SUCCESS, REFUNDED, FAILED) and framing it as step 5 in a sequence, which distinguishes it from sibling tools like EXECUTE_NEAR_SWAP or GET_NEAR_SWAP_FULL_QUOTE.

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

  Usage Guidelines4/5

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

  The description explicitly states 'Use this to monitor swap progress after initiating the swap, and continue polling until the swap is complete,' providing clear when-to-use context. It does not mention when not to use or alternatives, but the context is sufficient for an agent to decide.

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

• EXECUTE_NEAR_SWAPA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must fully convey behavioral traits. It discloses that the tool notifies the 1Click service and triggers swap execution. However, it lacks details on error handling, idempotency, or what happens if the txHash is invalid. Without annotations, this is an acceptable but incomplete disclosure.

  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: two sentences with no filler. It front-loads the step number and action, and every sentence adds value—purpose, notification mechanism, and usage context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (2 params, no output schema, no annotations), the description is mostly complete. It covers the purpose, when to use it, and the trigger mechanism. However, it does not mention the return value or error conditions, which would enhance completeness for an agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the input schema already documents both parameters (txHash and depositAddress) with clear descriptions. The tool description does not add any additional parameter semantics beyond the schema. Per guidelines, baseline is 3 when coverage is high.

  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: 'Submit a deposit transaction hash to initiate the swap.' It specifies the action (submit), resource (deposit transaction hash), and outcome (trigger swap execution). This distinguishes it from sibling tools like GET_NEAR_SWAP_FULL_QUOTE and CHECK_NEAR_SWAP_STATUS, which are for quotes and status.

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: 'Use this after users have sent their funds to the deposit address from the full quote response.' It implies a step-by-step process (STEP 4) and clearly indicates when to invoke the tool. However, it does not explicitly mention when not to use it or alternatives.

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

• GET_NEAR_SWAP_TOKENSA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It explains that the tool returns a list of token metadata with specified fields, which is adequate for a read-only discovery tool. However, it does not disclose any potential limitations such as pagination or rate limits.

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

  Conciseness5/5

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

  The description is concise with two sentences, front-loaded with a [DISCOVERY] tag. Every word is useful, and there is no redundancy.

  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 the tool has no parameters and no output schema, the description provides a complete explanation of its purpose, output details, and suggested usage context. It is fully adequate for an agent to select and invoke this tool correctly.

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

  Parameters4/5

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

  The tool has no parameters, so the input schema is empty with 100% coverage. The description adds no parameter details but explains the output, which is sufficient. Baseline for 0 parameters is 4.

  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 tool as a discovery tool for tokens supported by the NEAR 1Click API. It specifies the exact output (token metadata) and distinguishes itself from sibling tools like CHECK_NEAR_SWAP_STATUS and quote tools.

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

  Usage Guidelines4/5

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

  The description explicitly suggests using this tool before requesting quotes, providing clear context. However, it does not explicitly mention alternatives or when not to use it, though the sibling tools imply different use cases.

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