Server Quality Checklist

Tool Scores

• hyre-bonding-curveC
  2.7/5.0
  Behavior1/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, but it reveals no behavioral traits: no mention of read-only status, rate limits, output format, or side effects. The sparse phrase 'Bonding curve progress' offers no transparency beyond the tool's name.

  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, succinct sentence with no filler or repetition. It is front-loaded with the core concept, though its brevity borders on under-specification rather than effective conciseness.

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

  Completeness2/5

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

  Given there is no output schema and no annotations, the description is too minimal to be complete. It does not explain what 'progress' means, how the curve data is presented, or how the two parameters relate, leaving significant gaps 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 parameters 'mint' and 'curve_key' are already fully described in the schema. The description adds little beyond the token context and price, so it does not elevate semantics beyond the baseline.

  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 'bonding curve progress' for a PumpFun token at a specific price point, which distinguishes it from sibling tools focused on new tokens, verdicts, or wallets. However, it lacks a verb (e.g., 'get' or 'fetch'), so the action is implied rather than explicit.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus sibling tools, nor any mention of prerequisites like whether 'mint' or 'curve_key' is the preferred input. The description only states what the tool reports, not when it should be selected.

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

• hyre-poolsC
  2.9/5.0
  Behavior2/5

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

  The description mentions the data included (APR, TVL, volume) but leaves the '$0.001' parenthetical unexplained. Without annotations, it does not clarify read-only behavior, default sorting, pagination, or output format, which is a significant gap.

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

  Conciseness4/5

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

  The description is a single sentence with no redundant wording. The cryptic '($0.001)' is a minor distraction, but overall it is concise and 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?

  For a simple list tool with no output schema, the description covers the core returned fields but omits defaults for sort/limit and the meaning of '$0.001'. It is minimally adequate but leaves room for ambiguity.

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

  Parameters3/5

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

  The input schema fully covers all three parameters (sort, limit, token) with descriptions, giving 100% coverage. The tool description adds no additional parameter meaning beyond the schema, 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.

  Purpose4/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 'Meteora DLMM pool list' with key metrics (APR, TVL, volume), making the purpose evident. However, it lacks an explicit verb and does not differentiate from sibling tools like hyre-pool-recommend or hyre-tvl.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusions, so an agent has no context for tool selection.

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

• hyre-tvlC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It does not state whether the operation is read-only, what the 'trend narrative' entails, how the '$0.001' cost is applied, or any rate limits. The tool likely performs a read-only query, but this is not explicitly disclosed.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the core capability. The parenthetical '($0.001)' is an unexplained addition but does not bloat the text. It is appropriately sized and easy to scan.

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

  Completeness2/5

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

  Given the lack of an output schema and annotations, the description is incomplete. It does not explain what the returned data looks like, what 'trend narrative' means, or how to interpret results. For a tool with optional parameters, more context is needed for effective use.

  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 already provides 100% coverage for both parameters ('chain' with default and description, 'limit' with description). The description adds the phrase 'across chains' which aligns with the chain filter but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly indicates the tool provides Total Value Locked (TVL) data across chains, which distinguishes it from sibling tools focused on tokens, wallets, or pools. However, it lacks an explicit verb like 'get' or 'retrieve,' and the phrase 'with trend narrative' is somewhat vague. Overall, it is understandable and distinct.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as hyre-pools or hyre-yields. There is no mention of context, prerequisites, or exclusions. The sibling list exists but the description itself does not reference it.

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

• hyre-yieldsB
  3/5.0
  Behavior2/5

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

  With no annotations, the description alone should disclose behavioral traits. It states the tool returns top yield pools sorted by APY, but does not mention whether it's a read-only operation, how data freshness is handled, whether pagination or rate limits apply, or what the '$0.002' refers to (cost?). This leaves significant behavioral ambiguity.

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

  Conciseness3/5

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

  The description is very brief and front-loaded with the core function ('Top yield pools multi-chain sorted by APY'). However, the trailing '$0.002' is unexplained and likely a typo or misplaced cost indicator, which detracts from clarity and wastes one of only eight words.

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

  Completeness2/5

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

  No output schema and no annotations place a heavy burden on the description. It fails to explain the return payload shape, whether the list supports pagination, what 'multi-chain' means in terms of default chains, or the meaning of '$0.002'. For a tool with four parameters and no other documentation, this description is insufficient.

  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%, providing basic meaning for each parameter (chain filter, max results, min APY, stablecoin filter). The description adds that results are multi-chain and sorted by APY, but does not elaborate on parameter interactions or value formats beyond what the schema already states.

  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 states it lists 'Top yield pools multi-chain sorted by APY', which clearly identifies the tool's function (listing yield pools) and the sort order (by APY). This differentiates it from siblings like hyre-pools or hyre-tvl, though it doesn't explicitly name them. The trailing '$0.002' is ambiguous but doesn't obscure the primary purpose.

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

  Usage Guidelines3/5

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

  The phrase 'Top yield pools multi-chain' implies usage for discovering high-yield opportunities across chains. However, it provides no explicit guidance on when to prefer this tool over siblings like hyre-pools or hyre-tvl, nor any 'when not to use' exclusions.

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

• hyre-pool-recommendB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the AI nature and a cost of $0.008, but fails to disclose whether the operation is read-only, any required permissions, rate limits, or side effects. This is a significant gap for a tool with zero annotation coverage.

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

  Conciseness4/5

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

  The description is a single concise sentence with a parenthetical cost note, making it front-loaded and free of wasted words. It is appropriately short for a simple tool, though it could have been slightly more structured by moving the cost to a separate attribute.

  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 tool with 4 optional parameters, no required fields, and no output schema, the description provides a high-level indication of the return ('best pool + strategy') but lacks detail on response format or how this tool fits with siblings. It is adequate for simple use cases but not fully comprehensive.

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

  Parameters3/5

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

  The schema already provides 100% description coverage for all four parameters, including enums and defaults. The description adds minimal extra meaning beyond hinting that base/quote form a token pair and that 'strategy' is part of the recommendation. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states a specific action (AI recommendation) and resource (pool for a token pair), and mentions 'best pool + strategy' which distinguishes it from sibling hyre-pools (which likely just lists pools). It does not explicitly name alternatives, so it does not fully achieve a 5, but the purpose is unmistakable.

  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 a user wants a pool recommendation for a token pair, but it gives no explicit guidance on when not to use it or how it compares to sibling tools like hyre-pools. There are no exclusions or alternative scenarios, leaving the usage context implicit rather than explicit.

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

• hyre-wallet-pnlB
  3.3/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It adds a cost per call ($0.005) and enumerates the returned data, but doesn't disclose potential error behavior, authentication requirements, or any side effects (though likely a read-only operation). The absence of annotations is partly compensated by the cost and contents mention.

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

  Conciseness5/5

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

  The description is a single, compact sentence with no filler. It front-loads the tool's purpose and lists key outputs and cost efficiently.

  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 the simplicity (one fully-described param) and lack of output schema, the description covers the main purpose and cost, but omits response format and error conditions. For a simple read tool, this is adequate but not thorough.

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

  Parameters3/5

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

  The schema already fully describes the only parameter ('address' with a clear description). The tool description adds no additional parameter semantics, so it rests at the baseline for full 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 states the tool returns Wallet PnL with specific components (realized, unrealized, portfolio value, holdings). It distinguishes itself from broader wallet tools like hyre-wallet-intel by naming the exact metrics. However, it lacks an explicit verb like 'get' or 'compute', which is a minor gap.

  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 sibling tools like hyre-wallet-intel or hyre-ask. It doesn't mention any alternatives or exclusions, leaving the agent to infer from the name alone.

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

• hyre-graduatingB
  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 the full burden. It discloses the filter thresholds (70% progress, $0.003) but does not explicitly state that it returns a list, whether results are sorted, or that it is a read-only operation. The behavior is partially inferred 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 a single, front-loaded sentence that conveys the essential criteria without any wasted words. It is optimally concise for a simple tool.

  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 zero-parameter tool, the description is mostly complete, but the meaning of '$0.003' is ambiguous (could be token price or a separate signal value), and the output format is not described. These gaps prevent full completeness.

  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 baseline for such tools is 4. The description adds meaning by defining the constant thresholds used (70% progress, $0.003), which are not present in the empty schema. This is helpful context.

  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 tool's output as tokens meeting two specific criteria: >70% bonding curve progress and a $0.003 urgency signal. This distinguishes it from siblings like hyre-bonding-curve or hyre-new-tokens, though it lacks an explicit verb like 'list' or 'get'.

  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. The description states what it returns but does not mention recommended contexts, exclusions, or comparisons to sibling tools like hyre-bonding-curve.

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

• hyre-whalesA
  3.7/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 discloses that the tool returns top holders with supply percentage and includes a cost of $0.003, which is a behavioral trait. However, it does not explicitly state that it is a read-only operation or describe error or edge-case 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 extremely concise, consisting of a single phrase with no filler. It front-loads the core purpose and includes the cost detail, making it efficient.

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

  Completeness3/5

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

  The tool has one simple parameter and no annotations or output schema. The description covers the core functionality but omits details about response structure, pagination, or potential failure modes. Given the lack of annotations and output schema, a bit more detail would improve completeness.

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

  Parameters3/5

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

  The schema already documents the only parameter, mint, as 'Token mint address' (100% coverage). The description adds no additional parameter information beyond referring to 'a token,' so it does not exceed the schema's 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 identifies the tool as returning whale/top holders for a given token, with percentage of supply. It distinguishes itself from sibling tools like hyre-token-snipers and hyre-wallet-intel by focusing on holder distribution. The verb is implied but coherent.

  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 does not explicitly state when to use this tool over alternatives. It provides no context for prerequisites or exclusions. Usage is only implied by the tool's name and description.

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

• hyre-token-snipersA
  3.8/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 bear the full burden. It discloses the behavior (detecting wallets that bought early) and mentions a cost ($0.004), but does not state output format, access restrictions, or side effects. This is a read-only analysis tool, but that isn't explicitly stated.

  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?

  Single sentence with 11 words. Front-loaded with the action. The cost is in parentheses, which is minor extra info but doesn't detract. No wasteful 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 single-parameter tool with no output schema, the description gives the core purpose and even a cost. However, it lacks any detail on what the output looks like or any prerequisites (e.g., token must exist). This is acceptable but could be slightly more 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 covers the single 'mint' parameter with description 'Token mint address' (100% coverage). The tool description adds no parameter-specific semantics beyond what the schema provides; the verb 'Detect' implies the mint is the target, but no additional detail.

  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?

  Description uses specific verb 'detect' and identifies resource 'wallets' with clear modifier 'that bought in the first few blocks' (sniper analysis). This distinguishes it from sibling tools like hyre-new-tokens or hyre-wallet-pnl.

  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?

  No explicit guidance on when to use versus alternatives, but the phrase 'sniper analysis' implies a specific use case for analyzing early-buying wallets for a given token mint. Lacks explicit exclusions or comparisons.

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

• hyre-wallet-intelA
  3.8/5.0
  Behavior3/5

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

  Without annotations, the description carries the transparency burden. It discloses a cost of $0.012 and the specific data categories returned, but does not explicitly state that the operation is read-only or any prerequisites. The cost disclosure is useful, but it doesn't fully characterize the operation's side effects or limitations.

  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 sentence, front-loaded with the core purpose, and includes the key pricing detail without excess. Every part is informative.

  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 the report's content (trading patterns, success rate, archetype) and the 30-day scope, which is useful given no output schema. It also mentions cost, which is part of the invocation context. However, it doesn't cover edge cases like invalid addresses or how to interpret the archetype.

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

  Parameters3/5

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

  The schema already fully documents the address parameter with 100% coverage. The description adds no extra information about the parameter format or usage, so it meets the baseline but does not enhance 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 provides 'Full 30-day wallet intelligence' and lists specific outputs (trading patterns, success rate, archetype). This distinguishes it from sibling tools like hyre-wallet-pnl, which likely focuses solely on P&L.

  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 use for comprehensive wallet analysis over a 30-day window, but does not explicitly contrast with alternatives or provide exclusion criteria. There is no statement like 'use this instead of hyre-wallet-pnl for deeper insights'.

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

• hyre-new-tokensA
  3.9/5.0
  Behavior3/5

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

  No annotations are present, so the description bears the full burden. It adds behavioral context with 'real-time' and 'AI snipe signal', but does not disclose return format, pagination, or any limitations. For a simple read-only getter, 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 a single sentence that is front-loaded with the essential action and resource. It includes relevant modifiers (real-time, AI snipe signal) and a cost hint without unnecessary words. No waste.

  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 tool with no parameters and no output schema, the description provides the minimal necessary clarity. However, it leaves gaps about what the 'AI snipe signal' means, what fields each launch will contain, and any additional behavior. It is acceptable but not fully complete.

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

  Parameters4/5

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

  The input schema has zero parameters, so the description cannot add parameter-specific meaning. Per the rubric, a tool with 0 parameters receives a baseline of 4, and the description appropriately provides context without needing to detail arguments.

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

  Purpose5/5

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

  The description uses a specific verb ('Get'), names a clear resource ('PumpFun token launches'), and adds unique context ('real-time' and 'AI snipe signal'). This clearly differentiates it from siblings like hyre-token-verdict or hyre-graduating, which likely focus on other aspects.

  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 (when you need real-time token launch data with a snipe signal) but does not explicitly mention alternatives or exclusions. It is enough to understand the primary use case but lacks explicit guidance on 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.

• hyre-token-verdictA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by disclosing the cost ($0.015) and the specific scope of the verdict (holders, snipers, bonding curve, risk assessment), which helps set expectations. It doesn't explicitly state it's a read-only operation, but the analytical nature of a 'verdict' implies no 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 conveys the tool's purpose, key content areas, and cost without any fluff. Every word contributes meaning, making it exceptionally concise and well-structured.

  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 no output schema, so the description must convey what the agent can expect in return. It lists the verdict's components but doesn't specify the return format (e.g., single score, text report, structured data) or any potential errors. While adequate for a simple one-parameter tool, it leaves room for more detail about the output.

  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 for the single 'mint' parameter, clearly defining it as a Solana token mint address. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states it provides a 'Full AI verdict' on a token, listing specific components: holders, snipers, bonding curve, and risk assessment. This distinguishes it from sibling tools that focus on individual aspects, making its purpose unambiguous and specific.

  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 is the comprehensive tool for a full token assessment, but it doesn't explicitly state when to use it over specialized siblings like hyre-token-snipers or hyre-bonding-curve. No alternatives or exclusions are mentioned, so usage guidance is implicit rather than explicit.

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

• hyre-askA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It states that the AI orchestrates multiple data sources and mentions a cost of $0.025, which are useful behavioral hints. However, it does not disclose whether the operation is read-only, what the response format might be, or potential side effects, leaving some transparency gaps.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the purpose ('Ask any DeFi question in natural language') and packs the critical extra detail of the $0.025 cost. There is zero waste, and 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?

  The tool is simple (one parameter, no output schema) and the description adequately explains what it does, how it works (orchestrating data sources), and a cost implication. It could mention the expected return format, but given the AI question-answering nature, it's reasonably complete. The description also naturally differentiates this tool from the many specialized siblings.

  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 already documents the single 'query' parameter with the description 'Your DeFi question' (100% coverage). The tool description adds marginal meaning by clarifying the query should be a natural language question, but this is a baseline level since the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to ask any DeFi question in natural language, with AI orchestrating multiple data sources. This distinguishes it from the specialized sibling tools (e.g., hyre-token-verdict, hyre-pools) by providing a general-purpose interface rather than a focused concrete operation.

  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 conveys when to use the tool: for any arbitrary DeFi question in natural language, implicitly covering cases not handled by the specific sibling tools. It lacks an explicit 'when not to use' statement or a direct mention of alternatives, but the general-purpose framing provides clear context.

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