Server Quality Checklist

Tool Scores

• arena_searchC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden. It discloses one prerequisite (premium subscription) but does not state whether the operation is read-only, what data it returns, limitations, or authentication needs. Search implies read-only, but that is not explicit.

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

  Conciseness4/5

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

  The description is short and front-loaded, with each sentence serving a purpose: stating the action and a key requirement. However, the brevity comes at the cost of missing essential usage and parameter details, though the structure itself is clear.

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

  Completeness1/5

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

  For a search tool with no output schema, no annotations, and zero parameter documentation, the description is severely incomplete. It does not convey what is searchable, how results are structured, or how to use the optional parameter, making it inadequate for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention either parameter. It fails to explain what 'query' should contain or how 'per' controls pagination/results. The schema only provides type and numeric bounds, which is insufficient.

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

  Purpose4/5

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

  The phrase 'Full-text search' clearly identifies the action and resource, and it is distinct from sibling tools like arena_get_channel or arena_list_my_channels. However, it doesn't specify the exact scope of what is being searched (e.g., blocks, channels, users), which leaves some ambiguity.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It only mentions a subscription requirement, but does not explain use cases, exclusions, or trade-offs compared to other arena_* tools.

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

• arena_create_channelB
  3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It fails to disclose any behavioral traits such as permissions required, idempotency, default visibility, whether the channel is immediately available, or what the response contains. It merely restates parameter values already in 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.

  Conciseness4/5

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

  The description is very short, with three sentences or fragments. It front-loads the main action and lists key parameters. However, the visibility sentence is a fragment and 'the board itself' may confuse users by suggesting a different entity than a channel. Still, it is concise and not padded.

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

  Completeness3/5

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

  For a simple create tool with 3 parameters, the description covers purpose, visibility, and description format. It does not explain return values, errors, default visibility, or whether the operation can be undone. Given no annotations and no output schema, more behavioral context would be expected.

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

  Parameters2/5

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

  Schema coverage is only 33% (title has no description), so the description is expected to compensate. It mentions visibility enum values and that description supports Markdown, but both are already encoded in the schema. The required parameter 'title' is not explained at all. No additional semantic value is provided beyond schema.

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

  Purpose4/5

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

  The description clearly states the tool creates a channel, with the verb 'Create' and resource 'channel'. It is distinct from sibling tools like arena_update_channel and arena_get_channel, though it does not explicitly mention them. The visibility and description details are extra but not necessary for purpose.

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

  Usage Guidelines3/5

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

  Usage context is implied: use when you want to create a channel. No explicit comparison to sibling tools, no prerequisites, and no exclusions. The description does not clarify when one should prefer this over arena_update_channel or similarly named tools.

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

• arena_list_my_channelsB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It only states ownership and gives no details about pagination, return structure, or side effects (though it is a read operation). This is minimal disclosure, insufficient for the agent to fully understand behavior.

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

  Conciseness4/5

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

  The description is very short and front-loaded, containing only the essential scope without verbose filler. However, it is a sentence fragment rather than a complete statement, slightly reducing structure quality.

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

  Completeness3/5

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

  For a simple list tool with no output schema, the description states the core purpose but omits return format (e.g., array of channel objects) and pagination behavior. Without annotations or output schema, this leaves gaps, though the simple nature and optional parameters make it somewhat acceptable.

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

  Parameters2/5

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

  With 0% schema description coverage, the description does nothing to explain the 'per' and 'page' parameters. It doesn't mention that the list is paginated or how to use these parameters, leaving the agent to infer from the schema's min/max values. The description adds no meaning beyond the schema.

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

  Purpose4/5

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

  The description clearly identifies the resource (channels) and scope (owned by the authenticated user), distinguishing it from siblings like arena_get_channel or arena_create_channel. Although it lacks an explicit verb, the tool name/title supplies the 'list' action.

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

  Usage Guidelines4/5

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

  The description provides clear context that this tool is for listing channels owned by the authenticated user, which helps an agent choose it over arena_get_channel or arena_create_channel. However, it does not explicitly mention alternatives or exclusions, 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.

• arena_get_channelB
  3.3/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden of disclosure. 'Fetch' implies a read-only operation and 'a page of its blocks' signals pagination, but it does not explain error handling, rate limits, or what happens when the slug is not found. Some behavioral context is present, but it is incomplete.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence: 'Fetch a channel by slug with a page of its blocks.' Every word contributes meaning, and there is no redundancy.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description should provide more context about pagination behavior, return format, and possible errors. It only states the basic fetch operation, leaving significant gaps for an agent to understand the tool's full behavior.

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

  Parameters2/5

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

  The schema has 0% description coverage. The description clarifies that 'slug' is the channel identifier and that pagination is involved, but it does not explain the 'per' parameter or the semantics of 'page' (e.g., indexing, defaults). It adds minimal meaning beyond the raw schema.

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

  Purpose5/5

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

  The description uses the specific verb 'Fetch' with the resource 'channel' and identifies it by 'slug', while adding 'with a page of its blocks' to clarify the scope. This clearly distinguishes it from sibling tools like arena_create_channel or arena_list_my_channels.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the read-by-slug option or that arena_list_my_channels might be used for listing channels without a slug. No exclusions or alternative conditions are stated.

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

• arena_meA
  3.7/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of behavioral disclosure. It states what is returned but does not explicitly confirm that this is a read-only operation, does not mention authentication requirements beyond 'the token', and does not describe the structure of the profile or potential error cases. For a tool with no output schema, this lack of detail is a notable gap.

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

  Conciseness5/5

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

  The description is a single sentence that is concise and front-loaded. 'Profile of the account the token belongs to' immediately conveys the core purpose without any extraneous words. It is efficient and well-structured.

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

  Completeness3/5

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

  The tool is simple with no parameters and no output schema, so the description is the sole source of information about the return value. It does convey that the result is a profile, but it does not detail what fields the profile contains or any additional context about the response format. Given the minimal complexity, the description is somewhat sufficient but leaves room for interpretation regarding the profile structure.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for zero parameters is 4, and the description does not need to elaborate on parameter semantics since there are none. No further explanation is required.

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

  Purpose5/5

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

  The description clearly identifies what the tool returns: the profile of the account associated with the provided token. This is specific and distinguishes it from sibling tools that deal with channels, blocks, or search. The title reinforces the purpose.

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

  Usage Guidelines3/5

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

  The usage context is implied by the tool's name and description: it is the natural choice for retrieving the authenticated user's profile. However, no explicit guidance is given regarding when to use this tool versus alternatives, and no exclusions are stated. The sibling tools are all about different entities, so the choice is fairly obvious, but the description itself does not provide comparative guidance.

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

• arena_update_channelA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses two important behaviors: partial updates (only passed fields are changed) and clearing the description via an empty string. However, it omits other details such as authentication requirements, error handling, or return values, which would be expected for a mutation tool.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. It front-loads the core action and follows with the key behavioral rules, making it easy to parse quickly.

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

  Completeness4/5

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

  For a relatively simple update tool, the description covers the essential operation, partial-update behavior, and description clearing. No output schema or annotations are present, but the description is sufficient for an agent to invoke the tool correctly. Missing error/return details are minor in this context.

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

  Parameters4/5

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

  Schema coverage is only 50% (description and channel_slug have descriptions). The description compensates by explaining the partial-update semantics for all parameters and adding Markdown/clear behavior for description. It also mentions visibility explicitly, and the schema provides an enum for allowed values, so the additional semantics are valuable.

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

  Purpose5/5

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

  The description clearly states the action ('Update an existing board (channel)') and specifies the exact mutable fields (title, description Markdown, visibility). This distinguishes it from sibling tools like create_channel and get_channel, making the tool's purpose unambiguous.

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

  Usage Guidelines4/5

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

  It explicitly says 'existing board (channel)', implying it is for updates, not creation. The partial-update note ('Only the fields you pass are modified') provides clear context for when to use this over create_channel. It does not name alternative tools, but the context is sufficient for an agent to select it correctly.

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

• style_directivesA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that directives are mutable, current, layered on the durable skill, and change over time, which is useful context. However, it does not describe the response structure or edge cases (e.g., missing directives), leaving some ambiguity for a tool with no output schema.

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

  Conciseness5/5

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

  Two sentences, dense with relevant detail; every phrase adds value, with the key action and timing front-loaded.

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

  Completeness4/5

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

  For a zero-parameter read, the description is mostly complete: it states what is returned (mutating style directives), when to call it, and why. The lack of an output schema means a reader might want more detail on exact return format, but the description provides enough context to select and invoke the tool.

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

  Parameters4/5

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

  The tool has zero parameters, which is the baseline for a 4. The description avoids any unnecessary parameter discussion.

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

  Purpose5/5

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

  The description uses a specific verb ('Return') and identifies the resource ('current, mutable style directives'), clearly distinguishing this read operation from the write-focused sibling style_set_directives by emphasizing 'current-season focus' and 'recent preference updates' over the static skill.

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

  Usage Guidelines4/5

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

  It explicitly instructs to call this 'at the START of any styling task', providing clear timing and purpose (so recommendations reflect the latest direction). It does not list exclusions or alternatives, but the guidance is sufficient for a simple read tool.

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

• style_logA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral transparency burden. It discloses 'append-only' (no edits/deletes), 'durable', and that entries 'accumulate and get reviewed later', providing meaningful context about the tool's non-destructive, persistent nature. It does not mention auth, return values, or edge cases, but for an append-only log this is fairly transparent.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and includes useful examples without fluff. Every sentence earns its place, making it highly concise and well-structured.

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

  Completeness4/5

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

  The tool is simple (2 parameters, no output schema), and the description covers the what, when, and lifecycle (accumulate, review, promote). It does not describe return values or failure cases, but for an append-only logging tool, the core context is sufficiently complete. A slightly lower score would apply if there were hidden complexities.

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

  Parameters3/5

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

  Schema coverage is 100%, with both parameters (note and tags) having descriptions. The description adds illustrative examples of note content ('decided he's done with cropped hems', 'leaning into wider trousers') but does not add technical details beyond the schema. Baseline 3 is appropriate given the schema already covers semantics.

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

  Purpose5/5

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

  The description opens with 'Append a durable style learning or preference shift to the Style Journal (append-only)', clearly stating the verb (append), resource (Style Journal), and scope. It distinguishes itself from style_set_directives by explaining that entries 'accumulate and get reviewed later and promoted into the mens-style skill or the directives', implying it is for logging observations rather than setting directives directly.

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

  Usage Guidelines4/5

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

  It explicitly provides usage triggers: 'Use when Grayson states a new preference, dislike, or direction, or you notice a repeated pattern worth remembering', with concrete examples. However, it does not explicitly name sibling tools or state when not to use it, so while the guidance is clear, it stops short of fully explicit exclusions or alternatives.

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

• arena_add_blockA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the tool operates 'WITHOUT image validation', which is a key behavioral trait and potential limitation. However, it does not mention other aspects like whether the operation is reversible, idempotent, or what the response looks like. Still, the critical caveat is disclosed, so it earns a 4.

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

  Conciseness5/5

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

  The description is a single sentence that is concise, front-loaded, and contains no unnecessary words. Every phrase adds value: the action, the input types, the validation caveat, and the sibling tool reference. Excellent structure.

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

  Completeness3/5

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

  Given there are no annotations, no output schema, and 0% schema coverage, the description needs to be self-sufficient. It explains the core behavior and distinguishes from a sibling, but it omits details about the optional parameter, expected return value, and any error cases. For a simple tool, this is close to adequate but still has notable gaps, warranting a 3.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies that the 'value' parameter accepts a URL or Markdown text, which is essential. However, it does not explain the optional 'description' parameter or explicitly define 'channel_slug', though 'channel_slug' is fairly inferable from the name. The description adds some semantics but leaves gaps.

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

  Purpose5/5

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

  The description clearly states the action: 'Add a block from a URL or Markdown text'. It distinguishes from sibling tool arena_add_product by explicitly saying 'For products prefer arena_add_product'. The 'WITHOUT image validation' also clarifies a specific scope, making the purpose distinct and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: for raw blocks from URL or Markdown, and when not to use it by naming the alternative (arena_add_product) for products. This is a clear when/when-not statement with a specific alternative, exceeding the minimum.

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

• arena_remove_blockA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the key behavioral traits: 'Are.na can't delete a block entity (405)', 'deletes its CONNECTION to the board', and 'the block itself is not destroyed.' This is excellent transparency for a mutation tool, though it doesn't cover response behavior or error cases.

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

  Conciseness5/5

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

  The description is exactly three sentences, each serving a distinct purpose: state the action with an example, clarify the behavioral nuance, and provide parameter instructions. Every sentence earns its place with no filler.

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

  Completeness4/5

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

  Given the simplicity of the tool (2 params, no output schema, no annotations), the description is quite complete. It covers what, when, how, and the critical limitation. Minor omissions like return value or auth are not essential for this operation.

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

  Parameters4/5

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

  The schema already has 100% coverage for both params, so baseline is 3. The description adds valuable guidance by pointing out that block_id should come from arena_get_channel and that channel_slug is the board slug, reinforcing the schema and providing cross-tool context.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Remove a block from a channel', and provides a concrete use case ('a piece that no longer fits the brief'). It distinguishes itself from related operations by clarifying that it deletes the connection, not the block entity itself, which is critical given the tool name.

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

  Usage Guidelines4/5

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

  It gives clear context for when to use ('when a piece no longer fits the brief') and explicitly instructs how to invoke: 'Pass the board slug and the block_id from arena_get_channel.' While it doesn't name alternative tools, it implicitly differentiates from entity deletion by mentioning the 405 limitation.

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

• arena_add_productA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and excels: it discloses the image resolution pipeline, rejection criteria, web search fallback, and the 'NEVER rejects a product' guarantee. It also explains what happens when no image is found, covering edge cases comprehensively.

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

  Conciseness4/5

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

  The description is a single dense paragraph, front-loaded with the main purpose. It is somewhat long but every sentence contributes information about behavior or edge cases, with no redundancy.

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

  Completeness5/5

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

  Despite no output schema or annotations, the description is thoroughly complete for this tool's complexity. It covers the full workflow, failure modes, and guarantees, giving an agent all necessary context to invoke it correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context beyond the schema—e.g., how fallback_urls are used, the role of title as block title, and the behavior of the URL resolution. This elevates the value.

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

  Purpose5/5

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

  The description clearly states it adds a product to a channel with a real product photo, using specific verbs and a distinct resource. It differentiates from sibling tools like arena_add_block and arena_add_products by emphasizing image resolution and product-specific behavior.

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

  Usage Guidelines4/5

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

  The description provides clear context on how the tool operates, including image resolution and fallback behavior, but does not explicitly name alternatives or state when not to use it. The context is strong enough that an agent can infer when this tool is appropriate.

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

• arena_add_productsA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the fallback strategy (product photo, web-searched photo, link block), guarantees that no item is skipped, and describes the return value (how each item got its image: og/arena/search/link). This is robust disclosure for a mutation tool.

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

  Conciseness5/5

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

  The description is three sentences long and front-loaded with the key differentiator ('Batch version of arena_add_product'). Every sentence provides useful information: item structure, guarantee of image handling, never skipping, and return format. No filler or redundancy.

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

  Completeness5/5

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

  Given the moderate complexity (2 params, nested array, no output schema, no annotations), the description covers all essential aspects: what it does, the item format, the image-resolution behavior, the guarantee of never skipping, and the return value. The only omitted detail is the channel_slug parameter, which is trivial. It is sufficiently 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.

  Parameters4/5

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

  Although schema description coverage is 0%, the description compensates by detailing the item structure: each item contains url (required), and optional title, note, and fallback_urls. It does not explain channel_slug, but that parameter is self-explanatory. The description adds significant meaning beyond the raw schema for the complex nested items array.

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

  Purpose5/5

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

  The description clearly identifies this as the batch version of arena_add_product, with the explicit purpose of adding multiple products to a board. It names the sibling tool for differentiation and describes the core behavior: every item is added, with a guaranteed image via a fallback chain.

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

  Usage Guidelines4/5

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

  The description explicitly references arena_add_product, making it clear that this is the batch counterpart and thus should be used for multiple products. While it does not spell out 'use arena_add_product for a single product,' the batch distinction provides a clear context for selection. It does not mention other alternatives like arena_add_block, but the product-specific nature is evident.

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

• style_set_directivesA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the destructive/replacing nature ('Replace'), the requirement for a full body ('Pass the FULL new Markdown body, not a diff'), and the relationship to style_directives. It does not mention permissions or return values, but the key behavioral aspects are covered.

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

  Conciseness5/5

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

  The description is two sentences with no fluff. The first sentence states the action and object; the second provides usage guidance and alternatives. It is front-loaded and every word earns its place.

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

  Completeness5/5

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

  Given the simplicity (1 parameter, no output schema, no annotations), the description fully covers what the tool does, when to use it, how to format the input, and what not to use it for. It also references the sibling tool style_directives to establish context.

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

  Parameters4/5

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

  Schema coverage is 100% for the single parameter, so baseline is 3. The description adds crucial meaning beyond the schema by clarifying 'not a diff' and emphasizing 'FULL' body, which helps the agent understand the exact input format.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Replace the style directives document' — a specific verb with a specific resource. It also distinguishes this tool from siblings by referencing the mutable layer read by style_directives.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Use to update current-season focus or fold in a confirmed preference shift.' It also provides an exclusion: 'Durable rule changes belong in the mens-style skill via /style-review, not here.'

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