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 states there are no side effects ('without submitting and without changing anything'), describes the exact return fields, and clarifies the response reflects the publish gate's own answer. It doesn't cover permissions or error behavior, but the core behavioral disclosure is strong.

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 dense sentences each serve a distinct purpose: purpose/safety, return shape, and invocation timing. Key information is front-loaded 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?

Covers purpose, non-mutation, return values, and when to invoke, while an output schema handles detailed field definitions. The only meaningful gap is parameter value semantics, which prevents a perfect score.

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, but it never defines item_type or item_id or their allowed values. The phrase 'this draft' hints at the target, but an agent still has to infer parameter meaning from elsewhere.

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

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

States a specific verb 'Dry-run submit' with a clear resource ('this draft') and explicitly contrasts with submit_for_review by noting no submission and no changes. An agent can immediately distinguish this tool from its 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?

Explicitly instructs the agent to call this tool before submit_for_review and after every fix, and positions it as the authority. It does not spell out when not to use it, so it falls just short of full explicit when/when-not 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 must carry the full behavioral disclosure. It explicitly states the draft is private until submitted, that 'nothing goes live from this tool,' and that submissions enter a moderation queue as pending_review. This is rich, honest transparency about side effects and lifecycle.

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, well-organized paragraph with three sentences: purpose, parameter constraints, and behavioral notes. It front-loads the most important information and contains no filler. Each 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 purpose, key parameters, lifecycle behavior, and moderation. Given that an output schema exists (though not shown here), the return values are likely structured. It misses a couple of minor parameter details but is otherwise comprehensive for a create tool.

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

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

Schema coverage is 0%, so the description must explain parameters itself. It covers item_type (values), name (max length), description (min length), and category (source). However, it omits price_cents (likely currency/semantics) and tags (array of strings), and doesn't mention default values. Partial compensation, but not complete.

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

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

The description opens with a specific verb and resource: 'Create a new draft listing owned by the seller and return its id and web editor URL.' This clearly states the action and the return value, and it distinguishes the tool from siblings like update_draft and submit_for_review by framing creation and handoff.

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: it tells the agent to use update_draft afterward for 'content fields,' and it points to list_categories for the category slug. It implies that this is the first step in a workflow, but it doesn't explicitly state when not to use this tool or name alternative creation entry points, so it falls 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, the description carries the behavioral burden. It says the operation is a read that returns markdown and discloses the optional side effect: writing to a path when provided. It does not detail overwrite/permission behavior, but the core behavior is transparent.

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 tight sentences with no filler. The core transformation is front-loaded, and the optional write behavior is appended without redundancy.

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

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

For a two-parameter tool with an output schema, the description is largely complete: it defines the artifact, the return value, and the optional side effect. Minor details like path overwrite semantics are absent, but the essential calling context is present.

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 0%, but the description maps item_id to 'one of the seller's skill listings' and explains path's effect: 'when `path` is given, also writes it there.' This adds meaning beyond the bare schema titles and compensates for the lack of schema descriptions.

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

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

The description opens with a specific verb ('Read') and resource ('one of the seller's skill listings') and clarifies the output format ('the SKILL.md it compiles to — the same file a buyer downloads'). This also distinguishes it from get_listing by focusing on the compiled markdown artifact rather than listing metadata.

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 use case clear: retrieve the compiled SKILL.md file that corresponds to a skill listing, not the listing's metadata or source draft. It does not explicitly name alternatives or exclusions, but the context strongly implies 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.

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly signals a read-only operation via 'Read' and provides meaningful context: 'as the web editor loads it' and 'every content field and the current status.' It does not mention error behavior or authentication, but for a simple get operation this is sufficient.

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, no filler. The primary action and scope are front-loaded in the first sentence, and the second sentence concisely clarifies the parameter that needs it. 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 simple two-parameter read tool with an output schema present, the description covers the essential context: what is returned, in what form, and the item_type values. Minor gaps such as ownership assumptions or error cases are low-risk for this operation.

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 directly explains the key parameter: 'item_type is prompt, persona or skill,' giving the agent the allowed values. The other parameter, item_id, is self-explanatory by name and the schema title, so the description effectively covers the semantic gap.

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

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

The description opens with a strong verb and specific resource: 'Read one of the seller's listings in full.' It also clarifies scope ('every content field and the current status') and differentiates itself from sibling list tools like list_my_listings by emphasizing a single listing with full editor-level detail.

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: use this when you need the complete editor view of a single listing rather than a summary. However, it does not explicitly name alternatives or state when not to use it, leaving some inference required.

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 result enters a moderation queue as pending_review, that nothing goes live, that malformed frontmatter is refused, and that a duplicate title produces a warning. It stops short of covering idempotency, permissions, or side effects on existing drafts, but the key behaviors 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 information-dense with no filler. It front-loads the primary purpose, then covers parameters, error behavior, return values, and moderation flow 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?

For a tool with 3 parameters and an output schema, the description is complete: it explains input requirements, validation rules, error handling, return content, and downstream moderation behavior. Nothing an agent needs to invoke this tool 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?

Schema description coverage is 0%, so the description must compensate, and it does: path is the file to read, category is a slug from list_categories, and tags optionally overrides the file's tags. Every parameter is given meaningful semantic context beyond the bare schema 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 clearly states a specific verb and resource: it creates a draft skill listing from a SKILL.md file on disk. It distinguishes itself from siblings like create_draft (manual creation) and export_skill_md (opposite direction) by specifying the file-based input source.

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 concrete usage context: it references list_categories for the category slug and explains that tags can override the file's tags. It also clarifies that this tool does not go live, implying submit_for_review is the follow-up, though it does not explicitly name alternatives.

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 behavioral burden. It discloses that the tool is public, requires no token, returns a defined shape, and imposes a contract on downstream tools. It does not mention ordering or stability guarantees, but these are minor for a simple category listing.

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, no filler. The purpose is front-loaded, followed by output structure, downstream usage, and authentication status. 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?

Given zero parameters, an output schema, and a simple public read-only purpose, the description is fully sufficient. It states what the tool returns, how the results should be consumed, and that no auth is required.

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 has zero parameters, so the baseline is 4. The description adds value beyond that by explaining that the returned slug is the expected value for the `category` field elsewhere, making the data contract explicit. No further parameter documentation is needed.

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: 'List the categories Sigrix accepts for a listing' and further defines the output as slug, name, and one-sentence description. This clearly distinguishes it from the sibling listing-management tools, which operate on listings rather than the category vocabulary.

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 downstream guidance: pass a returned slug as `category`, and notes that the publish gate refuses any other value. It also says no token is needed. While it does not name an alternative tool for this purpose, no sibling tool provides category data, so the usage 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, the description carries the behavioral burden. It discloses ordering (newest first), output fields per row, and the optional filter. It implies a read-only operation via 'List' but does not explicitly state lack of side effects or auth requirements. Still, it is transparent about core behavior.

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

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

Two concise sentences, front-loaded with the main purpose, then details. No redundant phrasing; every clause adds value.

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 an output schema, the description covers the purpose, ordering, output fields, and filtering. It does not explain error handling or pagination, but these are not critical for basic usage and the output schema fills structural 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 coverage is 0%, so the description must compensate. It explains the item_type parameter as an optional narrowing and earlier mentions the valid types (prompts, personas, skills), giving the agent a strong hint of allowed values. It does not formally list them as enums, but the context is sufficient.

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 ('List') and resource ('the seller's own listings'), and enumerates the item types (prompts, personas, skills) and statuses. It clearly distinguishes from siblings like list_categories (categories) and get_listing (single listing).

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 context is clear: use this to see the seller's own listings. It also mentions optional narrowing by item_type. However, it does not explicitly state when not to use it or point to alternatives, leaving some inference to the agent.

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

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

With no annotations, the description carries the behavioral burden and discloses the state transition to pending_review, moderator review, seller notification, and the gate refusal behavior. It also clarifies that the tool never publishes content, which is material side-effect information beyond the name/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 compact and front-loads the core purpose in the first sentence. The third sentence partly restates the pending_review outcome from the first, so there is minor redundancy, but overall every sentence 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?

Given the simple two-parameter shape and the presence of an output schema, the description covers process, side effects, and refusal behavior well. It is incomplete only in the parameter semantics area, which is significant enough to prevent a higher score.

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% and the description never mentions item_type or item_id. While 'Submit a draft' implies the item is a draft, the agent is not told what item_type values are valid, how item_type relates to item_id, or any format constraints, so the description does not compensate for the bare 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 action (submit a draft for moderation), the target resource (draft), and the resulting state (pending_review, moderation queue), which clearly distinguishes it from sibling draft creation/update/check tools. The 'Nothing goes live' clause further disambiguates it from any publish-style operation.

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 explicitly tells the agent to run check_draft first and explains that submissions with missing content are refused, giving a clear precondition. It does not enumerate exclusions for all siblings, but the moderation context makes the appropriate use obvious.

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 transparency burden. It discloses the moderation consequence ('Nothing goes live from this tool... enters Sigrix's moderation queue as pending_review'), the edit-blocking pending_review rule, and the response content ('the saved record and its publish_eligibility'). It does not discuss authorization, failure modes, or overwrite semantics, but the core behavioral traits are conveyed.

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 and then provides a dense but necessary field reference. The list of accepted keys is long and arguably could be simplified, but every section adds value given the zero-coverage schema. It is structured logically: purpose, field groupings, key/type list, then behavioral notes.

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 a complex nested `fields` object and no schema descriptions, the description is thorough: it covers allowed keys, types, item-type variations, moderation behavior, and response shape. Minor gaps exist, such as explicit valid values for `item_type` and whether partial field updates are allowed, but the overall picture is complete enough 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?

Schema coverage is 0%, so the description fully compensates with an exhaustive list of accepted field keys and their types. It also explains how field applicability varies by item_type (prompt, persona, skill, any). This turns an opaque generic 'fields' object into a well-specified parameter.

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

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

The description opens with a specific verb and resource: 'Update fields on a draft (or a listing returned for corrections).' It clearly distinguishes the tool from siblings by scoping it to drafts and moderated returns, and further elaborates the item types and field categories. An agent can immediately tell this is for editing existing draft state, not creating or submitting.

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 (updating drafts or listings in correction state) and states an explicit exclusion: 'A listing that is pending_review cannot be edited until a moderator returns it.' It does not explicitly name sibling alternatives like create_draft or submit_for_review, but the usage boundary is well implied by the sibling set.

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