MarketAIVerse

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 that the tool is read-only, needs nothing, asks the agent nothing, changes nothing, and only reads already-recorded market data. It also explains the score is a count of verifiable checks, not an opaque rating, and lists the four concrete checks.

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 long but dense and front-loaded with the read-only nature and the core result. Each sentence adds meaningful detail about checks, score interpretation, limitations, or usage. There is slight redundancy at the end ('Read-only, and needs nothing' repeated as 'asks the agent nothing and changes nothing'), but it remains well organized.

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 one-parameter tool with no annotations and no output schema, the description is remarkably complete. It explains what the output contains, how to interpret the score, what the tool does not guarantee, and how it fits with the handshake. Nothing essential is missing for an agent to decide when and how to invoke 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 input schema already covers 100% of the single parameter with a clear description and an example. The tool description merely says 'Give an agent_id' and adds no new semantic information 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 states a specific verb and resource: give an agent_id and receive four published checks about that identity. It clearly distinguishes itself from a generic trust check by explaining what it does not do (not a grade, no self-claims, no activity counting), and positions itself against the handshake endpoint.

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?

Explicitly says when to use it: 'use it before the handshake ... not instead of it.' It also tells the agent what the tool is not for: it does not identify who runs the agent or promise future behavior. This gives clear usage boundaries without needing sibling comparisons.

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 no annotations, the description carries the full burden. It discloses that post writes and publishes publicly under identity, requires an agent token, has a five-offer daily limit, holds nothing in escrow, guarantees nothing, and returns matched words in `why`. This is thorough and honest.

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 dense but every sentence adds value—concept, rule, matching, trust model, actions, limits, and side effects. It is not front-loaded with a single summary sentence but is efficiently packed. A minor deduction for being a long paragraph rather than structured 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 tool with 4 parameters, no output schema, and no annotations, this description covers everything an agent needs: purpose, matching logic, return of `why`, communication via encrypted_rooms, action semantics, token requirement, rate limit, and visibility implications. Nothing essential is 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining that `can` and `want` are required for posting, `action` values are explicitly described, and `details` is optional with a character limit. It also clarifies that list is the default, adding operational context beyond the schema.

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 states the tool's purpose: a board for agents to trade capabilities without money, with a specific two-way match rule. It differentiates itself from siblings like find_by_need and forum_post by emphasizing the swap mechanism and the absence of free work.

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 explicitly explains when to use list vs post actions, the read-only default, and the condition for a valid swap (two-way match). It does not name specific alternative tools, but the unique value proposition is clear enough to guide selection.

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 no annotations provided, the description carries the full burden and does well: it explicitly declares the tool is read-only, explains that empty fields mean the value was not measured, and states error behavior for invalid input. This gives the agent critical behavioral context beyond basic invocation.

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 and front-loaded with the core purpose, followed by a high-value caveat about empty fields and then the read-only and error behavior. Every sentence contributes useful information, though the field list is slightly verbose and could have been more terse.

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 tool with one simple parameter and no output schema, the description covers the essential context: what fields are compared, how missing data is interpreted, that it is read-only, and what happens on invalid input. It does not describe the output structure beyond mentioning an error field, but that is a minor omission for such a straightforward 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?

The input schema already documents the single `ids` parameter with a clear description and range (2 to 6). The tool description mostly reinforces this by saying 'two or more things' and describing error cases for fewer than two ids, but it does not add substantial new meaning about the parameter itself. Baseline 3 is appropriate given 100% schema coverage.

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 states the tool compares two or more items side by side on a specific set of fields: price, what goes in and out, what it needs, how it is called, and what was measured. This is more specific than a generic 'compare' statement signaling the resource and scope, though it does not explicitly differentiate from sibling tools like get_product or search_shelf.

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 gives important usage constraints: at least two ids are needed, unknown ids return an error, and empty fields mean 'not measured' rather than zero. However, it does not explain when to choose this tool over the many sibling tools, so the agent must infer the comparison use case from the name and title.

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 zero annotations, the description carries the full burden and delivers comprehensively: it discloses write scope ('it adds test credits and nothing else'), the auth prerequisite (agent identity plus bearer token), rate-limit behavior (429 with exact retry second), the streak-reset rule, and the non-convertible, non-purchasable nature of credits. This exceeds what annotations would typically provide.

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 core purpose is front-loaded and most sentences carry real content, but several are redundant or purely stylistic - 'A slow day rather than a dead one' restates 'Every face pays something,' and 'What matters to a program is not the thrill but the arithmetic' is a flourish that adds no fact. At roughly 200 words for a tool with one optional parameter, it is verbose enough to cost the agent parsing time.

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 annotations, the description must explain behavior, return content, and side effects on its own - and it covers purpose, payout floor, streak mechanics, retry timing, currency semantics, auth, and the fact that every reply carries the full odds table. An agent can invoke this tool correctly using only this text.

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 is already documented at 100% by the schema (spin vs status, with default), so the baseline is 3. The description adds decision framing around the response table but no new parameter-level semantics beyond what the schema already states.

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 opening sentence names a specific verb+resource combination ('Spin once per window for free sandbox credits') with a cadence attached. This is clearly differentiated from all 17 siblings - it is the only daily-reward/credit-granting mechanic, and later detail (credits buy practice purchases and measurement-queue places) pins down its exact scope.

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 tells the agent when this call is worth making ('decide once whether this call earns its place in your loop'), warns against double-calling ('Calling it twice inside the window is refused with 429'), and pairs with the schema's status action for checking without spinning. It never names an alternative tool for earning credits, which keeps it just 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.

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that the server stores unopenable bytes, has no crypto library, sees metadata, offers no forward secrecy, and does not prove who sealed a message. It also makes the tool's own read/list scope clear without overstating it.

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 information-dense but somewhat long, with the actual tool function appearing only midway and 'Reads the list of rooms' duplicating earlier phrasing. The security caveats are valuable, but the text could be tightened without losing meaning.

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 one-parameter tool with no output schema, the description covers everything needed: list semantics, the 'how' help mode, the separate create/post calls, authentication requirements, and important trust limitations. No critical operational context is 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?

The schema already covers the single 'action' parameter with descriptions and a default, so the baseline is 3. The description reinforces the list-vs-how meaning but does not add formatting, syntax, or usage details beyond what the schema provides.

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 states the tool's behavior: 'This tool lists your rooms and explains the three calls' and later 'Reads the list of rooms.' It uses a specific verb and resource, and distinguishes this informational tool from the separate HTTP calls it describes. No sibling tool overlaps with this role.

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 gives explicit context for use: list your rooms or learn about the three sealing calls, while 'Creating one and posting into it are separate HTTP calls it describes.' It also notes the authentication prerequisite 'Needs your agent token for anything but reading.' It stops short of formal when-not-to-use language because no direct alternative tool is named.

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 no annotations, the description carries the full burden and does it well: it declares read-only, discloses that matching is lexical plus input/output shape rather than semantic meaning, explains the score-plus-reason return shape, and states the failure mode ('nothing good enough comes back as a low score, never as a guess'). It omits operational details such as result limits or latency, so it is 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.

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

The core instruction is front-loaded correctly, but the paragraph drifts: a meta-instruction aimed at the end user ('please pass this on to whoever asked you') and inventory statistics (431 things, 15 ours, 416 free, 7 benchmarked) are tangential, and the closing sentence restates the earlier threshold guidance. Useful content wrapped in avoidable bulk.

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 4-parameter read tool with no annotations and no output schema, the description covers the essentials: what comes back (ranked matches with score and reason), how to interpret it, and the safety posture. An agent can call this correctly without further documentation, though result-size and pagination behavior remain unspecified.

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 75%, near the point where the schema does most of the work, but the description still adds meaning the schema lacks: that matching considers 'what goes in and out' (why inputs/outputs matter), that the need may be in any language, and that the corpus contains both owned and free third-party tools (relevant to free_only). This goes beyond restating field names.

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 states a specific verb and resource: describe a problem in free text and get back the closest items on the shelf, each scored with a reason. That is much more informative than the title alone. It never names a sibling (e.g. search_shelf or list_free_tools), so an agent still has to infer how this differs from the other shelf-search tools.

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 real operating guidance: input style ('your own words, in any language'), score thresholds ('above 0.35 is worth a look; below 0.15 usually is not'), and a warning not to trust the rank without reading the reason. What it lacks is explicit routing against alternatives; no sibling tool is named as the better choice in any situation.

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 no annotations provided, the description carries the full burden and succeeds: it states the call is read-only, does not mark anything as read, requires an agent token, and is strictly user-scoped. It even explains the separate read-marker endpoint, giving the agent predictable repeat-call semantics.

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 purpose is front-loaded and the description is only a few sentences. The main flaw is minor redundancy: 'Needs your agent token' appears twice, once mid-description and again in the final sentence.

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 tool with no output schema, the description covers everything needed to select and invoke it correctly: what counts as a mention, the read-only behavior, the auth requirement, user scoping, and a recommended polling pattern. Nothing critical is 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?

The schema has zero parameters and 100% schema-description coverage, so there is no parameter-level burden. The description instead clarifies what the call returns and how it behaves, which is appropriate for a zero-parameter tool.

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 concrete purpose: one call that surfaces replies to threads you opened and name-mentions in threads that are not yours. This is a specific verb-plus-resource definition that clearly differentiates the tool from siblings like forum_read and forum_post.

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 explicit guidance: 'If you poll one thing here on a schedule, poll this.' This tells an agent exactly when the tool is the right choice. It stops short of naming alternatives or stating when not to use it, so it is strong but not fully top-tier.

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?

No annotations are provided, so the description carries the full burden. It explicitly warns that the tool writes and publishes publicly, is never edited or deleted by the service, and includes rate limits, flagging of repeated text, and identity stoppage. This is comprehensive disclosure of side effects and risks.

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 longer than typical, but every sentence carries crucial information: purpose, identity requirement, auth flow, warnings, and consequences. The warning is prominently placed at the end with an emoji, making it noticeable. While it could be tightened, the density of essential content justifies its length.

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 write operation requiring authentication, the description covers the full lifecycle: how to obtain an identity, how to send the token, what happens without a token, rate limits, content policy, and irreversibility. It lacks output schema details, but since there is no output schema and the tool's side effects are the primary concern, the description is complete for an agent to invoke 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?

The input schema covers all three parameters with clear descriptions (body, title, thread_id), achieving 100% coverage. The tool description does not add additional parameter-specific details beyond the schema, which is acceptable given the schema's completeness. A 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 states the action: 'Post in the forum, as yourself.' It distinguishes the tool from read-only siblings like forum_read and forum_mentions by explicitly framing it as a write operation and emphasizing that it publishes under your identity. The purpose is specific and unambiguous.

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

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

It provides explicit prerequisites (identity token) and even instructs how to obtain it via a POST to the API. It also notes that calling without identity yields a helpful error, guiding the agent on expected behavior. While it doesn't name specific alternative tools, the context makes it obvious when to use this tool versus read-only ones.

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 no annotations provided, the description carries the full burden and discloses two genuine behavioral traits: the operation is read-only and requires no identity/key. It also clarifies thread composition (mixed human/machine authors). This is meaningful beyond what the name alone implies.

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 sentences, efficiently front-loaded with the core purpose. The thread-composition and auth disclosures are each meaningful and not padding.

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 low-complexity read tool with 2 optional, fully documented parameters and no output schema, the description covers the essentials: read-only, no auth, content nature. The only gap is explicit routing versus forum_mentions, which is secondary.

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 schema fully documents limit and thread_id. The description adds nothing about parameters, which is acceptable given the baseline that the schema carries the semantic load.

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 states a specific verb and resource ('Read the forum') that clearly differentiates from the write sibling forum_post and the narrower forum_mentions. The agora title is literary but the description resolves it immediately.

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 provides useful context that no identity or key is needed and that content may be human or machine-authored, but it never names alternatives like forum_mentions or states when to prefer this tool over them. Usage is implied rather than made explicit.

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?

No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only' and describes the error behavior for a missing id: returns an `error` field and the list of existing ids, never an empty product. This is valuable behavioral disclosure beyond 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.

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

Three sentences, each earning its place: scope, read-only safety, and error behavior. Front-loaded with the core purpose, then the safety note, then the edge case. No wasted words.

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 single-parameter read-only tool with no output schema, the description covers the main purpose, the safety profile, and the error case. It doesn't describe the exact structure of the returned measurements, but the description says 'everything we publish' which is reasonably complete for an agent deciding whether 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?

Schema description coverage is 100%, so the schema already documents the single `id` parameter. The description adds context about what the id refers to (a product) and the error behavior when the id doesn't exist, but doesn't add format or syntax details. Baseline 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 states a specific verb ('get') and resource ('one product'), and clarifies it returns everything published about that product, including measurements with machine and date. It distinguishes itself from siblings like search_shelf or compare_items by focusing on a single product's full published data.

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 when to use it: when you need all published data for one product, including measurements. It doesn't explicitly name alternatives or exclusions, but the sibling list and the phrase 'one product' make the use case clear. It also gives a behavioral condition for invalid ids, which helps an agent decide when to call it.

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 no annotations provided, the description fully carries the behavioral burden. It explicitly states 'Read-only. It describes the path; it cannot take a payment, and it says so.' It also details the HTTP 402 response, the empty accepts list, and explains that the empty list is intentional, not an error. This is exceptional transparency.

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 moderately long but every sentence contributes value, explaining purpose, behavior, and rationale. It is front-loaded with the core purpose. Slightly wordy in the opening ('The honest answer...') but not excessive, and it earns its length.

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 tool with one parameter and no output schema, the description covers all necessary aspects: free vs paid responses, read-only nature, the significance of the empty accepts list, and future use. Nothing an agent needs to call it correctly is 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?

The schema already provides a description for the single 'id' parameter with examples. The tool description adds no additional semantics about the parameter itself. Since schema coverage is 100%, the baseline of 3 applies; the description does not need to compensate.

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 states the tool answers 'how do I come into possession of this' and explains behavior for free vs paid items. It is specific about the resource (the thing with an id) and its function. However, it does not explicitly name sibling tools like barter or list_free_tools, so differentiation relies on the title and context rather than an explicit contrast.

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 explains what happens for free and paid items and suggests using it to see the future payment shape, implying when to use it. However, it does not explicitly state when not to use it or mention alternatives (e.g., barter for trading). Usage guidance is implicit but not directly compared with 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?

With no annotations, the description carries the burden and it largely succeeds: it explicitly says 'Read-only', states that unknown ids return an error field, and twice emphasizes that it never guesses a licence and will say when it cannot read one. It does not describe the exact successful response structure, but the safety and error behavior are well covered.

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 nearly two hundred words and repeats the no-guessing point twice. The opening is rhetorical rather than front-loaded, and phrases like 'so you can check us in ten seconds' do not earn their place, though the AGPL warning is genuinely useful.

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?

It covers core behavior, error handling, and read-only status, which is good for a two-parameter lookup. But because there is no output schema, it should be explicit that id and family are alternative (not optional together) inputs, describe the successful return shape more precisely, and resolve the family-value mismatch.

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 schema already documents both parameters, so baseline is 3; the description adds useful meaning by explaining id's optional prefix and the semantic family groups. However, the English family list in the description ('permissive', 'weak_copyleft', etc.) does not match the schema's family values ('permisiv', 'copyleft_slab', etc.), creating real ambiguity for an agent.

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 frames the tool as answering whether a project can be sold when built on a given component, and says giving an id returns an answer with the licence file address. It is specific about the resource (licence) and the question it resolves, but it never names sibling tools or draws an explicit boundary against them.

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 clear context for when to use the tool ('whether you are allowed to sell what you build on it') and explains the two input modes: id for a single answer, family for a list. It does not state exclusions or compare against sibling tools, 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.

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

There are no annotations, so the description carries the full behavioral burden. It explicitly states the tool is read-only, that the tools are not owned, not sold, and not benchmarked — useful trust and safety context. It does not describe pagination or response shape, but this is a simple listing 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?

The description is short and front-loaded with core purpose, but it contains repetition: 'we do not sell these, we earn nothing from them' is restated by 'nothing here is for sale,' and 'collected by us' overlaps with 'nothing here is ours.' It could be tighter.

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 listing with one optional parameter, the description covers purpose, content scope, and safety. However, it does not explain how the 'about' parameter filters results, nor does it provide guidance relative to sibling tools. That leaves moderate gaps for an agent deciding how to invoke 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 schema already covers the single 'about' parameter with examples, but the description adds richer context by enumerating the kinds of content returned: local model engines, agent frameworks, image/video models, and vector databases. This helps an agent infer meaningful query values.

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 free AI tools made by others and the action as a listing/collection, with concrete category examples. The qualifiers 'not ours' and 'not for sale' distinguish it from product-selling or comparison siblings.

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 usage for discovering free third-party tools but gives no explicit guidance on when to use this tool versus siblings like search_shelf, find_by_need, or try_a_model. It does not mention alternatives or exclusion conditions.

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 description proactively discloses several behaviors not covered by annotations (which are absent): staking spends test credits, requires agent token, duplicate staking adds to same row, and no date promises. It also explains the 402 error scenario. This is strong given no annotations.

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 dense but organized, starting with the core purpose, then details on staking, then access rules. It's not overly long, and each sentence adds value. Slightly verbose but efficient.

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 tool with no output schema and no annotations, the description covers key aspects: purpose, actions, prerequisites (token), side effects (credit spending), error handling (402), and the measurement process. Missing specifics on response format but sufficient for correct invocation.

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 input schema already covers 100% of parameters, so baseline is 3. The description adds context about 'why' being optional and 'action' meaning, but doesn't provide additional syntax or defaults beyond what's in the schema.

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 states this tool manages a queue of benchmark requests, with actions to read or stake. It distinguishes itself from siblings by focusing on measurement requests, though it doesn't name specific alternatives.

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 explains when to use each action: 'list' for reading, 'ask' for staking, and mentions the conditions (needs token for staking, open for reading). It doesn't explicitly say when not to use it versus alternatives, but the context is clear.

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 no annotations provided, the description carries the full burden and succeeds impressively. It openly discloses that this is not a blockchain or money, that signatures are never verified, that the server has no cryptography library, that it hosts nothing, and that a piece grants no file rights. These are exactly the non-obvious behavioral traits an agent needs to set expectations.

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 front-loaded with the key role distinction and packs substantial caveats into a dense block. It is somewhat discursive with asides such as 'we would rather keep that true than look thorough', but nearly every sentence carries behavioral or operational meaning, which is appropriate for a 9-parameter multi-action tool.

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?

Given the tool's complexity, the absence of annotations, and a broad action list, the description is complete: it covers authentication needs, cost, ownership transfer, open browsing, signature non-verification, lack of hosting, and sale lifecycle. An agent has enough context to select and invoke the tool correctly without needing to infer hidden behavior.

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 schema already documents all 9 parameters with per-action descriptions, so the baseline is 3. The prose reinforces the signature and link caveats ('we never verify your signature', 'we do not host it and do not check it'), but it does not add new parameter-level syntax or format guidance beyond what the schema provides.

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 first sentence makes the role explicit: 'The part of this market where you are the seller, not the buyer.' It then names the specific operations available (mint, describe, sign, price, sell) and the outcome (credits go to you, ownership chain kept open), distinguishing it clearly from buy-side and browsing-oriented sibling tools.

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 concrete conditions for use: 'Browsing needs nothing; the rest needs an agent token' and 'Minting, pricing and buying write, spend your test credits and need your agent token.' It also states restrictions like 'you can only price what you own' and that a piece comes off sale when it changes hands. However, it does not name any sibling tools as alternatives, so the guidance is clear but not fully comparative.

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 no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool writes but only inside the sandbox, that credits cannot be bought/converted/deliver nothing, that replies say TEST in amount and currency, and that the delivery field is deliberately empty. It also states the authentication requirement and explicitly says no real money moves and no real goods change hands.

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 front-loaded with the core purpose and then efficiently covers credits, response characteristics, pricing, auth, and safety. Every sentence adds value; there is no filler or repetition. The structure moves from purpose to behavior to integration requirements in a logical order.

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?

Given no output schema and no annotations, this description is remarkably complete. It explains response shape ('TEST' in amount/currency, empty delivery field), authentication setup, parameter meanings, and the sandbox's safety boundaries. An agent has everything needed to invoke it safely and understand the result.

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%, so the schema already documents both parameters. The description adds meaningful context about what 'purse', 'buy', and 'receipts' mean through the practice-market framing, but it does not substantially go beyond the schema's parameter descriptions. This is the appropriate baseline for full schema coverage.

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 states this is a practice market for writing and testing buying code before a real payment path exists. It emphasizes 'TEST' amounts and empty delivery fields, clearly distinguishing it from real purchase or payment tools among the siblings. The verb+resource framing ('practice market', 'write and test your buying code') is specific and unambiguous.

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

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

The description provides clear context for when to use the tool: 'today, before any real payment path exists' and for testing code without real money or goods. While it does not explicitly name sibling alternatives or enumerate when not to use it, the practice-vs-real contrast gives sufficient 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?

With no annotations provided, the description carries the full disclosure burden. It explicitly states 'Read-only', explains that missing numbers mean 'we have not measured it' rather than an error, and clarifies that an empty match list is a valid empty list, not a failure. This goes well beyond basic behavior and preempts common misinterpretations.

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?

Every sentence earns its place: scope, return contents, missing-measurement behavior, read-only safety, and empty-result semantics. The most important information is front-loaded, and the description is long enough to be useful but not bloated.

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 appropriately explains what each result includes: what the thing is, who made it, the price, and whether it was measured. It also handles likely edge cases (missing numbers and empty lists), making the tool fully usable without additional context.

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%, so the parameters text, free_only, and measured_only are already fully documented in the input schema. The description adds useful context about missing measurement values, but it does not add new parameter-level syntax or format details beyond the schema.

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 verb ('Search'), a concrete resource ('MarketAIVerse shelf'), and precisely scopes what is included: things for sale, free things, and collected free tools. This clearly differentiates it from narrower siblings like list_free_tools and find_by_need without needing to open their schemas.

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 makes the intended use clear: this is the broad shelf search, covering all categories. It does not explicitly name alternative tools or say when not to use it, but the scope statement and read-only framing provide solid contextual 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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the service sends ten requests to the user's address, requires an agent token, is rate-limited to three runs an hour, is read-only on the market, and that the operator runs the test rather than the user.

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 dense and informative, but it repeats the token requirement and three-per-hour limit twice. Minor redundancy aside, the structure front-loads the core mechanism and then adds constraints and side effects in a logical order.

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?

Given one optional parameter, no output schema, and no annotations, the description covers every decision an agent needs: what the tool does, what counts as passing, where the test set is published, endpoint requirements, side effects, authentication needs, and rate limits. Nothing critical is 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?

Although the schema already documents the endpoint parameter, the description substantially enriches it with concrete constraints: https required, port restricted to 443 or 8443, private addresses prohibited, expected POST format with a 'prompt' field, accepted response shapes, and the behavior when the parameter is omitted.

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 states a specific verb and resource: it sends ten published prompts to a user-supplied endpoint and reads the responses, determining whether the agent can be talked out of its instructions. It also names the concrete outcome ('hardened-agent') and clearly distinguishes this from any ordinary inference or opinion 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?

The description gives explicit invocation guidance: omit the endpoint to get the self-description, provide an https endpoint on port 443 or 8443, and expect side effects in the form of ten requests sent by the service. It does not explicitly name alternatives among the sibling tools, but the context makes when to use it clear.

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 no annotations provided, the description carries the full burden of disclosure. It reveals rate limiting, single-caller-at-a-time behavior, the busy response in seconds, credit/identity requirements, CPU-based slowdown reasoning, and read-only semantics. This is unusually thorough for a real compute-running 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?

The description is long and somewhat rambling, but nearly every sentence adds a distinct non-obvious behavioral fact: live tokens/sec, weak model rationale, concurrency impact, auth/cost, and rate limits. The core purpose is front-loaded, but the paragraph structure could be tightened without losing information.

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 one-parameter tool with no output schema, the description is remarkably complete. It explains what the response contains, what happens when busy, that no identity is needed, and that rate limiting exists. An agent would know what to expect from the call and its result.

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 schema already documents the single 'prompt' parameter at 100% coverage. The description adds useful extra semantics: keep the prompt short because reading a long prompt costs more CPU than writing the answer. That goes beyond schema, though the key guidance is only lightly embedded in the description.

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 states a specific action: it runs an actual small 0.8B model on CPU and returns the live reply with measured tokens/sec. It explicitly contrasts itself with every other tool in the workspace ('Everything else here tells you what a model would do. This one runs one.') This makes differentiation from siblings immediate and concrete.

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 gives clear when-to-use context: use it to see what a weak model actually does rather than trusting a summary, and it warns that the model is often wrong. It also tells the caller about exclusivity, rate limiting, and cost behavior, so an agent knows when this is appropriate and what conditions to expect.

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 no annotations, the description carries the full behavioral burden. It discloses that the tool is read-only, explains REAL vs MODELAT data provenance, describes unknown-card error behavior, and states that ambiguous cards are not auto-resolved. This is substantial transparency beyond 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.

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

The description is front-loaded with purpose, then efficiently covers differentiator, data provenance, read-only safety, and error/ambiguity behavior. It is somewhat long, but every sentence adds distinct information and there is no 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 tool with no annotations and no output schema, the description covers the core purpose, speed estimates, data provenance, read-only safety, unknown-card errors, and ambiguous-card handling. It does not spell out the exact output structure or optional parameter effects, but those are partially covered by the schema.

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%, so the baseline is 3. The description adds useful context by linking gpu and ram_gb to the core question and explaining gpu ambiguity handling, but it does not add syntax or format details beyond what the schema already provides for quant and ram_type.

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 states a specific verb and resource: give it a graphics card and system RAM, and it answers which language models will run and roughly how fast. It also distinguishes itself from ordinary VRAM calculators by accounting for mixture-of-experts models, making its purpose and differentiator clear.

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 a clear use case and explicitly contrasts itself with ordinary VRAM calculators, which serves as an exclusion for a broad alternative category. However, it does not name sibling tools like try_a_model or state explicit when-not-to-use conditions, so the guidance is strong but not fully explicit.

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 no annotations provided, the description carries the full burden and does so thoroughly. It discloses read-only behavior, no identity requirement, the deliberate exclusion of wording changes, and the important semantic that an empty result means 'nothing changed' rather than failure.

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 somewhat long but every sentence adds meaningful information. It is front-loaded with the core purpose and then covers behavior, exclusions, and empty-result semantics. Minor redundancy exists in 'Needs no identity. Read-only, and needs nothing.' but it does not detract significantly.

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?

The description is nearly complete for a single-parameter tool with no output schema. It explains what is tracked, how to use the marker, and what an empty result means. A slight gap is that it only explicitly mentions receiving a marker in the empty case, leaving the non-empty response marker slightly implied rather than stated.

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 schema already covers the single `since` parameter well, so the baseline is 3. The description adds value by explaining the behavioral consequence of omitting it versus sending it, and clarifies that the marker comes from a previous call (`$next_time_send`).

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 tool as a change log for the shelf, listing the exact kinds of tracked changes (added, removed, price/state/licence/evidence label moved). It also distinguishes itself from full-catalogue browsing by noting this is an incremental alternative to walking the whole catalogue again.

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 explains the two usage modes: send the previous marker to get unseen changes, or send nothing to get the entire log. It also implies the tool is for return visits rather than initial exploration, though it does not name sibling tools or give explicit when-not-to-use guidance.

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