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

With no annotations, the description carries the transparency burden. It discloses that the tool stops before publish, returns a screenshot of the review page, and requires login. It also warns against estimating prices. It does not detail error states or whether the form is saved, but key behavior is 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?

Three sentences, front-loaded with the core action, and each sentence provides distinct value (action, photo guidance, return/confirmation, pricing rule, login prerequisite). No 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?

Given the tool has 7 parameters and no output schema, the description adequately explains the workflow (fill -> screenshot -> publish), the return value (screenshot), the per-item folder strategy, and the prerequisite login call. It is sufficient for an agent to select and sequence the tool 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?

Schema covers 57% of parameters with descriptions; the tool description adds actionable semantics for 'folder' vs 'photos' by labeling the normal use, and reinforces that 'price' must be seller-stated. Title, description, and condition are self-explanatory or enum-constrained, so no extra description 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 uses a specific verb ('Fill...form'), names the exact resource (Facebook Marketplace 'create item' form), and explicitly states the stopping point ('STOPPING before publish'), clearly distinguishing it from publish_listing and other 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?

It explicitly directs to the normal photo mode ('Point it at a folder...'), identifies when 'photos' should be used ('only for picking individual files'), and specifies the prerequisite ('Requires being logged in (call fb_login first)') and a rule about pricing without carrying it over from search_comps.

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 takes on full responsibility for behavioral disclosure. It reveals that the tool opens a real Facebook page, involves user interaction for 2FA, saves the session to a dedicated profile, and ensures the user types credentials only on Facebook's site. This is thorough and reassuringly 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?

The description is three sentences long, front-loaded with the primary action, and every sentence adds meaningful detail. There is no fluff or repetition, making it 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?

For a tool with no parameters and no output schema, the description covers all essential aspects: the action, the conditional behavior, the user interaction, and session persistence. It is complete for 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 tool has zero parameters, and the schema is trivially complete. The description adds no parameter details, but none are needed. Per the rubric, a baseline of 4 is appropriate for a zero-parameter tool.

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

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

The description starts with a specific verb and resource: 'Open the dedicated Facebook browser and sign in.' It also clarifies the tool's behavior when already signed in, making its purpose unmistakable. It implicitly distinguishes from siblings like fb_login_status by focusing on the login action itself.

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 clearly states when the tool is useful: first-time login or when a session is needed, and notes that it returns instantly if already signed in. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide when to call it.

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

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

No annotations are provided, so the description must carry the full burden of disclosing side effects. It states that the tool checks status and returns a path, but it does not explicitly mention that the operation is read-only and non-mutating. For a status check, this is implied but not explicitly stated, which is a modest gap.

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 primary action, and every word adds value. No filler or redundant information.

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

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

For a simple status check with no parameters and no output schema, the description provides the essential behavior (checks login) and return value (directory path). It does not explicitly mention prerequisites or use context, but the overall completeness is adequate for 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 tool has zero parameters, so the description naturally cannot add parameter meaning. Baseline for 0 params is 4, and there is no need for further param documentation.

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 uses a specific verb ('Check') and clearly defines the resource ('dedicated Facebook profile') and the action ('currently logged in'). It also differentiates itself from the sibling tool 'fb_login' by checking status rather than performing login, making the purpose unmistakable.

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?

While not explicitly stating when to use versus alternatives, the context is clear: it checks the login status of a dedicated Facebook profile, which is distinctly different from the sibling 'fb_login'. The absence of exclusions or alternative tool mentions is a minor gap, but the intended use case is unambiguous.

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

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

With no annotations, the description carries the full burden and discloses the tool's actions (open a page) and outputs (text and screenshot). It clearly implies a read-only inspection, though it does not mention authentication or session requirements explicitly.

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 concise, consisting of two sentences with no wasted words. It front-loads the action and adds the use case in the second sentence.

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

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

The description covers the tool's action, outputs, and a practical use case, which is sufficient given the tool has no parameters and no output schema. Minor gap: it doesn't state any prerequisites like being logged in, but sibling tools like fb_login imply this.

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 description does not need to explain parameter semantics. A baseline of 4 is appropriate for a no-parameter tool.

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

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

The description clearly states the tool opens the seller's 'Selling' page and returns current listings as text plus a screenshot. This specific verb+resource combination distinguishes it from siblings like publish_listing or create_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 description provides a clear use case: 'Useful to verify what is Active vs. under review.' This gives context for when to use the tool, though it does not explicitly name alternative tools or exclusion criteria.

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?

Since no annotations are provided, the description carries the full burden. It discloses the core side effect (publishing), the required state (review step), and the return value (URL). It does not mention reversibility or error cases, but for a zero-parameter publish action, this is sufficiently 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 concise sentences with no filler. The verb and object are front-loaded, and the additional information (precondition and return) is directly relevant. 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 zero-parameter tool with no output schema, the description is complete: it explains the action, when to call it, and what to expect. The reference to create_listing provides workflow context, making it fully usable for an AI agent.

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, making the schema trivially complete. There are no parameter meanings to add, so the baseline score of 4 applies.

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

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

The description clearly states a specific action ('Publish') with a precise target ('the listing currently on the review step') and explicitly references its originating tool, create_listing. This distinguishes it from all sibling tools and leaves no ambiguity about its function.

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

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

Provides an explicit precondition: 'Only call after the review screenshot has been confirmed.' This tells the agent exactly when to invoke the tool, and the reference to create_listing implies the correct workflow sequence. It effectively covers when-to-use and when-not-to-use.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals key details: folders starting with '_' or '.' are skipped, and a folder without subfolders is treated as a single item. This goes beyond a generic scan statement.

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 concise sentences, each adding essential information without redundancy. The purpose is front-loaded, followed by processing rules and output format.

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

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

Given the tool's simplicity, the description covers input, processing logic, and output format. No output schema exists, but the return format is explicitly stated as JSON, making the tool sufficiently complete for an agent to use.

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

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

The schema fully documents the single 'folder' parameter as an absolute path (100% coverage). The description adds meaningful semantic context by explaining how the folder is interpreted (immediate subfolders as items, skip rules), which complements the schema.

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

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

Uses a specific verb 'Scan' with a clear resource 'local folder for items to sell'. The description distinguishes itself from sibling tools like publish_listing or search_comps by focusing on the local scanning step.

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

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

Provides clear context on when to use this tool, describing the folder structure and rules. It does not explicitly name alternatives or exclusions, but the context is unambiguous and directly tied to the listing workflow.

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. It discloses key behaviors: returns aggregated price ranges, uses Facebook's fuzzy search which can skew results, is location-dependent, and requires being logged in. This is substantial context beyond a bare 'look up comps' statement, though it doesn't cover all edge cases like sort behavior.

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

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

The description is moderately sized but every sentence carries value: the purpose is front-loaded, and the warning about not using the numbers as recommendations is crucial for correct use. It is not overly verbose and is well-structured for an AI agent to grasp the essential constraints.

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 adequately explains the return format (min/p25/median/p75/max) and provides important context about location and login requirements. It does not explain how to use filters like sort_by or max_price, but these are optional and the core functionality is well covered.

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 only 50%, with sort_by, max_price, and min_price completely undocumented in the schema and not explained in the description. While the description mentions 'matching and loosely-matching listings' which hints at query semantics, it provides no additional meaning for the undocumented parameters, failing to compensate for the low coverage.

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

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

The description clearly states the tool's function: 'Look up what similar items are listed for' with the specific output of 'price ranges (min/p25/median/p75/max)'. It distinguishes from siblings by focusing on reference data rather than listing creation or management, and the phrase 'REFERENCE ONLY' reinforces its non-mutating nature.

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

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

Usage is implied through the description of looking up similar items, but there is no explicit statement of when to use this tool versus alternatives. The warning 'must never be used to set or suggest a price on their own' provides a strong exclusion, but no named alternatives or conditions are given; it's clear enough for a simple lookup tool.

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