AB[500] research and bounties

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuine behavioral context: collector rows are paginated because large Raster-indexed oeuvres may have thousands of addresses, which prevents an agent from assuming a single full response.

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 with no filler: the first front-loads the core purpose and required input, the second justifies and explains pagination. Every clause 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?

The description covers the input key, the singular nature of the tool, and pagination, but with no output schema it leaves the return shape and what a 'collector TDH register' contains unexplained. It also does not clarify how to advance through paginated pages or how to decide between this and list_artist_collector_tdh.

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 slug parameter is already described in the schema, and the description repeats that it is an AB5D artist slug without adding new meaning. Limit and offset have structural metadata (defaults, min, max) but no schema description; the pagination note partially explains their purpose, though it does not clarify how to page through results.

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 starts with a specific verb and resource: 'Get one artist-specific collector TDH register by AB5D artist slug.' The word 'one' distinguishes it from list_artist_collector_tdh, and 'collector TDH' distinguishes it from get_artist_otdh. This is sufficient for an agent to identify the tool's unique 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 implies usage for a single artist's collector TDH via slug, but it never explicitly says when to prefer this over list_artist_collector_tdh or when not to use it. Pagination is mentioned, but no exclusion or alternative-selection guidance is provided.

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, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the specific return field list and mentions snapshot metadata, giving the agent an accurate expectation without needing to call the tool. This adds useful context beyond the annotation bundle.

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 entire description is one efficient sentence that front-loads the core action and resource, then enumerates the returned fields. There is zero redundant phrasing or filler. Every word 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?

For a single-record lookup with a single parameter, the description adequately covers what is returned and the lookup key. No output schema exists, so listing the returned fields is helpful. It does not detail snapshot metadata contents or possible error behavior, but these are minor gaps given the tool's simplicity.

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 fully documents the slug parameter with an example, achieving 100% coverage. The description naturally references the slug but adds no additional semantic detail such as format requirements or edge cases. With complete schema coverage, 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 ('get'), resource ('one artist's oTDH'), and enumerates the exact data returned (rank, score, collector breadth, raw collector-days, project count, snapshot metadata). It also specifies the lookup key (AB5D artist slug). This clearly distinguishes it from the sibling list_artist_otdh, which likely returns multiple artists.

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 'one artist's' makes the singular scope explicit, implying this tool is for a single record while list_artist_otdh is for multiple. However, it does not explicitly name the alternative or state when to choose one over the other. The context is clear enough for an agent to infer the selection rule.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by noting that the result includes current status and operational routes, and it instructs the agent to check the status before proceeding. This adds context beyond the annotations but is minimal; it does not contradict 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 only two sentences. The first sentence front-loads the core purpose and return content; the second delivers a critical usage directive. There is no redundant information, and every clause 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?

For a simple read-only tool with one parameter and no output schema, the description provides essential context: what it does, what it returns (status and operational routes), and a critical precondition (check status before work). While it does not detail the format of 'operational routes', this is not necessary for invoking the tool correctly. It is complete enough for an agent to use it appropriately.

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 fully documents the single parameter task_id, including its source ('from list_open_bounties') and an example. Since schema description coverage is 100%, the description does not need to add parameter semantics. The tool description does not mention the parameter at all, so a baseline of 3 is appropriate given the strong 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 states a clear verb (Get), a specific resource (one AB5D bounty task), and the method of identification (by identifier). It also mentions what is returned (current status and operational routes). This distinguishes it from sibling tools like list_open_bounties (listing vs. getting a single item) and other get tools for different resources (e.g., get_artist_otdh, get_dossier).

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 context for when to use the tool: to retrieve a specific bounty and check its status. The critical usage rule 'Do not begin work unless the returned status is open' sets a clear precondition. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5 because it lacks explicit when-not-to-use guidance relative to sibling tools.

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 that the tool is read-only, idempotent, and non-destructive. The description adds useful context beyond annotations by specifying the exact composition of the returned biography and noting that the prose is CC0, which is helpful since no output schema exists.

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 tight and efficient: one well-structured sentence enumerates the payload contents, followed by a short license note. Every element earns its place and the most important action—fetching one artist's full biography—is front-loaded.

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, this description is complete: it gives the input mechanism, the full set of top-level fields in the returned biography, and licensing information despite the absence of an output schema. An agent knows what to expect and what consequences to use, with nothing 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?

There is only one required parameter, and the schema fully documents it with a clear source annotation and an example slug. The description's 'by slug' phrasing adds no meaning beyond the schema, so a baseline score 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 clear verb and resource: it gets one artist's full structured biography by slug, and enumerates the fields returned. It is clearly distinct from list_dossiers and search_artists, but does not explicitly distinguish itself from the similar-looking get_artist_otdh sibling.

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 it clear this is the tool for retrieving a single artist's complete biography once a slug is known, with the schema reinforcing that slugs come from list_dossiers or search_artists. It does not explicitly state when not to use it or name alternative tools, so it stops short of a 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by enumerating the specific elements the tool returns (definition, formulas, coverage, limitations, discussion URL, snapshot metadata), which goes beyond the annotations. However, it does not describe any potential performance, caching, or edge-case behaviors, so a 3 is appropriate.

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, information-dense sentence with no fluff. It front-loads the primary purpose and lists all key deliverables in a compact list, making it easy to scan and understand.

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 parameters and no output schema, the description provides a solid overview of what the response contains. It covers definition, formulas, coverage, limitations, discussion URL, and metadata, which is comprehensive for a documentation/metadata endpoint. A small gap is that it does not describe the exact structure or format of the snapshot metadata, but this is not essential for selection or 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?

With zero parameters, the schema carries no information. The description compensates by clarifying what the tool actually provides, which aligns with the baseline score of 4 for parameter-free tools. It adds meaning by specifying the metric and the types of data returned.

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 verb ('Get') and a specific resource: the definition, formulas, coverage, limitations, discussion URL, and snapshot metadata for AB5D's artist-level Oeuvre Total Days Held metric. It distinguishes itself from sibling tools like get_artist_otdh and list_artist_otdh, which presumably retrieve values rather than methodology.

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 does not explicitly state when to use this tool versus alternatives. It neither mentions conditions for selection nor names any sibling tools as alternatives. The usage context is only implied by the descriptor 'methodology' in the name and the listing of metadata elements.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds useful behavioral context by stating that the result set is fixed at all 308 records and enumerating the fields that will appear, giving the agent a concrete sense of the response shape. It does not mention authentication or pagination, but those are less important for a read-only, idempotent list operation.

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 sentence that front-loads the action and resource, then quickly provides the record count and key output fields. There is no filler, and every phrase contributes to the agent's understanding of what the tool does and returns.

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 zero parameters, no output schema, and annotations already covering the side-effect profile, the description carries a light burden. It nevertheless tells the agent exactly how many records exist and what fields each record includes, which is enough to invoke the tool and interpret the result 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?

This tool has zero parameters and 100% schema description coverage, so the description has no parameter semantics to add. For zero-parameter tools, the baseline is 4, and the description appropriately focuses on the output rather than 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?

The description opens with the verb 'List' and names the exact resource: 'artist-specific collector TDH dashboard records.' It also adds a precise scope ('all 308') and lists the included fields, so the agent knows what this tool returns. The 'collector TDH' qualifier distinguishes it from the sibling 'list_artist_otdh' without needing to open that tool's schema.

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 the use case: call this tool when you need the complete set of collector TDH dashboard records with their labels, routes, URLs, and source statuses. However, it never explicitly says when not to use it or names an alternative like 'list_artist_otdh' for OTDH records, so the routing decision is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is known. The description adds context about oTDH being 'price-independent' and 'current uninterrupted collector holding duration', which is domain context but not a behavioral trait like rate limits, pagination, or ordering specifics. The term 'ranked' implies sorted, but details are absent.

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 two sentences, front-loaded with the core action and scope, followed by a concise definition of the domain term. Every sentence contributes meaningful information without redundancy or fluff.

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 list tool with one optional parameter and no output schema, the description provides enough context to understand the purpose and the meaning of oTDH. It is missing explicit details about the return format or ordering direction, but given the low complexity and strong annotations, these are minor gaps.

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 0%, so the description must compensate. It mentions 'or a limited leading subset', which indirectly maps to the 'limit' parameter by implying that limiting the result set is possible. However, it does not explicitly state that the 'limit' parameter controls how many leading artists are returned, leaving the connection vague.

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 clear verb and resource: 'List the ranked oTDH records for all 308 AB[500] artists, or a limited leading subset.' This distinguishes it from the sibling 'get_artist_otdh' by emphasizing all artists or a subset, making the list-vs-single distinction obvious. The additional definition of oTDH further disambiguates its domain.

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 does not provide explicit guidance on when to use this tool versus alternatives. It never mentions 'use get_artist_otdh for a single artist' or any other exclusion condition. The only implicit usage is the scope ('all 308'), but no direct comparison to siblings 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?

The annotations already mark it as readOnly, idempotent, and non-destructive, so the description doesn't need to repeat that. It adds the 'published' qualifier and lists return fields, which is some extra context. However, it doesn't mention pagination, limits, or any potential side effects beyond what annotations cover, so it's adequate but not rich.

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, concise sentence that states the action, the resource, the filter (published), and the returned fields. It has no redundant words and is front-loaded with the primary purpose.

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 there is no output schema, the description compensates by listing the specific fields returned (name, slug, subtitle, editions, tier, updated date). It also clarifies the 'published' filter, which is useful. It doesn't mention pagination or limits, but for a simple list tool, the provided details are sufficient to understand what the tool returns.

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 has zero parameters, so the schema covers 100% of them. With a 100% coverage, the baseline is 3. The description adds no parameter semantics because there are none, which 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 tool lists every published AB[500] artist dossier and enumerates the fields returned. It also distinguishes itself from siblings by indicating it is the starting point for discovering which artists have a biography available, contrasting with get_dossier and other retrieval actions.

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 ('Start here') and hints that it serves discovery, but it does not explicitly state when to prefer this over sibling tools like get_dossier or search_artists. The guidance is present 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the constraining note 'Only returned tasks are current offers' which clarifies that the list is limited to current open offers, and enumerates the returned fields. This is useful context but doesn't go beyond what an agent might expect from a simple list operation; no pagination, limits, or data freshness details are 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?

The description is a single, front-loaded sentence that immediately states the action and scope, then lists the content fields. There is no fluff or redundancy, and each piece of information serves the agent's decision. It is highly concise and well-structured.

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 carries the full burden of explaining what the tool returns. It enumerates the exact fields returned and clarifies the 'current offers' constraint. For a simple list-all tool with no filters, this is complete—nothing an agent needs to interpret the result 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 tool has zero parameters, so the baseline per the rubric is 4. The description does not need to explain any parameter semantics because there are none; the schema is empty and coverage is 100%. No additional parameter context is possible or required.

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 'List every AB5D bounty that is currently open for claim' – a specific verb and resource, and enumerates the fields returned (reward, eligibility, claim route, submission route, protocol, acceptance command). This clearly distinguishes it from siblings like get_bounty (single item) and list_artist_otdh (different entity), so an agent can pick it without ambiguity.

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 this is the comprehensive list tool by saying 'List every...', but it offers no explicit when-to-use guidance, exclusions, or pointers to alternatives like get_bounty for specific items. The phrase 'Only returned tasks are current offers' adds a nuance about filtering, but it's not a full usage guideline. The agent must infer the selection logic from the description.

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, idempotentHint, and destructiveHint, so safety is covered. The description adds return value details ('returns matching artists with their slugs'), which is not in the schema, enhancing 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 two sentences with no filler, directly stating the action, result, and a usage tip. It is well-structured and easy to parse.

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 search tool with one parameter and no output schema, the description covers the essential context. It mentions the relationship to get_dossier and the purpose of returning slugs, though it omits potential details like pagination or result limits, which are not critical here.

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 provides a clear description and examples for the 'query' parameter ('Name or keyword, e.g. 'Fidenza' or 'tyler''). The description also reiterates its purpose, ensuring full clarity.

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 searches artist dossiers by name or keyword and returns matching artists with slugs, with a specific verb and resource. It also provides a usage scenario for when to use it before get_dossier.

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 a concrete usage hint ('Use before get_dossier when you don't know the exact slug'), which helps distinguish it from related tools. It lacks explicit contrast with other siblings but is sufficient for the simple use case.

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