Server Quality Checklist

Tool Scores

• execute_buyB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description bears the full burden. It usefully discloses the multi-stage pipeline (risk-check -> build -> sign -> broadcast) and the required env flag/keypair, which signals an irreversible on-chain write. It stops short of saying the transaction is irreversible, that funds leave the wallet, or how a failed risk-check is surfaced.

  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, zero filler, with the action sequence front-loaded and the prerequisite relegated to a second sentence. Every clause carries information.

  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 real-money mutation tool with no annotations and no output schema, the description covers the operation and auth gate but omits slippage semantics, the failure mode when the risk check fails, and whether a transaction signature is returned. Adequate but with recognizable 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?

  Schema coverage is 67%: mint and usdAmount are described in the schema (usdAmount even carries the $10-$20 bound), but slippagePct is undocumented in both places. The description adds no parameter-level meaning of its own, so this sits at the baseline-3 level for partial 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 gives a precise verb chain ("Risk-check, build, sign, and broadcast") applied to a specific resource ("a pump.fun buy"). An agent can immediately tell this executes a real trade, and "broadcast" implicitly separates it from the prepare_buy sibling, though that sibling is never named.

  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?

  It states a prerequisite (AUTO_TRADING_ENABLED=true, configured keypair) but never says when to reach for this tool versus prepare_buy or the sell path. No conditions, no exclusions, no alternative routing are given, so the agent must infer usage 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.

• execute_sellA
  3.5/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 behavioral burden. It correctly discloses the mutation nature of the operation and the environment gating flag, which is genuinely useful. It omits the traits that matter most for a live trading execution — irreversibility of the broadcast, whether funds move on mainnet, and failure/confirmation 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?

  Two short sentences, both earning their place: the first states the operation, the second states the gating requirement. The core action is front-loaded with no 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?

  For a high-risk financial execution tool with no annotations, no output schema, and low parameter coverage, the description meets the minimum but leaves key gaps: slippage semantics, irreversibility, and what constitutes success/failure are all absent.

  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 only 33%; mint is documented but slippagePct and percentOfHoldings are not. The phrase 'part or all of a held position' does add conceptual meaning to percentOfHoldings beyond its raw default/bounds, but slippagePct is left entirely unexplained.

  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 a specific verb chain (build, sign, broadcast) and resource (a pump.fun sell) and scopes it to 'part or all of a held position.' An agent can infer this is the execution counterpart to prepare_sell, but no sibling is named explicitly, so it falls short of full differentiation.

  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?

  It states one concrete prerequisite (AUTO_TRADING_ENABLED=true), which is useful context for when invocation can succeed. However, it never contrasts this with prepare_sell or execute_buy, and gives no guidance on when not to use it, leaving the routing decision to inference.

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

• log_creator_activityA
  3.5/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 behavioral burden. It usefully discloses the append-only, single-row nature and the daily cadence, which implies no update/delete semantics. It omits auth requirements, duplicate-handling, error behavior, and what is returned after the append.

  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?

  Three sentences, front-loaded with the core action, then the rationale, then the cadence rule. The thesis contrast earns its place by preventing confusion with plan-creation content. Minor: it is slightly more discursive than strictly necessary.

  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?

  Covers purpose, precondition (open plan), cadence, and the semantic distinction from the static thesis. With no output schema and no annotations, an agent has enough to invoke correctly, though return behavior and failure modes remain unspecified.

  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 all nine parameters are already documented in the schema with examples. The description only references the creator-mention row and the open-plan requirement, adding no syntax or format detail beyond the schema. Baseline 3 applies.

  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?

  States a specific verb and resource: 'Append one creator-mention row to the append-only Creator Activity sheet.' The word 'one' implicitly contrasts with the log_creator_activity_batch sibling, and the thesis distinction clarifies what this log is not. It stops short of naming the batch sibling explicitly, so differentiation is inferential rather than stated.

  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?

  Gives a clear cadence guideline ('logged at least daily while a plan is open') and scopes it to open plans, which is genuine usage context. However it never names the batch alternative (log_creator_activity_batch) or says when a single append is preferable to a batch, so the routing decision is left to inference.

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

• get_plansA
  3.6/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 the burden. It discloses two useful traits: the data comes from a 'permanent spreadsheet' and the totals are 'formula-computed' (i.e., derived rather than stored), which tells the agent the values are freshly computed. It says nothing about auth requirements, rate limits, or failure behavior.

  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?

  Two tight sentences with the core action front-loaded and the use-case following. The parenthetical field list is slightly bulky but earns its place by naming the return contents in the absence of an output schema.

  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?

  With only two fully-described optional parameters and no output schema, the description covers what is returned and when to reach for it, so an agent can call it confidently. It omits only edge-case behavior such as what an empty or unknown planId yields.

  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 'planId' (return only this plan) and 'openOnly' (exclude Closed status). The description adds no syntax or filtering detail beyond that baseline, merely saying 'all investment plans'.

  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 gives a specific verb and resource ('Read back all investment plans') and names the returned fields (Total Invested, Realized P&L, Status), so an agent knows exactly what this yields. It implies its place relative to trade-committing siblings but never names one explicitly, so it falls just short of full sibling differentiation.

  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?

  It states a clear use context — the 'track-record loop', reviewing which entry signals worked before committing to a new trade — which effectively positions it against create_investment_plan and the trade-execution siblings. It stops short of explicit alternatives or when-not-to-use conditions.

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

• get_risk_scoreA
  4.2/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 behavioral burden. It discloses the return payload (score, threshold pass/fail, triggered flags) and the external data sources, which is useful. However, it does not state whether the call is a pure read or triggers external network/API fetches, what happens on failure or for an invalid mint, or any rate/latency behavior, leaving a meaningful gap for an un-annotated 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?

  Three sentences, each earning its place: what is computed and from which sources, what is returned, and the hard workflow prerequisite. The most decision-relevant constraint (must call before prepare_buy) is placed last but is unambiguous and clearly set off.

  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?

  There is no output schema, so the description correctly explains the return shape (numeric score, threshold boolean, human-readable flags), and it covers the critical gating relationship with prepare_buy. It falls short only on failure/error behavior and whether the call has external dependencies or side effects, which would matter for a scoring tool hitting third-party APIs.

  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?

  Only one parameter and schema description coverage is 100%, so the schema already documents the base58 Solana mint address fully. The description confirms the mint is the subject of the computation but adds no syntax, format, or validation detail beyond the schema, so baseline 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?

  States a specific verb and resource (compute a rug-pull risk score for a token mint), distinguishes itself from siblings like get_token_detail and get_new_tokens by naming the composite data sources (RugCheck, GMGN), and defines the scale (0-100, higher = riskier). An agent immediately knows what this does.

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

  Usage Guidelines5/5

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

  Explicitly states the mandatory workflow condition: 'You must call this for a mint (and it must pass) before prepare_buy will accept it.' This is a concrete when-to-use rule with a named dependent sibling (prepare_buy), leaving nothing to inference about sequencing.

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

• log_creator_activity_batchA
  4.2/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 disclose that this is a write ('one spreadsheet write'), append-only, and batched into one round trip, which is useful context. However it omits error handling for partial batch failures, idempotency/duplicate behavior, and any permission requirements.

  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?

  Three tight sentences, front-loaded with the action and scope, followed by the efficiency rationale and the routing rule. No filler; 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?

  For a one-parameter batch-append tool with no annotations or output schema, the description covers purpose, efficiency benefit, and cross-plan scope. It lacks any note on batch failure semantics or return behavior, but with no output schema that gap is 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?

  The single parameter has 100% schema description coverage, so the schema already documents every nested field. The description adds a small amount of meaning — that entries may span multiple plans, clarifying the planId-per-entry structure — but mostly rests on 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?

  States a specific verb (Append) and resource (creator-mention rows) with explicit batch scope ('several ... at once'), and distinguishes itself from the singular sibling log_creator_activity. An agent can tell immediately what this does and how it differs from the single-entry version.

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

  Usage Guidelines5/5

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

  Explicitly names the alternative ('Prefer this over repeated log_creator_activity calls') and the precise condition that selects it ('whenever you have more than one mention to record'). It also notes entries may span multiple plans, removing a likely source of hesitation.

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

• log_transactionA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does disclose meaningful traits: the row is appended to a 'permanent' sheet (append-only semantics), one row per leg, and the Investment Plans sheet recalculates totals automatically from these rows. It omits error/duplicate handling and whether rows can later be amended, so not a 5.

  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?

  Three tight sentences, front-loaded with the action and destination, then timing, then the multi-leg nuance, then the downstream effect. No sentence is 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 7-parameter, no-annotation, no-output-schema tool, the description covers what it does, when to call it, and its side effects on the plans sheet. It stops short of stating the confirmation/return behavior, which would matter for an agent verifying the append succeeded.

  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%, including the enum constraint on type and per-field descriptions, so the baseline is 3. The description adds the Plan-ID tagging concept but no format or validation detail beyond what the schema already provides.

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

  Purpose5/5

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

  States a specific verb and resource ('Append one transaction row ... to the permanent Trade Log sheet') plus the scoping key ('tagged with its Plan ID'). An agent can distinguish this record-keeping tool from execution siblings like execute_buy/execute_sell without opening either schema.

  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?

  'Call this after a trade actually settles on-chain' gives a clear triggering condition, and the one-row-per-leg rule (DCA entry or scaled TP exit produce several rows under one Plan ID) tells the agent when to call it repeatedly. It doesn't explicitly name execute_buy/execute_sell as the alternative it follows, so 4 rather than 5.

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

• get_market_activityA
  4.3/5.0
  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, and it does a good job: it discloses the upstream data source, that data is aggregated across all trading pairs, and that indexing can lag new launches by minutes. It stops short of documenting rate limits, failure behavior for unindexed tokens, or caching, which keeps it from a 5.

  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 core purpose and scope are front-loaded in the first sentence, and the signal list and sibling routing follow logically. It is dense and slightly long, but nearly every clause carries information an agent needs.

  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?

  With no output schema and no annotations, the description compensates well by enumerating the derived signals returned and the aggregation scope. It still omits error behavior for unindexed tokens and any rate/refresh constraints, leaving a small gap for a data-fetch 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?

  There is a single parameter (mint) with 100% schema description coverage, so the schema already defines it as a base58 Solana public key. The description adds no extra syntax or format guidance beyond what the schema states, 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?

  States a specific verb+resource ('Live trading activity for a token') plus the data source (DexScreener) and the exact metrics returned. It also contrasts itself with sibling get_risk_score, so an agent can distinguish it without opening another schema.

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

  Usage Guidelines5/5

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

  Explicit routing guidance: 'Use this alongside get_risk_score: risk scoring says whether a token is a scam, this says whether anyone is actually buying it.' It also states a caveat for when it works (any indexed token) and a known limitation (pump.fun launches can lag a few minutes).

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

• get_token_detailA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses the live-data availability constraint and the subscription/retry semantics, which an agent could not infer from the schema. It omits permission/rate-limit behavior, but for a read-only lookup the disclosed constraints are substantial.

  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 tight sentences: the first front-loads what is returned and its sources, the second covers the one non-obvious behavioral caveat. No filler.

  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 or annotations, the description must convey return content, and it enumerates the concrete fields (bonding curve state, implied price, holders, mint/freeze authority, metadata) plus the missing-price edge case. An agent has everything needed to call and 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?

  There is one parameter and schema coverage is 100%, so the schema already documents the mint address and its base58 format. The description adds no format or constraint detail beyond that, 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?

  States a specific verb and resource ('Get price/liquidity/holder/contract detail for a specific pump.fun token mint') and enumerates the data domains returned, which separates it from narrow siblings like get_risk_score or get_new_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?

  Gives actionable usage context: it explains the source mix (live trade feed vs RugCheck report) and prescribes a retry pattern ('call this once to subscribe, then again a few seconds later if price fields are missing'). It does not, however, name an alternative sibling or state 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.

• prepare_sellA
  4.3/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 and does well: unsigned-only, no signing or broadcasting, caller signs the returned tx, and no risk gate on sells. It omits slippage-default behavior, balance sufficiency checks, and whether a quote or error is returned, so it is strong 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.

  Conciseness5/5

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

  Three tight sentences, front-loaded with the core action and scope, followed by the signing contract and the exemption from the risk gate. No filler or repetition; every clause adds selection or invocation value.

  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 3-parameter tool with no output schema, the description covers the signing workflow, the absence of a risk gate, and the sizing model, which is everything an agent needs to invoke it correctly and safely. Return-value detail is unnecessary because the tool's contract is producing an unsigned transaction.

  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 all three parameters are already documented in the schema, including percentOfHoldings defaulting to 100 for a full exit. The description reinforces the percentage-of-holdings intent but adds no syntax or format detail beyond the schema, 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?

  States a specific verb and resource (build an unsigned sell transaction) with the exact scope: a pump.fun position sized as a percentage of current holdings, for take-profit or manual exit. An agent can distinguish this from prepare_buy and from the execute_* siblings without opening any schema.

  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?

  Clearly frames this as the unsigned-preparation step ('Like prepare_buy, this never signs or broadcasts anything — you sign the returned transaction yourself') and notes no risk gate applies to exits. It does not explicitly name execute_sell as the alternative or state when to prefer one over the other, so routing is implied rather than spelled out.

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

• review_positionsA
  4.3/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and delivers: data provenance is disclosed ('rebuilt from the spreadsheets rather than anything remembered in this conversation'), live vs. cached is split explicitly (chain/price feed for holdings, price, unrealized P&L; sheet formulas for realized P&L), and the overdue-review flag is surfaced.

  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?

  Front-loaded with purpose, then a structured enumeration of returned fields, then the routing hint. Dense but every clause earns its place; the 'durable memory' closing line is slightly ornamental but reinforces the mental model.

  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 read-only review tool with no annotations and no output schema, the description supplies the essential context: what's returned, where data comes from, and when to reach for it. It does not discuss pagination or response size for the all-positions case, a minor gap.

  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% and the single planId parameter is already documented in the schema. The description's 'review all open positions' phrasing reinforces the omit semantics but adds no syntax or format detail beyond the schema. Baseline 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?

  Precise verb+resource (review open positions) with an explicit scope statement: 'the durable memory this connector is built around.' It clearly distinguishes itself from siblings like get_position (single) and get_plans (plan definitions) before those schemas are even opened.

  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?

  Gives a clear when-to-use ('Start here when picking up an existing position') and a scoping mechanism (planId vs. omit for all). It does not explicitly name a sibling or the when-not condition (e.g., versus get_position), 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.

• update_active_positionA
  4.3/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 well: it discloses that the last-review timestamp is stamped automatically, computed columns are sheet formulas and are left untouched, and ACTIVE/CLOSED status is not changed here. It does not cover permissions, error behavior, or rate limits, so it is not fully exhaustive.

  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?

  Three sentences, front-loaded with the action and scope, then side effects, then exclusions. Every sentence adds useful information and nothing is wasted.

  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 a rich input schema, no annotations, and no output schema, the description covers the mutation scope, automatic side effects, untouched computed columns, and the alternative tool for status changes. It provides enough context for an agent to invoke the tool 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 description coverage is 100%, so the schema already documents each parameter. The description lists the updatable fields but adds no syntax, format, or constraint details 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?

  States a specific verb (update), resource (working columns of an open position in 'Active Positions'), and enumerates the affected fields. It also explicitly distinguishes the operation from close_plan for status changes, so the agent can select it without opening sibling schemas.

  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 makes clear this is for updating an open position and explicitly says to use close_plan for ACTIVE/CLOSED status changes. It does not explain when to use update_active_position versus review_positions or get_position, so it falls short of full when/when-not/alternatives guidance.

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

• close_planA
  4.4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and discharges it well: it discloses that nothing is deleted, that rows remain for auditability, that spreadsheet formulas stay aligned, and that the permanent trade-log is untouched. It also reveals the refusal condition and the force escape hatch — the sort of state-mutation behavior an agent cannot infer from 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?

  Four sentences, each carrying distinct information (what is marked, what is preserved, what is untouched, when it refuses), with the action front-loaded. No filler or restatement of the 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?

  Side effects on the working vs. permanent spreadsheets and the guard condition are all covered, which is what matters for a state-mutating tool. The only minor gap is the return value/confirmation shape, but with no output schema that is a low-priority omission.

  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% and both parameters are already documented (force with a rug example, planId). The description references the force override and the Status condition but adds no syntax or format detail beyond the schema, so the baseline 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?

  States a specific verb+resource ('Close out a finished plan') and enumerates exactly what changes ('marks its Active Positions row and all its Creator Activity rows as CLOSED in the working spreadsheet'). An agent can immediately tell this apart from write-oriented siblings like update_active_position or execute_sell.

  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?

  Gives an explicit precondition ('Refuses unless the plan's formula-computed Status reads Closed') and the override path ('unless force is set'), which tells the agent when the call will succeed. It does not name an alternative tool for the force/rug scenario, so the routing guidance is strong but not exhaustive.

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

• get_new_tokensA
  4.4/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 meaningful traits: results are bounded by how long the server's live feed has been running ('since it started'), and the tool deliberately performs no safety analysis. It does not mention rate limits, pagination beyond the limit param, or refresh cadence, which keeps it short of a 5.

  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?

  Three sentences, front-loaded with purpose, then return payload, then the safety disclaimer. Every sentence carries distinct information with no 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?

  Despite having no output schema, the description enumerates the returned fields (mint, name, symbol, creator, age), which is exactly what an agent needs. The remaining gap is the absence of any note about refresh/streaming behavior or empty-feed conditions, minor for a two-optional-param read 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%, so both 'limit' (most recent first) and 'maxAgeMinutes' are already fully documented in the schema. The description adds no additional parameter semantics such as ordering or unit conventions, so the baseline 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?

  States a specific verb (List) and resource (newly launched pump.fun tokens) plus the data source scope ('observed by this server's live feed since it started'). It also explicitly distinguishes itself from the sibling get_risk_score, so an agent can differentiate without opening any schema.

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

  Usage Guidelines5/5

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

  Explicitly frames the tool as a discovery-only tool and routes safety assessment to get_risk_score. The when-to-use condition (finding fresh launches) and the when-not-to-use condition (safety evaluation) are both stated outright.

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

• create_investment_planA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so: it discloses the dual-row write, the shared generated Plan ID, the ACTIVE status, and a crucial negative constraint that aggregate columns are sheet formulas never written by this tool. This is exactly the kind of non-obvious behavior an agent 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?

  Three tightly packed sentences with zero waste: the ordering constraint is front-loaded, the write mechanics follow, and the formula-column exclusion closes with a useful negative. 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?

  For a 12-param write tool with no annotations and no output schema, the description supplies the missing behavioral context (dual write, Plan ID, formula columns) while the rich schema handles parameter details. Nothing essential to correct invocation is absent.

  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 12 parameters thoroughly, including examples for buyStrategy and sellStrategy. The description adds no per-parameter guidance beyond what the schema provides, which is the correct baseline when schema coverage is complete.

  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?

  States a specific verb+resource ('Create a new investment plan') and immediately clarifies ordering relative to siblings ('BEFORE any buy'), distinguishing it from prepare_buy/execute_buy. The double-write behavior to 'Investment Plans' and 'Active Positions' is named precisely.

  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?

  Clear guidance that no buy should be prepared without a Plan ID existing first, effectively routing the agent to call this before prepare_buy/execute_buy. Does not name alternative tools explicitly, but the workflow ordering is unmistakable.

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

• get_positionA
  4.5/5.0
  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 discloses key behavioral traits: it reads the chain directly, the P/L is an estimate based on this server's log of prepared buys, and cost-basis assumes prepared buys were executed. It doesn't specify authentication requirements or rate limits, which would be useful for a wallet-reading 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?

  Three sentences, each earning its place: the first states the primary purpose and source of truth, the second explains the P/L estimate and its basis, the third clarifies the cost-basis assumption. Front-loaded with the main function and no 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?

  For a read-only position tool with one optional parameter, no output schema, and no annotations, the description covers what the tool returns (holdings, estimated P/L), the data source (on-chain), and the caveat about P/L estimation. It provides enough context for an agent to invoke it correctly and interpret the results, though more detail on return format could help.

  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?

  With 100% schema description coverage (the mint parameter is fully documented), the baseline is 3. The description contextually reinforces that the tool reports on all holdings otherwise, but doesn't add new semantic information beyond the schema. The description does not contradict the schema. Baseline 3 is appropriate, but the description's explanation of the mint filter's role in the context of reporting adds marginal value, so 4 is justified.

  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?

  States a specific verb and resource: 'Read the configured wallet's current on-chain holdings'. It distinguishes itself from siblings like review_positions by explicitly noting it doesn't rely on the server's trade history, and the scope is further clarified with filtering by mint. An agent can tell exactly what this tool does.

  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?

  Provides clear context for when to use it—when you need a source of truth for on-chain holdings directly from the chain, and when you need an estimated unrealized P/L. It implies usage but doesn't explicitly state when not to use it or list alternative tools like review_positions. Still, the source-of-truth framing is strong guidance.

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

• prepare_buyA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the whole burden and does so: it declares the non-custodial model (never holds a private key, never signs or broadcasts), the exact artifact returned (a base64-encoded transaction), the rejection conditions (stale/failed risk score, out-of-range USD size, breached daily/weekly caps), and how a human consumes the output. This is unusually rich behavioral disclosure for a mutation-adjacent 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?

  Three sentences, each doing distinct work: what is built, what the server will and will not do plus how to use the result, then the refusal conditions. Front-loaded on the core action with no filler or repetition of the schema.

  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?

  No output schema exists, and the description compensates by naming the return value (base64 transaction) and the consumption path. Combined with the prerequisite chain and refusal conditions, an agent has everything needed to call this correctly and to explain the result, which is thorough for a 3-parameter 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%, so the schema already documents mint, usdAmount and slippagePct, including the $10–$20 bound. The description reinforces the sizing constraint via the [MIN_TRADE_USD, MAX_TRADE_USD] phrasing and the spend-cap context, but adds nothing about slippagePct semantics or default slippage behavior, so the baseline 3 holds.

  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?

  States a specific verb and resource ('Build an UNSIGNED buy transaction for a pump.fun token') and immediately scopes it as unsigned, which separates it cleanly from execute_buy (which would broadcast) and from prepare_sell. An agent can pick this out of a 17-tool sibling list without opening a schema.

  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?

  Gives explicit preconditions — get_risk_score must have been called recently for this mint and passed, and the size must fall in [MIN_TRADE_USD, MAX_TRADE_USD] and the spend caps — plus the downstream step (review/sign in your own wallet). It stops short of naming the post-signing sibling (execute_buy) or contrasting directly with prepare_sell, so selection is clear but not fully routed.

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

• gdrive_statusA
  4.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 full burden. It discloses the authentication identity (service account email, Cloud Run or key file context) and the diagnostic output (spreadsheet titles and tab names), and explains the permission-error scenario. It does not explicitly state that the operation is read-only or has no side effects, but the word 'Check' strongly implies it — a minor 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?

  Three sentences, front-loaded with the core purpose, followed by output details and then the critical 'Run this first' instruction. Every sentence earns its place and the structure is easy to parse.

  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 a simple diagnostic tool with an empty input schema, no output schema, and no annotations, the description is complete: it covers purpose, when to run, what it returns, and how to resolve a common error. An agent has everything needed to call it correctly.

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

  Parameters4/5

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

  The tool takes zero parameters, so the schema provides no parameter descriptions. The description appropriately does not discuss parameters, and the baseline for zero-parameter tools 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 states a specific verb ('Check') and resource ('connector can reach both Google Sheets') and clarifies that it reports authentication identity plus spreadsheet metadata. It distinguishes itself as a diagnostic/preflight tool from any operational siblings, leaving no ambiguity about what it does.

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

  Usage Guidelines5/5

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

  It explicitly instructs 'Run this first' and provides the exact remediation path if a permission error occurs ('share both spreadsheets with the service account email it prints'). This gives clear when-to-use and what-to-do-on-failure guidance without requiring inference.

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