FloorFeed

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful data semantics such as 'real (not wash-traded) sales' and how the 7-day floor change is measured, but it does not mention error behavior, missing symbols, rate limits, or other operational constraints.

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

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

The description is a single dense run-on sentence enumerating many metrics. It front-loads the collection scope, and each listed metric may be useful given there is no output schema, but the structure could be more readable.

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

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

Because there is no output schema, the description carries the burden of explaining return values, and it does so extensively by naming the metrics and their time windows. The missing piece is usage context relative to sibling tools, but the data coverage is otherwise strong for a single-parameter read tool.

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

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

Schema coverage is 100% and the single symbol parameter is fully described with an example in the schema. The description does not add parameter-specific meaning 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.

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

The description clearly scopes the tool to 'One collection's market' and enumerates the market metrics it returns. It distinguishes the resource as a single collection, though it does not explicitly contrast itself with siblings such as find_collections or floor_calls.

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

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

There is no explicit when-to-use guidance or mention of alternatives. The phrase 'One collection's' implies a known symbol is required, but the agent is left to infer when this tool is preferable to find_collections, floor_calls, or sales.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered and the description instead spends its words on what each ranking actually measures ('biggest 24h floor gains with real volume', 'most real volume over 7 days') — genuinely useful context the enum alone lacks. It does not disclose result count, pagination, or how ties/ordering are resolved, which keeps it below 5.

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

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

Front-loaded with the resource and its ranking nature, then definitions in parentheticals, then the scoping constraint last. Two sentences, no filler, no restatement of the tool title.

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

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

For a two-parameter read-only tool with no output schema, the description covers the semantics of both inputs and the nature of the result ('ranked lists'). What it omits is the shape of the return — how many collections come back and whether the ranking is paginated or capped — which an agent would want before calling.

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

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

Schema coverage is 50%: the chain parameter is documented inline, but the list enum is bare in the schema. The description compensates by defining all four enum values, which is precisely the missing half. It also adds the cardinality constraint ('optionally one network') that the schema type alone (a plain string) does not convey.

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

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

States a concrete resource ('ranked lists of collections') and then enumerates the four ranking modes with a one-clause definition of each metric (e.g. 'trending = today's volume against its usual day'). An agent can distinguish this from find_collections or collection without opening the schema, and the optional network scope is named up front.

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

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

The description implicitly tells the agent when each list value applies, but never says when to use this tool instead of find_collections or collection, nor when not to use it. Usage is inferable from the list definitions rather than being stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the tracked network set and enumerates the returned fields, but says nothing about match semantics (prefix/substring/case), result limits, or pagination, which matter for a search tool.

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

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

Two sentences, zero filler: the search scope comes first and the return payload second. 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.

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

With no output schema, the description usefully enumerates the return fields (symbol, network, floor, 24h/7d change, volume) and the network coverage, which is enough to call it confidently. Missing only result-count/pagination expectations for a search endpoint.

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

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

Schema coverage is 100% and the single 'query' parameter is already documented with an example ('pudgy'). The description only restates 'by name', adding no syntax or matching-behavior detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Search') and resource (NFT collections) plus the network scope FloorFeed covers, so the agent knows exactly what is searched. It does not explicitly differentiate itself from siblings like 'collection' or 'discover', which is the only thing keeping it from a 5.

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

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

The phrase 'Returns each one's symbol (for the other tools)' implies the downstream workflow — resolve a name to a symbol before calling other tools — but no explicit when-to-use or when-not-to-use guidance and no named alternative is given.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real context beyond that: results are scored by FloorFeed against its own floor history, status is surfaced, and leaderboard entries require 5+ settled calls. It omits nothing critical for a read-only query, though ranking/limit behavior is unstated.

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

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

Three tight sentences: what the data is, then the two modes in parallel structure. The clipped 'With a symbol… Without…' phrasing is efficient rather than confusing, and the core definition is front-loaded with zero filler.

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

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

For a zero-required-param read tool with annotations covering safety and no output schema, the description supplies the data's meaning, scoring basis, and mode behavior. Only the leaderboard size and per-call status vocabulary are missing, which is minor.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the semantic consequence of the optional symbol parameter — supplying it switches from a per-collection call list to a caller leaderboard ranked by hit rate — which the schema's short text does not convey.

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

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

States a specific verb and resource: members' public floor-price calls, scored against FloorFeed floor history. It distinguishes the two operating modes (per-symbol vs leaderboard). It does not name the obvious sibling (my_calls) to contrast public calls with the caller's own, which would have made the split explicit.

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

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

The 'With a symbol / Without' framing tells the agent how the two modes differ, which implicitly signals when to use each. However, it never names an alternative tool or states when NOT to use this one (e.g. use my_calls for your own calls), so routing to the right sibling 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.

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

The readOnlyHint=true and openWorldHint=false annotations already establish this as a safe, closed-world read, so the description does not need to re-explain safety. It adds useful return-content context by listing the launch attributes exposed, including phases with price and wallet limits, FloorFeed fees, reveal, and royalty. It does not describe error behavior or response structure, but with annotations covering the safety profile this is a solid additive description.

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

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

The description is compact at two sentences, and the field inventory is dense but relevant. It could be front-loaded more directly with an explicit action verb, but there is little wasted wording.

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

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 carries the burden of explaining return content, which it does by enumerating the launch details. The schema fully covers parameters, and annotations cover the read-only behavior. The main remaining gap is the lack of sibling routing guidance, which keeps it from being complete at a 5.

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

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

Schema description coverage is 100%, and the schema already documents slug, chain, and address with the same ff:<network>:<address> format and mints-tool sourcing. The description repeats the slug guidance but adds no additional meaning for chain or address, 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.

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

The description clearly identifies the resource as a FloorFeed launchpad collection and enumerates the launch data it covers: mint phases, prices, wallet limits, fees, reveal, and royalty. However, it opens with a noun phrase rather than an explicit verb such as 'get' or 'retrieve', and it does not distinguish itself from siblings like my_launch, my_launches, or collection.

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

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

It gives one concrete usage cue: pass the slug returned by the mints tool. That implies the tool is used to retrieve launch details for a collection surfaced elsewhere, but it does not state when to use this instead of my_launch, my_launches, or collection, nor does it describe exclusions.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false; the description adds the useful scope detail that results are limited to FloorFeed-launched collections and the OpenSea drops FloorFeed lists, which explains why the tool is closed-world. It also enumerates the returned attributes (network, stage, price, start/end, slug), which annotations do not cover. Missing only ordering/pagination behavior.

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

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

One front-loaded sentence with the data scope first and the returned fields after the colon. The parenthetical adds real scope information rather than filler, though the sentence is dense enough that a second short clause on freshness or ordering would have to be weighed carefully.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by listing network, stage, price, timing, and slug. For a zero-parameter listing tool with safety already covered by annotations, this is nearly sufficient; only result ordering and refresh cadence are unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly says nothing about inputs.

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

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

States a concrete resource and scope: NFT drops minting now or opening soon, drawn from FloorFeed's Mint hub plus the OpenSea drops it lists. The scope ('now or opening soon') implicitly separates it from creation-oriented siblings like launch/my_launch, but no sibling is named, so it falls short of a 5.

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

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

The timing qualifier ('minting now or opening soon') implies the use case — checking live or imminent drops — but the description never states when to prefer this over launch, my_launches, or discover. No exclusions or prerequisites are given, so usage must be inferred.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the per-entry payload (status plus a transaction link) and the event taxonomy, but it leaves the window of 'recently', ordering, and result limits undisclosed — meaningful for a feed tool.

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

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

One front-loaded sentence that identifies the subject first and then qualifies the event types. The parenthetical list is dense but each item carries information; nothing is redundant with the title.

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

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

With no parameters, no output schema, and read-only annotations, the description covers what an agent needs: what the feed contains and what each entry looks like. Missing only operational details such as how far back 'recently' reaches and how many entries come back.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The description correctly implies the feed is implicitly scoped to the link owner with no filtering arguments.

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

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

States a specific resource (the link owner's activity on FloorFeed) and enumerates the action types covered — buys, sales, offers, listings, mints, bridges, swaps — so the agent knows this is a historical activity feed rather than a holdings or alert tool. It stops short of explicitly naming which sibling (my_portfolio, my_calls, sales) to prefer for adjacent needs.

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

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

Usage is only implied: the word 'recently' and the event list suggest 'call this to see what the wallet has done lately.' There is no explicit when-to-use statement, no exclusions, and no pointer to alternatives among the many my_* siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that results are 'recent' (implying recency ordering) and scoped to the link owner, but does not disclose the default/effective limit, result ordering, or how many alerts are returned when no limit is given.

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

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

A single front-loaded sentence with the resource scope stated first followed by the enumerated alert types. It is dense but every clause maps to a real return category; only slight trimming of the list would improve it.

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

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

With no output schema, the enumerated alert types usefully describe what comes back, and the read-only annotations cover the safety profile. Still missing are the limit default, ordering, and pagination behavior for a feed-style tool, which an agent needs to call it predictably.

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

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

The single parameter 'limit' has 0% schema description coverage and is never mentioned in the description. An agent learns only from the schema bounds (1-30) and gets no default value or interpretation from the description, so the description fails to compensate for the coverage gap.

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

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

The description names a specific resource ('the link owner's recent FloorFeed alerts') and enumerates the distinct alert categories it returns (trades by followed wallets, floor/volume alerts, Offer guard warnings, offers on their NFTs, collection news). This clearly separates it from siblings like my_activity or my_calls, though it never states an explicit verb such as 'retrieve' or 'list'.

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

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

Usage is implied by the scope 'the link owner's' and by the alert categories, which are notification-style items rather than the raw activity or call records exposed by my_activity and my_calls. However, there is no explicit statement of when to prefer this over those siblings or any prerequisite (e.g., must be authenticated as the link owner).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful content shape (per-call status plus hits/settled/hit rate) and a domain definition of a Floor Call, but says nothing about ordering, completeness, time window, or freshness of the returned record.

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

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

One sentence, no filler, with the resource named first. The trailing clause 'hits, settled calls and hit rate' is slightly list-heavy but each item carries real information about the payload.

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

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

With no output schema and no parameters, the description bears the entire burden of describing the return value; it names the top-level fields but not their types, ordering, or whether results are paginated or bounded. Adequate for a simple read tool, but not fully self-sufficient.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline of 4 applies. No misleading claims about inputs are made.

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

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

The description identifies a specific resource — 'the link owner's Floor Calls' — and explains the domain concept inline (a call that one price will be over/under by a given date). The possessive scoping distinguishes it from the sibling 'floor_calls' (all calls), though the retrieval verb itself is only implied 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.

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

There is no explicit when-to-use guidance and no alternative named, despite siblings like floor_calls, my_activity, and my_alerts that an agent could plausibly confuse with this one. The reader must infer that this is the personal-scoped view rather than the global one.

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

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

With readOnlyHint=true and openWorldHint=false already declaring a safe, closed read, the description adds substantial context about the return payload: settings, artwork counts, trait rarities, metadata pin status, deployment gaps, risk score, and on-chain write cost. That is valuable for an agent to know what data it will receive, though it omits error or empty-state behavior.

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

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

The description is a single front-loaded sentence that leads with the core purpose and then packs in return details without filler. It is dense but every clause carries information, though a colon-separated list might read more easily as bullets.

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

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

For a read-only tool with no output schema, the description carries the burden of explaining what is returned and does so comprehensively—covering settings, art, metadata, readiness, risk, and cost. It stops short of describing error cases or access confirmation, but is otherwise complete.

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

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

The single draftId parameter has 100% schema description coverage, and the schema explains where to obtain the id (prepare_launch, my_launches). The main description adds no further parameter detail, so the baseline 3 applies.

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

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

The description specifies a single launch draft and enumerates its full contents, clearly distinguishing its scope from the plural my_launches list tool. However, it does not explicitly name the sibling to use for listing, leaving that inference to the tool name and param description.

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

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

The description implies use when full details of a draft are needed—e.g., checking 'what's left before it can deploy'—but gives no explicit when/when-not guidance or named alternatives. The param description mentions prepare_launch and my_launches, but the main description does not route the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds genuine return-shape context beyond that: drafts include settings, uploaded artwork counts, and what remains before deploy; live collections include minted-of-supply; each item carries a link for continuing or managing.

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

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

Front-loaded with the core statement, then the draft/live breakdown, then the sibling pointer. The nested parentheticals make the opening sentence dense, but every clause carries information and nothing is filler.

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

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

With no output schema, the description carries the burden of explaining what comes back, and it does so for both draft and live record types, including the management link. Minor gaps remain: ordering, empty-state behavior, and whether results are paginated.

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

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

Zero parameters, so the baseline is 4. The description correctly implies a fixed, owner-scoped query with no filtering options available.

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

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

States a specific verb+resource: the collections the link owner is launching or has launched on FloorFeed's launchpad, broken down into drafts and live collections. It distinguishes itself from the singular sibling by name ("my_launch shows one draft in full"), which is exactly the disambiguation an agent needs.

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

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

Implicit but clear usage context: use this for the owner's own launches, and use my_launch for a single draft in full. No explicit when-not-to-use or routing to collection/find_collections is given, so it stops short of the top score.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description doesn't need to restate safety. It adds real context beyond that: offers are scoped to the link owner (no wallet parameter, so no selection possible), they span two chains/marketplaces, and each price is rendered against the current floor with an interpretation rule.

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

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

One front-loaded sentence naming the resource first, then the venue breakdown, then the floor-comparison semantics. Dense but every clause carries information; the parenthetical explanation of floor comparison is slightly verbose but earns its place.

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

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

No output schema and no parameters, so the description must convey what comes back — it does, at the level of venue and price-vs-floor per offer. Minor gaps remain (currency/token detail, whether expired or accepted offers appear, result size), but an agent has enough to know when and how to call it.

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

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

The tool takes zero parameters, so the baseline is 4 by rule. The description usefully confirms the implicit scoping — the owner is taken from the link, not supplied as an argument.

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

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

States a specific resource and scope: open offers belonging to the link owner, broken out by venue (OpenSea collection/trait/item offers on Ethereum-style networks, Tensor on Solana). This clearly separates it from siblings like my_activity or my_alerts, which cover different object types.

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

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

Usage is implied — check your outstanding offers and compare their price to floor — but there is no explicit when-to-use versus when-not guidance, nor a pointer to a sibling for related queries (e.g., historical/accepted offers in my_activity).

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

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

Annotations already declare a safe read (readOnlyHint=true, openWorldHint=false), and the description adds genuine behavioral context beyond them: valued amounts are suppressed when the owner opted for privacy, and 'estimated value' is defined as floor minus a typical sell discount. The only gap is nothing about freshness/caching or sort order of collections.

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

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

A single front-loaded sentence that names the resource and scope first, then enumerates the returned fields, then the caveat. It is dense but every clause carries information; only the 'floor less a typical sell discount' phrasing is slightly circuitous.

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

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

With no input schema, no output schema, and security covered by annotations, the description must describe the return shape and it does: grouping by collection plus count, floor, estimated value, and cost basis. Minor omissions like ordering or whether empty/hidden collections are included remain, but an agent could call this correctly.

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

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

There are no parameters, so per the baseline this lands at 4. The description correctly signals that no targeting input is needed by specifying the owner's linked wallets as the implicit scope, which prevents an agent from hunting for an address parameter.

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

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

States a specific resource ('the NFTs the link owner holds across their linked wallets') plus the exact aggregation ('grouped by collection') and the fields returned. This clearly separates it from address-scoped siblings like wallet/collection and from my_activity/my_wallets.

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

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

Usage is implied rather than stated: with zero parameters it implicitly acts on the caller's own linked identity, which helps an agent infer it needs no targeting. But there is no explicit when-to-use or when-to-prefer-a-sibling guidance (e.g. vs. my_activity for trade history or wallet for an arbitrary address).

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

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

Annotations already establish readOnly=true and openWorld=false; the description adds valuable computation and staleness context, including after-fee offer prices, floor comparison, recent-pace sell time, and a 10-minute refresh cap. It does not contradict the annotations, but it could be clearer about the owner/link scope.

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

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

It is compact and front-loads the main output before the refresh note. However, the first sentence is dense and the phrase 'NFTs would pay' is awkward, slightly reducing readability.

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

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

For a zero-parameter, read-only analytics tool with no output schema, the description adequately covers the main outputs and freshness. It leaves some ambiguity around 'link owner' and does not differentiate from adjacent portfolio tools, so it is not fully complete.

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

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

There are zero input parameters, so there is nothing for the description to document beyond the schema. The baseline for a no-parameter tool is 4.

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

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

States a specific analytic operation: estimating proceeds from selling the owner's NFTs into current collection offers, alongside floor value and time-to-sell. The intended output is distinguishable from generic portfolio tools, though it does not explicitly name which sibling to use instead.

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

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

Provides no explicit when-to-use guidance, prerequisites, or alternatives such as my_portfolio or my_offers. The only contextual cue is the refresh cadence, which is a freshness constraint rather than usage direction.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that results are scoped to the link owner's account and that network family is included, but says nothing about ordering, result size, or behavior when no wallets are linked.

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

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

A single compact sentence with no filler, and the core content (wallets, account scope, network family) is front-loaded. It reads as a fragment rather than a complete tool statement, which slightly weakens it.

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

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

With no output schema, the description bears responsibility for describing the return value. It names the two pieces of information (wallet and network family, with an example taxonomy) but does not indicate the shape of each entry, whether addresses are included, or what an empty result looks like.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It correctly implies a no-argument, account-scoped lookup.

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

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

The description identifies the resource (the wallets linked to the link owner's FloorFeed account) and the payload detail returned (each wallet's network family, Solana or Ethereum-style). That is more specific than a tautology, though it is phrased as a noun phrase with no verb and does not explicitly contrast with the sibling `wallet` tool.

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

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

There is no statement of when to call this versus the sibling `wallet` tool, nor any prerequisites such as needing a linked account or authentication. 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds that results are ordered newest first and enumerates returned fields including price in both coin and dollars, buyer/seller, and transaction.

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

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

The description is a single efficient sentence that front-loads the core behavior and ordering, then lists the relevant returned fields. Every clause adds useful context without repetition.

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

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

For a simple read-only tool with complete schema documentation and no output schema, the description supplies the missing return-value context by naming the fields and ordering. Nothing essential for correct invocation appears to be missing.

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

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

Schema description coverage is 100%, with both limit and symbol fully documented in the schema. The description does not add parameter-specific meaning beyond that baseline, so a 3 is appropriate.

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

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

The description clearly defines the resource as a collection's most recent sales and adds ordering and return-field detail, so the agent knows exactly what the tool returns. It does not explicitly distinguish itself from siblings such as floor_calls or mints, which keeps it short of a 5.

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

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

The phrase "Answers 'what was the last buy'" implies the primary use case, but the description gives no explicit when-to-use guidance, exclusions, or alternative tools for related queries. This is adequate implied usage rather than clear routing guidance.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, but the description adds real methodology: profit is realized and net of fees, and probable market makers are filtered out. That materially changes how an agent should interpret the ranking. It stops short of noting any pagination or result-size behavior.

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

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

One dense, front-loaded sentence that packs definition, ranking basis, exclusion rule, and returned fields with no filler. The trailing field list is slightly list-like but earns its place since there is no output schema.

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

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

For a 2-parameter read-only tool with no output schema, enumerating the returned metrics is a genuine fill-in. The gap is the undocumented 'limit' parameter and the 25-row cap, which an agent needs to call correctly.

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

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

Only 'window' has schema documentation ('Days to count (default 30)'); 'limit' has no description in the schema and none in the description. At 50% coverage the description should compensate, but it says nothing about the limit cap of 25 or the window enum's effect on the leaderboard.

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

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

Names the resource (NFT flipper leaderboard), the ranking basis (realized profit after fees), and the exclusion rule (likely market makers). It also enumerates the metrics returned, so it is distinguishable from siblings like 'wallet' or 'collection', though it is phrased as a noun label rather than a verb+resource action.

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

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

There is no indication of when to pick this over siblings such as 'wallet' or 'collection', nor any prerequisites. 'Likely market makers left out' is a data-scope statement, not usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the source (FloorFeed), the profit basis (after fees, in main coin and dollars), and the precise copy-score methodology (buying and selling at the floor 10 minutes late, after fees). It does not state behavior for an unrecognized address or unsupported chain, 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.

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

One sentence, front-loaded with the resource and then the metric list, with no filler. It is dense with nested parentheticals, which slightly taxes scanning but every clause conveys substance.

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

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

With no output schema, the description correctly takes on the job of explaining what comes back, and it does so thoroughly, including derived metrics and their computation. Minor omissions such as address-not-found behavior and supported-chain support keep it just short of complete.

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

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

The single parameter has 100% schema description coverage, including both Solana base58 and Ethereum 0x formats, so the schema does the heavy lifting. The description adds nothing about the address parameter, so the baseline 3 applies.

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

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

The description opens with a specific verb+resource ("A wallet's NFT flipping record from FloorFeed") and enumerates exactly which metrics are returned: flips, win rate, realized profit, trader tier, copy score. This clearly separates it from sibling tools like 'sales' or 'mints', though it never explicitly contrasts with closer siblings such as 'top_traders' or 'my_wallets'.

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

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

There is no explicit statement of when to use this versus alternatives, nor any exclusions. Usage is only implied by the mention of 'trader tier' and 'copy score', which hint at vetting a wallet for copying, but an agent must infer this.

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