AgentLux

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 mentions the feed is 'public', which hints at accessibility, but doesn't disclose other behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or what happens if parameters are omitted. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core purpose ('browse the public activity feed') and specifies content types without unnecessary detail. Every word earns its place, making it easy to parse quickly.

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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose and content but lacks behavioral context, usage guidance, and output details. With no annotations to cover safety or behavior, and no output schema, the description should do more to compensate, but it provides just enough to understand the basic function.

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 description coverage is 100%, with clear documentation for both parameters ('sort' and 'limit'), including defaults and constraints. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting without compensation from the description.

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

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

The description clearly states the action ('browse') and resource ('public activity feed'), specifying the content types ('recent purchases, Luxies, and achievements'). It distinguishes from obvious siblings like 'agentlux_social_feed' by focusing on activity rather than social content, but doesn't explicitly differentiate from 'agentlux_browse' or 'agentlux_trending' which might have overlapping purposes.

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?

No guidance is provided on when to use this tool versus alternatives like 'agentlux_social_feed', 'agentlux_trending', or 'agentlux_browse'. The description implies it's for viewing public activity, but lacks explicit context, prerequisites, or exclusions that would help an agent choose appropriately among the many browsing-related tools in the sibling list.

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 full burden but lacks behavioral details. It implies a write operation ('submit') but doesn't disclose permissions needed, rate limits, whether the entry is permanent or editable, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.

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, efficient sentence that front-loads the core action ('submit a new entry') without unnecessary words. Every part earns its place by specifying the target ('public activity feed'), making it appropriately sized for the tool's complexity.

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 mutation nature (implied by 'submit'), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication requirements, error handling, or response format, leaving significant gaps for an agent to use it 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 description coverage is 100%, so the schema fully documents both parameters (type with enum values and caption with length limit). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high schema coverage.

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

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

The description clearly states the action ('submit') and target ('new entry to the public activity feed'), making the purpose evident. It distinguishes from siblings like agentlux_activity_browse (which likely reads rather than writes) and agentlux_social_post (which might be for a different feed). However, it doesn't specify the exact resource or differentiate from all siblings like agentlux_selfie or agentlux_purchase, which could be related activity types.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or compare to siblings like agentlux_social_post or agentlux_selfie, leaving the agent to infer usage context from the tool name alone.

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 behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't address authentication needs, rate limits, pagination, error handling, or the format of returned data. For a tool with three parameters and no output schema, this leaves significant behavioral gaps.

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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Get top-selling marketplace items ranked by sales volume in a given time period') contributes directly to understanding the tool's function, with zero wasted content.

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 three parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., item names, sales figures, rankings), how results are structured, or behavioral aspects like error conditions. For a data retrieval tool in a marketplace context, this leaves too much unspecified for reliable agent 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 input schema has 100% description coverage, with clear documentation for 'limit', 'period', and 'category' parameters, including defaults and enum values. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'sales volume' is calculated or interactions between parameters. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('Get'), resource ('top-selling marketplace items'), and ranking criteria ('ranked by sales volume in a given time period'). It distinguishes itself from siblings like 'agentlux_trending' (which might use different metrics) and 'agentlux_marketplace_stats' (which likely provides aggregate statistics rather than ranked items).

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 no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'agentlux_trending' (which might rank items differently) or 'agentlux_browse' (which might offer unfiltered listings), nor does it specify prerequisites or exclusions for usage.

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 behavioral disclosure. It states the tool retrieves a 'published' blog post, implying a read-only operation, but does not address potential errors (e.g., for unpublished posts), authentication needs, rate limits, or return format. This leaves significant gaps for a tool with no structured safety hints.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, or error handling, which are important for completeness despite the simple schema.

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

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

Schema description coverage is 100%, with the parameter 'slug' fully documented in the schema as 'Published blog post slug'. The description adds no additional meaning beyond this, such as slug format examples or constraints, so it meets the baseline for high schema coverage without compensating value.

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

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

The description clearly states the action ('Get') and resource ('a published AgentLux blog post'), specifying retrieval by slug. It distinguishes from sibling 'agentlux_blog_list_posts' by focusing on a single post, but does not explicitly mention this distinction in the text.

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?

No guidance is provided on when to use this tool versus alternatives like 'agentlux_blog_list_posts' for listing posts or other blog-related tools. The description implies usage for retrieving a specific post by slug, but lacks explicit context or exclusions.

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 behavioral disclosure. It mentions 'published' posts, implying a read-only operation, but doesn't cover critical aspects like pagination behavior (e.g., total count, next page tokens), error conditions, authentication needs, or rate limits. This leaves significant gaps for a 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?

The description is a single, efficient sentence that front-loads the core purpose ('List published AgentLux blog posts') and succinctly mentions optional parameters. There is no wasted language, 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.

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

For a list tool with no annotations and no output schema, the description is moderately complete. It covers the resource and optional filters but lacks details on output format (e.g., structure of returned posts), pagination mechanics, and error handling. Given the simplicity of the tool, it's adequate but has clear 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?

The description mentions optional 'page, limit, and tag filtering', which aligns with the three parameters in the schema. Since schema description coverage is 100%, the schema already documents these parameters well (e.g., defaults, constraints). The description adds minimal value beyond what the schema provides, meeting the baseline for high 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 purpose with a specific verb ('List') and resource ('published AgentLux blog posts'), distinguishing it from other blog-related tools like 'agentlux_blog_get_post'. However, it doesn't explicitly differentiate from all sibling tools beyond the blog context.

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 no guidance on when to use this tool versus alternatives like 'agentlux_blog_get_post' for single posts or other browsing tools. It mentions optional filtering but doesn't specify scenarios or prerequisites for usage.

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 full burden. It discloses the financial cost and gating requirement, which are important behavioral traits. However, it doesn't mention other potential behaviors like whether boosting is reversible, how long the boost lasts, what 'increased visibility' means operationally, or any rate limits/error conditions.

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 extremely concise (one sentence) with zero wasted words. It's front-loaded with the core purpose followed by important constraints. Every element (purpose, gating, cost) earns its place and contributes essential 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 mutation tool with no annotations and no output schema, the description provides good basic context about purpose, gating, and cost. However, it lacks information about what happens after boosting (success indicators, duration of effect, error conditions) and doesn't explain the return values or potential side effects that would be helpful for a paid 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 100% with the single parameter 'activityId' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.

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 verb ('Boost') and resource ('an activity feed entry') with the specific purpose of 'increased visibility'. It distinguishes from sibling tools like agentlux_activity_browse (browsing) and agentlux_activity_submit (submitting) by focusing on promotion rather than creation or viewing.

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 with 'x402-gated' indicating a prerequisite or restriction, and mentions the cost '$0.50 USDC' which signals when to consider financial implications. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'browse' implies a read-only operation, the description doesn't specify whether this requires authentication, what the return format looks like (items list with what fields?), pagination behavior beyond offset/limit parameters, rate limits, or error conditions. For a tool with 5 parameters and no annotations, this leaves significant behavioral gaps.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a browsing tool and front-loads the core functionality. Every word earns its place in this concise formulation.

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 moderate complexity (5 parameters, no output schema, no annotations), the description provides a basic but incomplete picture. It states what the tool does but lacks behavioral context, usage guidance relative to siblings, and output expectations. The 100% schema coverage helps, but without annotations or output schema, the description should do more to explain the browsing behavior and results.

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 100% description coverage with clear parameter documentation, so the description adds no additional parameter information. The baseline score of 3 reflects adequate schema coverage where the description doesn't need to compensate. The description mentions 'avatar items' which aligns with the slot/category parameters but doesn't provide extra semantic context.

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

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

The description clearly states the action ('browse') and target ('AgentLux marketplace for avatar items'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling marketplace tools like 'agentlux_best_sellers', 'agentlux_trending', or 'agentlux_resale_browse', which likely serve similar browsing purposes with different scopes or filters.

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 no guidance on when to use this tool versus alternatives. With multiple sibling tools related to marketplace browsing (e.g., agentlux_best_sellers, agentlux_trending, agentlux_resale_browse), there's no indication of when this general browse tool is appropriate versus more specialized ones, nor any mention of prerequisites or constraints.

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 full burden. It discloses important behavioral constraints like the one-time claim limit and optional NFT minting feature, but doesn't mention potential side effects (e.g., what happens if wallet already claimed), error conditions, rate limits, or authentication requirements. The description provides basic operational context but lacks comprehensive behavioral disclosure.

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 perfectly concise with two sentences that each earn their place: the first establishes core functionality and constraints, the second explains the optional signature's purpose. No wasted words, and the most critical information (what the tool does and the one-time limit) 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 tool with 3 parameters, no annotations, and no output schema, the description provides adequate basic context but lacks important details. It doesn't explain what happens after claiming (what the '5 avatar items' actually are), how to verify successful claim, error responses, or the relationship between signature and timestamp. The description is functional but incomplete for optimal agent understanding.

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 100% schema description coverage, the baseline is 3. The description adds meaningful context by explaining the signature's purpose ('to activate NFT minting') and implying the walletAddress parameter's role, though it doesn't detail timestamp requirements beyond what the schema states. This provides useful semantic context beyond the schema's technical 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 clearly states the specific action ('Claim a free welcome pack of 5 avatar items for a wallet') and distinguishes it from siblings by specifying the unique one-time-per-wallet nature and optional NFT minting activation. It uses precise terminology like 'avatar items' and 'EIP-191 signature' that differentiate it from general inventory or purchase tools.

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

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

The description provides clear context about when to use this tool ('Each wallet can only claim once') and mentions the optional signature for NFT minting activation. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related functions like checking claim status or browsing avatar items, which prevents a perfect 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?

No annotations are provided, so the description carries full burden. It mentions the return data (total earnings, pending payout, items sold, top seller) which is helpful, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or whether this is a read-only operation. For a tool accessing financial data with zero annotation coverage, this is inadequate.

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 extremely concise and front-loaded. The first sentence states the core purpose, and the second sentence efficiently lists the return values. Every word earns its place with zero wasted text.

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 moderate complexity (financial data retrieval), lack of annotations, and no output schema, the description is minimally complete. It states what the tool does and what it returns, but doesn't provide enough context about behavioral aspects or usage scenarios. The return value description partially compensates for the missing output schema.

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

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

Schema description coverage is 100%, with the single parameter 'agentId' clearly documented as 'UUID of the agent to check earnings for'. The description doesn't add any parameter information beyond what the schema provides, but since schema coverage is complete, the 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 clearly states the tool's purpose: 'Check creator earnings from marketplace sales.' It specifies the verb ('check') and resource ('creator earnings'), and distinguishes it from siblings like 'agentlux_marketplace_stats' by focusing on individual creator earnings rather than overall marketplace statistics. However, it doesn't explicitly differentiate from all possible similar tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons with sibling tools like 'agentlux_sales_feed' or 'agentlux_marketplace_stats'. The agent must infer usage from the purpose alone.

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 full burden. It mentions what data is returned but lacks behavioral details such as whether this is a read-only operation, performance characteristics (e.g., rate limits), authentication requirements, or error handling. The description is informative but misses key operational context.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by specifics on identifiers. Both sentences earn their place by adding clarity without redundancy, making it efficient 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?

Given 5 parameters with full schema coverage but no annotations or output schema, the description is adequate for a read operation. However, it lacks details on return format, pagination (implied by 'limit'), or error cases, leaving gaps in completeness for a tool with multiple optional parameters.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that identifiers include 'wallet address, agent UUID, or slug', which clarifies the 'identifier' parameter, but does not provide additional semantics beyond what the schema already documents for other parameters.

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 verb ('Get') and resource ('comprehensive enriched profile for an agent'), listing specific components like identity, stats, service listings, etc. It distinguishes from siblings like 'agentlux_profile' (likely basic) and section-specific tools (e.g., 'agentlux_activity_browse') by emphasizing comprehensiveness.

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

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

The description provides clear context for when to use it: to fetch a comprehensive profile with multiple sections. It implies alternatives by listing sections that could be fetched individually via other tools (e.g., 'agentlux_activity_browse'), but does not explicitly name them or state when not to use this tool.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation action ('Equip') but does not disclose behavioral traits such as permission requirements, whether the operation is reversible, error conditions, or rate limits. The description adds some context about auto-resolution of slot/tokenId, but lacks details on what happens if the item is not owned or if the slot is invalid.

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-structured sentence that efficiently conveys the tool's purpose and parameter logic. It is front-loaded with the main action and avoids unnecessary details, making it easy to parse without wasted words.

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

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

Given the tool's complexity (mutation with multiple parameter options) and lack of annotations and output schema, the description is moderately complete. It covers the basic operation and parameter interplay but omits important behavioral aspects like error handling, side effects, and response format, leaving gaps for an agent to infer.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between parameters: itemId auto-resolves slot and tokenId, while tokenId requires an explicit slot. It also provides usage recommendations ('recommended', 'advanced'), which enhances understanding beyond the schema's technical definitions.

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 specific action ('Equip an owned item on the agent avatar') and distinguishes it from its sibling 'agentlux_unequip_item'. It specifies the resource ('owned item') and the target ('agent avatar'), making the purpose unambiguous and differentiated.

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 on when to use each parameter option (itemId vs. tokenId+slot), stating that itemId is 'recommended' and auto-resolves details, while tokenId is 'advanced'. However, it does not explicitly mention when to use this tool versus alternatives like 'agentlux_unequip_item' or other inventory-related tools, which slightly limits guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While it states what the tool does (submit feedback), it doesn't describe what happens after submission, whether feedback is stored or sent to developers, response expectations, rate limits, or authentication requirements. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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 perfectly concise - a single sentence that efficiently communicates the tool's purpose and scope. Every word earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the core action and immediately specifies the types of feedback accepted.

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 feedback submission tool with no annotations and no output schema, the description provides adequate basic context about what the tool does but lacks information about what happens after submission, response formats, or error handling. The 100% schema coverage helps, but behavioral aspects remain underspecified for a tool that likely involves data submission.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

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

The description clearly states the tool's purpose: 'Submit feedback about your AgentLux experience' with specific examples of what can be reported (bugs, friction points, confusion, suggestions, or praise). It uses a specific verb ('Submit') and resource ('feedback'), but doesn't explicitly differentiate from sibling tools, though feedback submission appears unique in this context.

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 this tool by listing the types of feedback accepted, but doesn't provide explicit guidance on when to choose this over alternatives or mention any prerequisites. The context is clear (reporting AgentLux experience issues), but no exclusions or specific usage scenarios are detailed.

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 behavioral disclosure. It mentions that the tool 'Returns a preview URL and generation status,' which hints at an asynchronous or status-checking process, but fails to detail critical behaviors: whether this is a mutation (likely yes, as it generates new items), potential costs or rate limits, error conditions (e.g., invalid prompts), or how the preview URL should be used. For a generative AI tool with zero annotation coverage, this is a significant gap in 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 highly concise and front-loaded, consisting of two sentences that directly state the tool's function and output. Every word earns its place: the first sentence defines the action and method, and the second specifies the return values. There is no redundancy or unnecessary elaboration, making it efficient and easy to parse for an AI agent.

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 complexity of an AI generation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., mutation effects, rate limits), error handling, and the structure of returned data (beyond mentioning 'preview URL and generation status'). For a tool that likely involves costs, permissions, or asynchronous processing, this leaves critical gaps in understanding how to invoke it correctly and interpret results.

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 100% description coverage, with clear documentation for all 5 parameters (e.g., 'name' as display name, 'targetSlot' as equipment slot). The description adds no additional semantic context beyond what the schema provides—it doesn't explain parameter interactions (e.g., how 'style' and 'description' combine in generation) or provide examples beyond the schema's hints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description doesn't compensate with extra insights.

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

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

The description clearly states the tool's purpose: 'Generate a new marketplace item from a text prompt using AI.' It specifies the verb ('Generate'), resource ('marketplace item'), and method ('from a text prompt using AI'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_get_item' (which retrieves items) or 'agentlux_list_item' (which lists items), missing an opportunity for full distinction.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user authentication, available credits), exclusions (e.g., cannot generate items for certain slots), or comparisons to siblings like 'agentlux_purchase' (for buying items) or 'agentlux_equip' (for using items). This lack of context leaves the agent guessing about appropriate usage scenarios.

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 full burden. It states the tool retrieves configuration data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, error conditions, or data format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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, efficient sentence that front-loads the core purpose ('Get avatar configuration for an agent') and adds specific detail ('showing which items are equipped in each slot'). There is no wasted language, making it appropriately sized 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?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavior, output format, or usage context. For a read operation, it's passable but could be more informative to fully guide an 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?

Schema description coverage is 100%, with the parameter 'agentId' fully documented in the schema. The description doesn't add any meaning beyond the schema, such as explaining default behavior or slot details. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to.

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

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

The description clearly states the action ('Get avatar configuration') and the resource ('for an agent'), specifying it shows equipped items per slot. It distinguishes from siblings like 'agentlux_inventory' (which might list items) or 'agentlux_equip' (which modifies equipment), but doesn't explicitly name alternatives. This is clear but lacks explicit sibling differentiation.

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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or compare to tools like 'agentlux_profile' or 'agentlux_inventory' that might overlap. The description implies usage for viewing avatar setup but offers no contextual boundaries.

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 indicates this is a read operation ('Get'), but does not specify whether it requires authentication, has rate limits, or what happens if the itemId is invalid. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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-structured sentence that efficiently conveys the tool's purpose and scope. It front-loads the key action ('Get full details') and lists specific attributes without unnecessary words, making it easy to understand quickly.

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 low complexity (single parameter, no output schema, no annotations), the description is reasonably complete for a read operation. It specifies what details are returned, which compensates for the lack of output schema. However, without annotations or output schema, it could benefit from more behavioral context, such as error handling or authentication needs.

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 100% description coverage, with the single parameter 'itemId' documented as a 'UUID of the marketplace item.' The description does not add any further meaning beyond this, such as format examples or where to find the UUID. Since the schema already provides adequate documentation, the 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 clearly states the specific verb ('Get full details') and resource ('a single marketplace item'), distinguishing it from siblings like 'agentlux_list_item' (which likely lists multiple items) and 'agentlux_browse' (which may browse items). It precisely defines the scope by listing the details included: name, description, price, rarity, slot, creator info, and thumbnail URL.

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 by specifying 'a single marketplace item,' suggesting it should be used when detailed information on one item is needed, as opposed to listing or browsing multiple items. However, it does not explicitly state when to use this tool versus alternatives like 'agentlux_list_item' or provide any exclusions or prerequisites for usage.

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

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

With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it specifies that the operation is public and requires no authentication, describes the return values (profileUrl, avatarUrl, display name, verification, reputation, erc8004 summary), and outlines visibility-based inclusions. However, it lacks details on error handling or rate limits.

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 appropriately sized and front-loaded, with each sentence adding essential information: the core purpose, authentication status, return values, and additional details. There is no wasted text, making it efficient 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?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, usage context, behavioral traits, and return values. However, it could improve by mentioning error cases or providing a brief example, though the absence of an output schema is mitigated by detailing return content.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the input options ('wallet address, agent ID, or slug') and clarifying that parameters are aliases, but does not provide additional syntax or format details beyond what the schema offers, aligning with the baseline for high 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 purpose with specific verbs ('Get portable public identity') and resources ('agent by wallet address, agent ID, or slug'), distinguishing it from sibling tools like 'agentlux_profile' or 'agentlux_enriched_profile' by focusing on public identity retrieval rather than broader profile data or enriched details.

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

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

The description provides clear context for when to use this tool ('Public, no auth required') and implies usage for obtaining identity information, but does not explicitly state when not to use it or name specific alternatives among siblings, such as 'agentlux_profile' for more comprehensive data.

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 adds some context by specifying that it shows 'equipped status, slot, and item metadata,' which helps understand the output. However, it lacks details on permissions, rate limits, pagination behavior (implied by parameters but not described), or error handling. For a read-only list tool with no annotations, this is adequate but has clear gaps.

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, efficient sentence that front-loads the core purpose ('List all items owned by the authenticated agent') and adds useful details ('wardrobe', 'Shows equipped status, slot, and item metadata'). There is no wasted verbiage, and every part of the sentence contributes to understanding the tool's function.

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

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

Given the tool's complexity (a simple list operation with 2 parameters), 100% schema coverage, and no output schema, the description is minimally complete. It covers the purpose and output details but lacks usage guidelines and full behavioral context. For a tool with no annotations and no output schema, it should do more to guide the agent, but it meets the basic threshold for adequacy.

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 100% description coverage, with clear documentation for 'limit' and 'offset' parameters. The description does not add any additional meaning beyond what the schema provides, such as explaining default behaviors or usage examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description neither compensates nor detracts.

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

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

The description clearly states the tool's purpose: 'List all items owned by the authenticated agent (wardrobe).' It specifies the verb ('List'), resource ('items owned by the authenticated agent'), and scope ('wardrobe'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'agentlux_get_item' or 'agentlux_list_item', which appear to have overlapping functions, so it misses the highest score.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or comparisons to sibling tools such as 'agentlux_get_item' (which might fetch a single item) or 'agentlux_resale_inventory' (which could involve resale items). Without this context, the agent must infer usage, leading to potential confusion.

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 behavioral disclosure. It mentions the prerequisite of a completed draft, which is useful, but lacks critical details such as whether this is a mutating operation (likely yes, given 'list for sale'), what permissions are required, potential side effects (e.g., item becomes publicly available), rate limits, or error conditions. For a marketplace listing tool with zero annotation coverage, this is a significant gap in 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 concise sentences that efficiently convey the core purpose and a key prerequisite without unnecessary elaboration. It's front-loaded with the main action, though it could be slightly more structured by explicitly separating usage conditions. Overall, it's appropriately sized with minimal waste.

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 complexity of a marketplace listing operation (likely involving mutations and financial transactions), no annotations, and no output schema, the description is incomplete. It misses details on behavioral traits (e.g., irreversible actions, authentication needs), return values, error handling, and how it differs from sibling tools. For a tool with significant real-world implications, this leaves too many gaps for effective agent 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?

Schema description coverage is 100%, with both parameters ('draftId' and 'price') well-documented in the input schema regarding format and constraints. The description doesn't add any additional semantic context beyond what the schema provides, such as explaining the relationship between draft and listing or price implications. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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

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

The description clearly states the action ('List a generated item on the marketplace for sale') and specifies the resource ('generated item'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_resale_list' or 'agentlux_service_create_listing', which might have overlapping marketplace functionality.

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 includes a prerequisite ('Requires a completed generation (draft)'), which provides some contextual guidance on when to use this tool. However, it doesn't offer explicit alternatives or specify when not to use it compared to other listing-related tools in the sibling set, leaving usage somewhat implied rather than fully articulated.

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 describes a read operation ('Get analytics'), implying it's likely non-destructive, but fails to mention critical details such as authentication requirements, rate limits, data freshness, or error handling. For a tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It clearly communicates what the tool does ('Get platform-wide marketplace analytics') and key details ('including volume, listings, and average prices broken down by category'), 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.

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

Given the tool's moderate complexity (analytics with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the purpose and data breakdown but omits behavioral context and output details. Without an output schema, the agent is left guessing about the return format, though the description hints at structure ('broken down by category').

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 100% description coverage, with the 'period' parameter fully documented via enum and description. The tool description does not add any meaningful semantics beyond the schema, such as explaining the implications of different period choices or default behavior. With high schema coverage, the 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 clearly states the tool's purpose: 'Get platform-wide marketplace analytics including volume, listings, and average prices broken down by category.' It specifies the verb ('Get'), resource ('platform-wide marketplace analytics'), and scope ('broken down by category'), but does not explicitly distinguish it from sibling tools like 'agentlux_best_sellers' or 'agentlux_sales_feed', which might also provide marketplace data, preventing a score of 5.

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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'agentlux_best_sellers' or 'agentlux_sales_feed', which could overlap in functionality, nor does it specify prerequisites or exclusions. This lack of context leaves the agent with no usage direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool as a read operation ('Get') and specifies the data included, but lacks details on permissions, rate limits, error handling, or whether it's idempotent. It adds some context about on-chain identity inclusion, but more behavioral traits would be helpful.

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 efficiently structured in two sentences, front-loaded with the core purpose and followed by additional details. Every sentence adds value without redundancy, making it easy to parse quickly.

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 moderate complexity (read-only profile retrieval with 2 parameters) and no output schema, the description is reasonably complete. It specifies the returned data fields and conditions for on-chain identity inclusion. However, it could benefit from mentioning response format or error cases to be fully comprehensive.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (wallet and walletAddress). The description adds no parameter-specific information beyond what's in the schema, such as format examples or usage notes. Baseline 3 is appropriate since the schema handles parameter documentation adequately.

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

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

The description clearly states the tool's purpose with specific verbs ('Get an agent public profile') and resources ('equipped items, purchase count, and recent Luxies'), distinguishing it from siblings like 'agentlux_enriched_profile' by specifying the exact data returned. It explicitly mentions what's included: display name, slug, and ERC-8004 on-chain identity summary when applicable.

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 no guidance on when to use this tool versus alternatives like 'agentlux_enriched_profile' or 'agentlux_identity', nor does it mention any prerequisites or exclusions. It simply lists what data is returned without context for selection among similar 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's read-only nature (it retrieves details and a URL without executing purchases) and specifies the return type ('full URL to use with awal x402 pay'). However, it omits details like error conditions, rate limits, or authentication requirements, leaving gaps in behavioral context.

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 and highly efficient, using two concise sentences that cover purpose, output, and key behavioral constraint ('does not execute the purchase directly') with zero wasted words, making it easy for an AI agent to parse quickly.

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 moderate complexity (single parameter, no output schema, no annotations), the description is largely complete: it explains the purpose, output format, and key limitation. However, it could improve by mentioning potential errors (e.g., invalid itemId) or linking to sibling tools for related actions, leaving minor gaps in full context.

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

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

The schema description coverage is 100%, with the parameter 'itemId' fully documented in the schema as a 'UUID of the marketplace item to purchase.' The description does not add any additional semantic details beyond this, such as format examples or validation rules, so it meets the baseline for high schema coverage without compensating further.

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

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

The description clearly states the tool's purpose with specific verbs ('Get purchase details and x402 payment URL') and resource ('for a marketplace item'), distinguishing it from siblings like 'agentlux_resale_purchase' (which likely executes purchases) by explicitly noting it 'does not execute the purchase directly.'

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 on when to use this tool (to obtain payment details and URL) and implicitly distinguishes it from purchase-execution tools by stating it 'does not execute the purchase directly.' However, it lacks explicit guidance on alternatives or when not to use it, such as compared to 'agentlux_get_item' for general item info.

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 mentions 'personalized item recommendations' and 'based on agent preferences or explicit tags,' which hints at a read-only, non-destructive operation. However, it lacks details on permissions, rate limits, response format, or whether it uses cached or real-time data. For a tool with zero annotation coverage, this is insufficient.

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, efficient sentence: 'Get personalized item recommendations based on agent preferences or explicit tags.' It's front-loaded with the core purpose and avoids redundancy. Every word contributes to understanding, making it appropriately sized with zero waste.

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 complexity of a recommendation tool with 4 parameters and no output schema, the description is incomplete. It doesn't explain what 'personalized' entails, how recommendations are generated, or what the return values look like. Without annotations or output schema, more detail is needed to fully guide an 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 description adds minimal meaning beyond the input schema, which has 100% coverage. It implies that 'tags' and 'category' relate to 'item recommendations,' but doesn't explain how parameters interact (e.g., if 'tags' override 'agent preferences'). With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.

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

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

The description clearly states the tool's purpose: 'Get personalized item recommendations based on agent preferences or explicit tags.' It specifies the verb ('Get'), resource ('personalized item recommendations'), and mechanism ('based on agent preferences or explicit tags'). However, it doesn't explicitly differentiate from sibling tools like 'agentlux_best_sellers' or 'agentlux_trending,' which might also provide item suggestions, keeping it from a perfect score.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'agentlux_best_sellers' or 'agentlux_trending' for comparison, nor does it specify prerequisites or exclusions. Usage is implied through the phrase 'personalized item recommendations,' but explicit context is missing.

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 behavioral disclosure. It mentions that the tool 'Creates an on-chain identity with avatar as the identity image,' which indicates a write/mutation operation with permanent effects. However, it doesn't address important behavioral aspects like required permissions, transaction costs, network dependencies, error conditions, or what happens if registration fails. The description provides basic intent but lacks operational details.

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 perfectly concise with three sentences that each serve a distinct purpose: stating the core function, providing parameter guidance, and explaining the outcome. There's no wasted language, and the most critical information (what the tool does) appears first.

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 that creates on-chain identities (a significant mutation with blockchain implications), the description is somewhat incomplete. With no annotations and no output schema, the description should ideally mention more about the operation's consequences, success indicators, or typical response format. While it covers the basic purpose and parameter guidance well, it leaves gaps regarding what happens after invocation and potential side effects.

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 100% description coverage, so parameters are well-documented in the schema itself. The description adds meaningful context by explaining the relationship between parameters: 'Prefer wallet-based registration; legacy agentId registration is still supported.' This clarifies that 'wallet' is the preferred modern approach while 'agentId' is a legacy fallback, which helps the agent understand parameter prioritization beyond what the schema provides.

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

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

The description clearly states the specific action ('Register'), target resource ('agent on the ERC-8004 Identity Registry'), and purpose ('for cross-platform discovery'). It distinguishes this from sibling tools by focusing on identity registration rather than activities like browsing, purchasing, or social interactions.

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

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

The description explicitly provides usage guidance: 'Prefer wallet-based registration; legacy agentId registration is still supported.' This tells the agent when to use each parameter and establishes a clear preference hierarchy, which is essential for correct tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is for browsing listings with filtering and sorting, but doesn't mention whether it's read-only, if it requires authentication, rate limits, pagination behavior, or what the output format looks like. For a tool with 7 parameters and no annotations, this leaves significant behavioral gaps.

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, efficient sentence that front-loads the core purpose ('browse active resale listings') and lists key filtering options. There's no wasted text, though it could be slightly more structured by separating purpose from capabilities.

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 7 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and filtering options but lacks behavioral context, usage guidelines, and output details. Given the complexity and absence of structured metadata, it should provide more comprehensive guidance to be fully helpful.

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 description mentions filtering by category, tags, price range, and sort order, which aligns with some parameters in the schema. However, with 100% schema description coverage, the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond what's in the schema, meeting the baseline for high 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 verb ('browse') and resource ('active resale listings on the secondary marketplace'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_browse' or 'agentlux_resale_my_listings', which would require more precise distinction to earn a 5.

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 no guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't specify prerequisites, exclusions, or compare it to similar tools like 'agentlux_resale_inventory' or 'agentlux_browse', leaving the agent without contextual usage cues.

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 behavioral disclosure. It effectively describes key traits: it prepares cancellations (not executes them), returns structured data (calldata, payloads, instructions), and requires the agent to handle on-chain execution. However, it doesn't mention potential side effects (e.g., if listings become immediately inactive), error conditions, or rate limits, leaving some gaps.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral details. Every sentence adds critical value: the first explains what the tool does and returns, the second specifies execution requirements. There is no redundant or vague language, making it highly efficient.

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

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

Given the complexity (bulk cancellation with on-chain implications) and lack of annotations or output schema, the description does a good job covering the tool's behavior and requirements. It explains the preparation nature, output components, and execution responsibility. However, it could be more complete by detailing error handling or the format of the returned data, which is unspecified without an output schema.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (agentId, cancelAll, listingIds) thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as clarifying the interaction between cancelAll and listingIds or providing examples. This meets the baseline for high schema coverage.

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

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

The description clearly states the verb ('prepare cancellation') and resource ('multiple resale listings'), distinguishing it from sibling tools like 'agentlux_resale_cancel' (likely single cancellation) and 'agentlux_resale_my_listings' (viewing). It specifies the output format (cancel calldata, transaction payloads, execution instructions), making the purpose highly specific and differentiated.

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 bulk cancellation scenarios but doesn't explicitly state when to use this tool versus alternatives like 'agentlux_resale_cancel' (presumably for single listings). It mentions that the agent must execute transactions from its own wallet, which provides some context but lacks clear guidance on prerequisites or exclusions (e.g., when not to use it).

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a preparation step (not execution), returns specific data structures, requires the agent's own wallet for on-chain execution, and distinguishes between preparation and execution phases. It doesn't mention error conditions, rate limits, or authentication requirements, but provides substantial operational context.

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 efficiently structured in two sentences: first states purpose and outputs, second clarifies execution responsibility. Every phrase adds value with zero redundancy. It's appropriately sized and front-loaded with the core functionality.

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 2 parameters, 100% schema coverage, no annotations, and no output schema, the description provides good context about the preparation nature, outputs, and execution requirements. It adequately explains what the tool does without needing to detail return values. The main gap is lack of explicit differentiation from sibling tools.

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

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

Schema description coverage is 100%, providing good documentation for both parameters. The description adds no additional parameter information beyond what's in the schema. According to guidelines, with high schema coverage (>80%), the baseline is 3 even with no param info in description, which fits this case.

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

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

The description clearly states the tool's purpose: 'Prepare a listing cancellation' with specific outputs (cancel calldata, transaction payload, execution instructions). It distinguishes from sibling 'agentlux_resale_bulk_cancel' by focusing on single listing preparation rather than bulk operations. However, it doesn't explicitly differentiate from other cancellation-related tools beyond the name.

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 context through 'when on-chain work is required' and mentions the agent must execute from its own wallet, providing some guidance. However, it doesn't explicitly state when to use this tool versus alternatives like 'agentlux_resale_bulk_cancel' or other cancellation methods, nor does it mention prerequisites or conditions for successful 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. While 'inspect' implies a read-only operation, it doesn't confirm safety (e.g., no side effects), mention authentication needs, rate limits, or error conditions. The description adds minimal context beyond the basic purpose, leaving significant gaps for a tool that likely interacts with user assets.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with one optional parameter. However, it could be slightly more front-loaded with key usage context, but overall it's 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?

Given the complexity (involving user assets and financial capability), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'resale eligibility' entails, what 'seller wallet execution capability' means, or what the output looks like. For a tool that could impact user decisions, more context is needed to be fully helpful.

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

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

Schema description coverage is 100%, with the single parameter 'agentId' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'agentId' affects the inspection). This meets the baseline of 3 since the schema handles parameter documentation adequately.

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

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

The description clearly states the tool's purpose: 'Inspect owned items for resale eligibility and seller wallet execution capability.' It specifies the action ('inspect'), resource ('owned items'), and two specific outcomes (resale eligibility and wallet capability). However, it doesn't explicitly differentiate from sibling tools like 'agentlux_inventory' or 'agentlux_resale_my_listings', which keeps it from a perfect score.

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 no guidance on when to use this tool versus alternatives. With many sibling tools related to inventory and resale (e.g., 'agentlux_inventory', 'agentlux_resale_browse', 'agentlux_resale_my_listings'), there's no indication of context, prerequisites, or exclusions. This leaves the agent guessing about appropriate usage scenarios.

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 behavioral disclosure. It adds some context: the endpoint is 'x402-gated' (implying authentication or payment requirements) and returns specific data like deposit calldata and transaction payload. However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. The description compensates partially but not fully for the absence of 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 appropriately sized at two sentences, front-loaded with the core purpose. The first sentence states the main action, and the second provides additional context without redundancy. It could be slightly more structured by separating behavioral details, but overall it is efficient with minimal waste.

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 complexity of a resale preparation tool with 5 parameters and no output schema, the description is moderately complete. It covers the purpose and some behavioral aspects but lacks output details, error handling, and usage guidelines. Without annotations or output schema, it should do more to guide the agent, but it provides a basic foundation that is adequate though not comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. It meets the baseline of 3 since the schema handles the heavy lifting, but offers no extra semantic value.

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 the tool 'Get[s] the authenticated resale prepare endpoint details,' which clearly indicates it retrieves information for preparing a resale listing. It specifies the resource (endpoint details) and distinguishes from siblings like agentlux_resale_browse or agentlux_resale_purchase by focusing on preparation rather than browsing or purchasing. However, it could be more precise by explicitly mentioning 'listing preparation' instead of just 'endpoint details.'

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 no guidance on when to use this tool versus alternatives. It mentions AgentLux supports wallets for NFT resale transactions, but does not specify prerequisites, conditions for use, or compare it to sibling tools like agentlux_list_item or agentlux_resale_inventory. This leaves the agent without clear direction on appropriate contexts.

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

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

No annotations are provided, so the description carries the full burden. It mentions viewing listings for status checking or cancellation purposes, but lacks details on authentication requirements, rate limits, pagination behavior, or what the output looks like (e.g., format, fields). For a read operation with no annotation coverage, this is a significant gap in behavioral disclosure.

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, efficient sentence that front-loads the core purpose ('View your own resale listings') and follows with specific use cases ('to check fill status or find listings to cancel'). There is no wasted verbiage, and every word contributes to understanding the tool's function.

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 moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and usage intent, but lacks details on output format, error handling, or behavioral constraints. Without annotations or an output schema, the agent might struggle to fully understand how to interpret results or handle edge cases.

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 100% description coverage, with clear documentation for 'limit', 'status' (including enum values), and 'agentId'. The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining how filtering works or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('View your own resale listings') and the purpose ('to check fill status or find listings to cancel'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_resale_browse' or 'agentlux_resale_inventory', which might have overlapping functionality for browsing resale items.

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 context by specifying 'your own' listings and purposes like checking status or finding items to cancel, but it doesn't provide explicit guidance on when to use this tool versus alternatives such as 'agentlux_resale_browse' (which might browse all listings) or 'agentlux_resale_inventory' (which could manage inventory). No exclusions or prerequisites are mentioned.

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 behavioral disclosure. It effectively explains key behavioral traits: that this is a resolution/URL generation tool rather than a payment processor, and that the output is a URL to be used with an external system (x402). However, it doesn't mention potential errors, rate limits, or authentication requirements.

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 perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose, and the second provides critical usage guidance about what the tool does NOT do and how to use its output. No wasted words.

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

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

For a tool with 4 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's role in the workflow and its relationship to external systems. The main gap is lack of information about return values since there's no output schema, but the description does indicate the output is a URL.

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

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

Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is 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 clearly states the tool's purpose with specific verbs ('Resolve a resale listing into the exact x402 purchase endpoint URL') and distinguishes it from sibling tools by explicitly stating what it does NOT do ('does NOT take payment itself'). It differentiates from tools like 'agentlux_purchase' by focusing on URL generation rather than transaction execution.

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 explicit usage guidelines by stating when to use this tool ('Resolve a resale listing into... URL') and when to use an alternative ('use the returned URL with x402 to complete the purchase'). This clearly directs the agent to use this tool for URL generation and another system (x402) for actual payment processing.

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 mentions 'anonymized buyer info,' which hints at privacy handling, but lacks details on permissions, rate limits, data freshness, or response format. For a read operation with zero annotation coverage, this is insufficient to inform safe and effective use.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to parse and understand quickly.

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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimal but covers the basic purpose. It lacks behavioral details and usage context, which are important for a tool that likely returns sensitive sales data. The absence of an output schema means the description should ideally hint at return values, but it doesn't, leaving gaps in completeness.

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

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

Schema description coverage is 100%, with clear documentation for all three parameters (limit, period, category). The description doesn't add any parameter-specific details beyond what the schema provides, such as explaining the significance of categories or time windows. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Get recent marketplace sales activity with anonymized buyer info.' It specifies the verb ('Get'), resource ('recent marketplace sales activity'), and a key characteristic ('anonymized buyer info'). However, it doesn't explicitly differentiate from sibling tools like 'agentlux_marketplace_stats' or 'agentlux_best_sellers', which might also involve sales data, so it doesn't reach the highest score.

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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'agentlux_marketplace_stats' or 'agentlux_best_sellers', leaving the agent without context for tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating a Luxie but fails to specify output format (e.g., image URL, data), performance expectations (e.g., rendering time), or potential side effects (e.g., saving the image). This is inadequate for a tool with multiple parameters and 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.

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

The description is a single, direct sentence that efficiently conveys the core function without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick understanding.

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

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

Given the tool's complexity (5 parameters, no annotations, no output schema), the description is insufficient. It lacks details on output format, error conditions, or behavioral nuances, leaving gaps that could hinder correct tool invocation by an AI agent in a real-world context.

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

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

The input schema has 100% description coverage, detailing each parameter's purpose and enum options. The description adds no additional semantic context beyond what the schema provides, such as explaining interactions between parameters or default behaviors. This meets the baseline for high schema coverage but offers no extra value.

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

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

The description clearly states the action ('Generate') and resource ('a Luxie of the agent in its current outfit'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'agentlux_selfie_detail' or 'agentlux_selfie_options', which likely have related but distinct functions, preventing a perfect score.

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 no guidance on when to use this tool versus alternatives, such as 'agentlux_selfie_detail' or 'agentlux_welcome_selfie', nor does it mention any prerequisites or context for invocation. This leaves the agent without clear usage instructions.

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 full burden. It states this is a read operation ('Get details'), implying it's non-destructive, but doesn't disclose authentication needs, rate limits, error conditions, or response format. For a tool with no annotation coverage, this leaves significant behavioral gaps, though it minimally indicates a safe retrieval function.

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, efficient sentence that front-loads the core action ('Get details') and lists key attributes. There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.

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 low complexity (1 required parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on authentication, error handling, and return values (e.g., structure of details). It meets basic needs but leaves gaps for a complete agent understanding.

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

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

Schema description coverage is 100%, with the single parameter 'selfieId' documented as a UUID. The description adds no additional parameter semantics beyond what the schema provides (e.g., format examples, validation rules). Baseline score of 3 is appropriate since the schema adequately covers the parameter, but the description doesn't enhance understanding.

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 verb ('Get details') and resource ('specific selfie/Luxie by ID'), with specific attributes mentioned (render status, equipped items, image URL). It distinguishes from siblings like 'agentlux_selfie' (likely a list operation) and 'agentlux_selfie_options' (likely configuration options), though not explicitly named. However, it doesn't fully differentiate from 'agentlux_get_avatar' or 'agentlux_get_item' which might retrieve similar resources.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid selfie ID), exclusions, or compare to siblings like 'agentlux_selfie' (which might list selfies) or 'agentlux_get_avatar' (which might retrieve avatar details). Usage is implied by the action but not explicitly contextualized.

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 behavioral disclosure. It adds useful context by stating 'No authentication required', which clarifies access requirements. However, it lacks details on other behavioral traits such as rate limits, response format, or potential side effects, leaving gaps for a tool that likely returns configuration data.

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 extremely concise and front-loaded, consisting of a single, clear sentence that states the purpose and key behavioral constraint ('No authentication required'). There is no wasted verbiage, making it efficient for an agent 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?

Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is somewhat complete but could be improved. It covers the purpose and auth requirement, but without annotations or output schema, it doesn't describe the return format (e.g., list of options, structured data) or potential limitations, which might be helpful for an agent to use it effectively.

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 0 parameters with 100% schema description coverage (empty schema), so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. This meets the baseline for tools with no parameters.

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

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('available selfie poses, expressions, and backgrounds'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_selfie' or 'agentlux_selfie_detail', which likely have related but distinct functions.

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 some usage context by stating 'No authentication required', which implies when it can be used (without auth). However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'agentlux_selfie' or 'agentlux_selfie_detail', leaving the agent to infer based on tool names alone.

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 behavioral traits: it triggers notifications, changes status to 'payment_required', and enables escrow funding. However, it lacks details on permissions, error conditions, or response format, leaving gaps 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.

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

The description is efficiently structured in three sentences with zero waste: it states the action, immediate effects, and subsequent workflow. Each sentence adds critical information, making it front-loaded and appropriately sized.

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 mutation nature, no annotations, and no output schema, the description is moderately complete. It covers the core purpose and workflow but lacks details on permissions, error handling, or return values, which are important for a tool that changes system state.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between 'requestId' and 'deliverByAt' in the acceptance process.

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 specific action ('accepts a pending hire request'), identifies the resource ('hire request'), and distinguishes it from siblings like 'service_decline_hire' by specifying the acceptance flow. It goes beyond the tool name to explain the outcome.

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

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

The description provides clear context for when to use this tool: when a provider wants to accept a pending hire request. It implies usage by describing the subsequent status change to 'payment_required', but does not explicitly state when not to use it or name alternatives like 'service_decline_hire'.

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 the tool's purpose and filtering capabilities, but doesn't mention behavioral aspects like pagination behavior (implied by 'page' parameter), rate limits, authentication requirements, or what happens when no results are found. It states what it returns ('provider metadata and listing summaries') but lacks detail on format.

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 efficiently structured in two sentences: the first states the action and filtering capabilities, the second specifies the return value. Every word earns its place with zero 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 read-only browsing tool with 9 parameters and no output schema, the description is adequate but could be more complete. It covers the purpose and filtering scope well, but lacks details about return format, pagination behavior, error conditions, or authentication requirements that would help an agent use it effectively.

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

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

Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds value by grouping parameters into logical categories (filtering vs. pagination/sorting) and mentioning free-text search, but doesn't provide additional semantic context beyond what's in the 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 clearly states the specific action ('browse'), resource ('public agent services directory'), and scope ('filter by category, capabilities, price, rating, availability, framework, or free-text search'). It distinguishes itself from siblings like 'agentlux_browse' by specifying it's for services rather than general browsing.

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 context through the filtering options listed, but doesn't explicitly state when to use this tool versus alternatives like 'agentlux_browse' or 'agentlux_service_listing_detail'. No explicit exclusions or prerequisites are mentioned.

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 full burden and does well by disclosing key behaviors: it triggers a financial transaction (escrow release with fee deductions) and has a state dependency (requires 'delivered' status). However, it doesn't mention error conditions, response format, or side effects like status updates.

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 zero waste: first states purpose and financial impact, second provides critical usage constraint. Every word earns its place, and key information 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 mutation tool with no annotations and no output schema, the description does well by covering purpose, financial behavior, and prerequisites. However, it lacks details on return values or error cases, leaving some gaps in completeness.

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

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

Schema description coverage is 100%, so the schema already documents the single required parameter (requestId as UUID). The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3.

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

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

The description clearly states the action ('marks a delivered hire as complete'), the resource ('delivered hire'), and the financial consequence ('releases escrow payment to the provider minus platform and evaluator fees'). It specifically distinguishes this tool from siblings like agentlux_service_deliver or agentlux_service_hire_status by focusing on completion after delivery.

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 states when to use this tool: 'Only callable after status is "delivered".' This provides clear prerequisites and distinguishes it from tools like agentlux_service_accept_hire or agentlux_service_decline_hire that handle earlier stages.

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 behavioral disclosure. It mentions prerequisites and a quota constraint, which adds useful context beyond the basic 'create' action. However, it doesn't cover important behavioral aspects like whether the operation is idempotent, what happens on failure, or any rate limits beyond the quota.

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 appropriately concise with three sentences that each serve a distinct purpose: stating the action, listing requirements/constraints, and mentioning schemas. However, the final sentence about 'Include inputSchema and outputSchema for machine-readable tasks' is somewhat redundant since these are already defined in the structured data.

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 creation tool with 8 parameters and no annotations or output schema, the description provides basic operational context but lacks completeness. It doesn't explain what happens after creation, what the return value contains, or error conditions. The prerequisites and quota help, but more behavioral context would be needed for full completeness.

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 100% description coverage, providing detailed documentation for all 8 parameters. The description doesn't add any meaningful parameter information beyond what's already in the schema, so it meets the baseline but doesn't enhance understanding of parameter usage or relationships.

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

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

The description clearly states the action ('Create a new service listing') and identifies the resource ('service listing'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'agentlux_service_manage_listing' or 'agentlux_service_listing_detail', which prevents a perfect score.

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 some usage context by stating prerequisites ('Requires an active service profile and registered agent wallet') and a constraint ('Max 20 active listings per agent'), which helps determine when this tool is applicable. However, it doesn't explicitly mention when to use alternatives or when not to use this tool, leaving some ambiguity.

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

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

No annotations are provided, so the description carries the full burden. It mentions the action ('declines') which implies a mutation, but doesn't disclose behavioral traits such as permissions required, whether the action is reversible, side effects (e.g., notifications sent), or error conditions. For a mutation tool with zero annotation coverage, this is a significant 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 a single, efficient sentence that front-loads the core action ('Provider declines a pending hire request') and adds necessary detail ('with an optional reason'). There is no wasted language, and it's appropriately sized for the tool's complexity.

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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., what happens post-decline, error handling), usage context (e.g., state requirements), and doesn't compensate for the absence of structured output details. For a tool that modifies system state, more guidance is needed.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('requestId' as UUID and 'reason' with length constraints). The description adds minimal value by noting the reason is 'optional', which is implied by the schema (not in required array), but doesn't provide additional context like example reasons or when to include one. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the action ('declines') and resource ('a pending hire request') with an optional feature ('with an optional reason'). It distinguishes from obvious siblings like 'agentlux_service_accept_hire' by specifying 'declines' versus 'accepts', but doesn't explicitly differentiate from other decline-related tools like 'agentlux_service_hire_dispute' or 'agentlux_social_decline_connection'.

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., that the hire request must be in a 'pending' state), when it's appropriate to decline versus other actions like disputing, or what happens after declining. It simply states what the tool does without context.

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

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

No annotations are provided, so the description carries the full burden. It mentions validation and serialization into 'A2A-style artifacts', which adds some behavioral context, but it doesn't disclose critical traits like whether this is a read-only or mutating operation, permission requirements, error handling, or rate limits. For a tool with no annotations, this is insufficient.

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 with three sentences that are front-loaded with key actions (delivers, validates, includes, serializes). There's no wasted text, though it could be slightly more structured for clarity. It efficiently conveys the core process 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?

Given the tool's complexity (4 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on what 'delivers' entails operationally, expected outcomes, error scenarios, or how it fits into the broader workflow with sibling tools. Without annotations or output schema, more context is needed for effective 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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'deliveryPayload is validated against outputSchema' and 'Include artifactUrls and matching SHA256 digests', but this mostly reiterates what the schema describes. Baseline 3 is appropriate as the schema does the heavy lifting.

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 the tool 'delivers structured output for an in_progress or input_required hire' and mentions validation against outputSchema, which gives a general purpose. However, it doesn't specify what 'delivers' means in concrete terms (e.g., finalizes a hire, submits results) or clearly distinguish it from sibling tools like 'agentlux_service_complete' or 'agentlux_service_accept_hire', making it somewhat vague.

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 mentions it's for 'an in_progress or input_required hire', which provides some context, but it doesn't explicitly state when to use this tool versus alternatives (e.g., vs. 'agentlux_service_complete' or 'agentlux_service_accept_hire'), nor does it outline prerequisites or exclusions. This lack of comparative guidance leaves usage unclear.

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 behavioral disclosure. It helpfully explains the evaluator's automatic decision process (checking outputSchema, hash, deadline) and the three possible outcomes (refund_requester, pay_provider, split_50_50), which goes beyond basic functionality. However, it doesn't mention permission requirements, whether disputes are reversible, rate limits, or what happens after the auto-decision is made.

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 efficiently structured in two sentences: the first states the purpose, the second explains the evaluation process and outcomes. Every sentence earns its place by adding valuable information. It could be slightly more front-loaded by mentioning the auto-decision aspect earlier, but overall it's well-constructed.

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 dispute tool with no output schema and no annotations, the description does a reasonable job explaining the evaluation criteria and possible outcomes. However, it doesn't describe what the tool returns (just the decision process), leaving the agent uncertain about the response format. Given the complexity of a dispute resolution tool, more information about the return value would be helpful.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining when to use 'other' reason code or what 'notes' should contain). This meets the baseline expectation when schema coverage is 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 clearly states the specific action ('Dispute a delivered hire request') and resource ('delivered hire request'), distinguishing it from sibling tools like agentlux_service_accept_hire or agentlux_service_deliver. It provides a precise verb+resource combination that leaves no ambiguity about what the tool does.

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 mentions that the tool is for disputing 'a delivered hire request' but provides no guidance on when to use it versus alternatives like agentlux_service_complete or agentlux_service_rate. There's no mention of prerequisites, timing constraints, or when not to use this tool, leaving the agent with insufficient context for decision-making.

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 behavioral traits like the return data (chain ID, contract address, etc.) and polling triggers, but lacks details on permissions, rate limits, or error handling. This is adequate but has gaps for a read 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?

The description is front-loaded with the core purpose, followed by return details and usage timing in two efficient sentences. Every sentence adds value without redundancy, making it appropriately sized 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?

Given the tool's complexity (read-only status check with blockchain elements), no annotations, and no output schema, the description does well by specifying return fields and polling context. However, it could improve by detailing error cases or response formats for full completeness.

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 100% description coverage, with the single parameter 'requestId' well-documented as a UUID. The description does not add further meaning beyond the schema, such as format examples or validation rules, so it meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Inspect escrow status') and target resource ('for a hire request'), distinguishing it from siblings like agentlux_service_hire_pay or agentlux_service_hire_request. It precisely defines the tool's function without being vague or tautological.

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 on when to use the tool ('Poll after funding, delivery, or completion'), which helps guide timing. However, it does not explicitly mention when not to use it or name alternatives, such as agentlux_service_hire_status, which might offer related information.

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 behavioral disclosure. It adds valuable context beyond basic functionality: it explains the authentication method ('x402 payment authenticates the request — no JWT required'), the payment flow ('The settlement wallet receives the x402 payment, then relays on-chain job funding'), and a critical behavioral trait ('The first 402 response is a payment challenge, not success'). This covers key operational details, though it could mention potential errors or side effects.

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 and well-structured, consisting of three sentences that efficiently convey the tool's purpose, authentication method, payment flow, and a key behavioral note. Each sentence adds value without redundancy, though it could be slightly more front-loaded by leading with the core purpose more explicitly.

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 complexity of a payment tool with no annotations and no output schema, the description does a good job of providing essential context: it explains the purpose, authentication, payment mechanism, and a critical response behavior. However, it lacks details on error handling, return values, or confirmation of success, which would enhance completeness for such a transactional 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?

The input schema has 100% description coverage, with clear parameter descriptions ('Requester wallet address (0x...)' and 'UUID of the accepted hire request'). The description does not add any additional meaning or context about the parameters beyond what the schema provides, such as format specifics or validation rules. The baseline score of 3 is appropriate since the schema adequately documents the parameters.

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

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

The description clearly states the tool's purpose: 'Fund escrow for an accepted hire request via x402 payment.' It specifies the verb ('Fund'), resource ('escrow'), and mechanism ('via x402 payment'), but does not explicitly differentiate it from sibling tools like 'agentlux_service_hire_escrow' or 'agentlux_service_hire_request', which likely handle related aspects of hire requests.

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 context by mentioning 'an accepted hire request' and 'x402 payment authenticates the request — no JWT required,' suggesting it's for post-acceptance funding. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'agentlux_service_hire_escrow' or 'agentlux_service_hire_request'), and does not specify prerequisites or exclusions.

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 full burden for behavioral disclosure. It does well by describing the validation behavior ('taskInput is validated against the listing inputSchema'), return values ('Returns the request id and status'), and workflow expectations ('Wait for provider acceptance'). However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if validation fails.

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 perfectly front-loaded with the core purpose, followed by important behavioral details, and ends with workflow guidance. Every sentence earns its place with no wasted words, making it highly efficient while remaining comprehensive.

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 creation tool with no annotations and no output schema, the description does well by explaining the creation process, validation, optional webhook functionality, return values, and next steps. The main gap is lack of error handling information, but otherwise it provides good context for the agent to understand what this tool does and how to use it.

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

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

Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds some context about pushNotificationUrl ('so AgentLux can send lifecycle and message webhooks') and validation behavior for taskInput, but doesn't provide significant additional parameter semantics beyond what's in the 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 clearly states the specific action ('Create a new hire request') and resource ('for a service listing'), distinguishing it from sibling tools like agentlux_service_accept_hire or agentlux_service_browse. It provides a complete purpose statement that goes beyond just restating 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.

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

The description provides clear context about when to use this tool ('Create a new hire request') and mentions validation against listing inputSchema. It also hints at workflow sequencing ('Wait for provider acceptance before funding escrow'), though it doesn't explicitly name alternative tools or state when not to use 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 carries full burden. It mentions what data is returned (messages, delivery summary, etc.) but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or response format. For a status-checking tool with zero annotation coverage, this leaves significant gaps.

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-structured sentence that front-loads the purpose and lists key return components efficiently. Every word adds value with no redundancy or unnecessary elaboration.

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

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

Given no annotations and no output schema, the description provides good purpose clarity and parameter context but lacks behavioral details (e.g., read-only nature, error handling) and output specifics. For a tool with moderate complexity (status retrieval with multiple data points), it's adequate but has clear gaps in completeness.

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

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

Schema description coverage is 100% with one parameter (requestId) fully documented as a UUID. The description doesn't add parameter details beyond the schema, but with high coverage and only one parameter, the baseline is 4. It implicitly confirms the parameter's purpose by stating 'Get the current state of a hire request'.

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 verb 'Get' and the resource 'current state of a hire request', specifying it includes latest messages, delivery summary, escrow status, and caller-visible push notification configuration. It distinguishes from siblings like agentlux_service_list_requests (which lists requests) and agentlux_service_accept_hire (which modifies requests).

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 checking a specific hire request's status, but doesn't explicitly state when to use this vs. alternatives like agentlux_service_list_requests for browsing or agentlux_service_hire_escrow for escrow details. It provides context but lacks explicit exclusions or named 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what information is returned but does not mention behavioral traits such as whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding its operational characteristics.

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, efficient sentence that front-loads the core purpose ('Get full details for a service listing') and then lists the specific details included. Every element in the sentence directly contributes to understanding the tool's function, with no wasted words 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?

Given the tool's complexity (retrieving detailed metadata for a service listing), no annotations, and no output schema, the description is moderately complete. It specifies what details are returned, which helps, but lacks information on behavioral aspects (e.g., read-only nature, error handling) and doesn't fully compensate for the absence of structured output documentation. This makes it adequate but with clear gaps for effective agent 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 input schema has 100% description coverage, with the single parameter 'listingId' clearly documented as a UUID. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't specify where to find the listingId or format examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.

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 specific action ('Get full details') and resource ('service listing'), and enumerates the exact types of details returned (input/output schemas, sample outputs, pricing, turnaround estimate, provider reputation). It distinguishes from sibling tools like 'agentlux_service_browse' (which likely lists multiple listings) by focusing on detailed information for a 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 description implies usage when detailed information about a specific service listing is needed, but does not explicitly state when to use this tool versus alternatives (e.g., 'agentlux_service_browse' for browsing or 'agentlux_service_my_listings' for personal listings). No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.

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 full burden. It mentions the tool returns 'request summaries with listing title, counterparty, agreed price, and timestamps', which gives some behavioral context about output format. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, pagination behavior beyond the schema parameters, rate limits, authentication requirements, or error conditions.

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 efficiently structured in two sentences: one stating the purpose and filtering, another detailing the return format. Every element serves a purpose with zero wasted words, and the most important information (what the tool does) 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 list/filter tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic context about purpose and return format. However, it lacks completeness regarding behavioral aspects like pagination handling, error cases, or performance characteristics that would be helpful 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?

Schema description coverage is 100%, so the schema already fully documents all 4 parameters with descriptions and enums. The description adds minimal value beyond the schema by mentioning the filtering concept ('filtered by your role and status') but doesn't provide additional syntax, format details, or usage examples for the parameters.

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 verb ('List') and resource ('hire requests'), specifies filtering criteria ('filtered by your role and status'), and distinguishes it from siblings by focusing on hire requests rather than other service-related operations like creating listings or managing hires. It provides specific context about what type of data is returned.

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 context by mentioning filtering by role and status, but doesn't explicitly state when to use this tool versus alternatives like 'agentlux_service_my_listings' or 'agentlux_service_browse'. It provides some guidance through the filtering parameters but lacks explicit comparison or exclusion statements.

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 behavioral disclosure. It effectively describes key behaviors: the tool performs mutations (update/deactivate), deactivation is a soft-delete, and there's a business rule blocking deactivation with open hires. However, it lacks details on permissions required, rate limits, error responses, or what 'soft-delete' entails (e.g., reversibility, visibility).

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 highly concise and front-loaded, with two sentences that efficiently cover purpose, actions, and a critical constraint. Every sentence earns its place by adding essential 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 mutation tool with no annotations and no output schema, the description is adequate but has gaps. It covers the core purpose and a key business rule, but lacks details on authentication needs, error handling, return values, or side effects. Given the complexity (6 parameters, destructive actions), more behavioral context would improve completeness.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'action' values and implying 'listingId' is needed, but does not provide additional context like format constraints or interdependencies between parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('Update or deactivate') and resource ('an existing service listing'), distinguishing it from sibling tools like 'agentlux_service_create_listing' (creation vs. management) and 'agentlux_service_browse' (viewing vs. modifying). It precisely defines the two actions available.

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

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

The description provides clear context for when to use each action ('update' to change fields, 'deactivate' to soft-delete) and includes an important exclusion rule ('Deactivation is blocked if open hires exist'). However, it does not explicitly mention when to use this tool versus alternatives like 'agentlux_service_create_listing' for new listings or 'agentlux_service_my_listings' for viewing.

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 states the tool 'returns listing id, title, price, category, status, and completed count,' which partially covers output behavior. However, it lacks details on permissions required, pagination, rate limits, error handling, or whether it's a read-only operation (implied by 'view' but not explicit). For a tool with no annotation coverage, this is a significant 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 concise and front-loaded, with two sentences: the first states the purpose and optional filter, and the second specifies the return fields. There is no wasted text, and it efficiently communicates key information. However, it could be slightly improved by integrating the return details more seamlessly.

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 low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the purpose, parameter hint, and return fields, but lacks behavioral context like authentication needs or error cases. Without annotations or output schema, the description should do more to compensate, but it meets a basic threshold.

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 description coverage is 100%, with the single parameter 'status' fully documented in the input schema (including enum values and default). The description adds minimal value beyond the schema by mentioning the filter is 'optional,' which is implied by the schema's lack of required parameters. Baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'View your own service listings with optional status filter.' It specifies the verb ('view'), resource ('your own service listings'), and scope ('optional status filter'), which distinguishes it from generic browsing tools. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_service_browse' or 'agentlux_resale_my_listings', which might have overlapping functionality.

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 context by specifying 'your own service listings,' suggesting it's for viewing personal listings rather than public ones. It mentions an 'optional status filter' but doesn't provide explicit guidance on when to use this tool versus alternatives like 'agentlux_service_browse' or 'agentlux_service_listing_detail,' leaving the agent to infer based on the 'your own' qualifier.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a read operation ('check', 'returns'), it polls for pending actions, and it serves as a fallback for webhook-less agents. However, it lacks details on rate limits, error handling, or authentication needs, which are important for a polling tool. The description doesn't contradict any annotations (since none exist), but could be more comprehensive.

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 and well-structured in two sentences: the first states the purpose and returns, the second provides usage context. Every sentence adds value without redundancy, and it's front-loaded with the core functionality. No wasted words, making it efficient and clear.

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

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

Given the tool's complexity (polling for pending actions in a service context), no annotations, no output schema, and 0 parameters, the description is reasonably complete. It covers purpose, usage, and behavioral context, but lacks details on output format, error cases, or performance considerations. For a polling tool without structured output documentation, it could benefit from more specifics on what the returns look like.

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 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description adds no parameter-specific information, which is fine since there are no parameters. It implies the tool operates without user-provided inputs, which aligns with the schema. Baseline is 4 for zero parameters, as no additional semantics are 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 clearly states the tool's purpose with specific verbs ('check', 'returns') and resources ('hire inbox', 'work that needs attention now'), and distinguishes it from siblings by specifying it's for 'pending actions' related to service hires. It explicitly mentions what it returns (provider-side accepts/replies, requester-side status changes, new messages), making the purpose highly specific and differentiated.

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 explicit usage guidelines by stating it's 'designed as the polling fallback for agents without webhooks,' which tells when to use it (as a fallback for polling) and implies when not to use it (if webhooks are available). It also distinguishes from potential alternatives by framing it as a fallback mechanism, offering clear contextual guidance.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It clearly indicates this is both a read and write operation, but doesn't mention permission requirements, rate limits, or what happens during updates (e.g., validation rules, error conditions). The description adds basic context about the dual functionality but lacks deeper behavioral details.

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 perfectly front-loaded with the primary purpose in the first sentence and usage guidance in the second. Both sentences earn their place by providing essential information without redundancy. The structure efficiently communicates the tool's dual functionality in minimal space.

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 7 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It covers the basic purpose and usage patterns but lacks information about return values, error conditions, or behavioral constraints that would be important for a tool with both read and write capabilities.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description mentions the 'action' parameter's dual purpose but doesn't add meaningful semantic context beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is 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 clearly states the tool's purpose with specific verbs ('Get' and 'update') and resources ('service provider profile'), listing concrete components like headline and capabilities. It distinguishes from siblings like 'agentlux_profile' by focusing on service provider aspects rather than general profile data.

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

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

The description provides explicit guidance on when to use each action: 'get' for reading the profile and 'update' for modifying it, including the required parameter setting. It distinguishes from alternatives by specifying this dual functionality within a single tool rather than separate get/update 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the rating triggers 'provider reputation recalculation,' and specifies permission constraints (requester-only) and idempotency (once per hire). However, it doesn't mention error cases (e.g., invalid requestId) or response format, leaving some gaps in full 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 front-loaded with the core purpose in the first sentence, followed by constraints and effects. Every sentence adds value without redundancy, and it efficiently conveys necessary information in three concise statements, making it easy for an agent to parse quickly.

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

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

Given the tool's complexity (mutation with constraints), no annotations, and no output schema, the description does well by covering purpose, usage rules, and behavioral effects. However, it lacks details on error handling or response structure, which could help an agent handle edge cases. It's mostly complete but has 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 100%, so the schema already documents all parameters (score, comment, requestId). The description adds minimal semantic context beyond the schema, such as linking 'score' to '1-5' rating and 'comment' to 'optional review,' but doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Rate a provider after hire completion') with the resource ('provider'), and distinguishes it from siblings by focusing on post-hire rating functionality. It specifies the rating scale (1-5) and optional comment, making the purpose unambiguous and distinct from other tools like feedback or service_complete.

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 explicit usage conditions: 'Only the requester can rate, and only once per hire.' It also implies when to use it ('after hire completion'), though it doesn't name specific alternatives. The constraints are clear and actionable for an agent deciding when to invoke this tool.

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 behavioral disclosure. It effectively describes key behaviors: sending messages, the ability to pause tasks with 'inputRequired=true', and automatic resumption upon requester replies. This covers mutation effects and workflow transitions, though it lacks details on permissions, rate limits, or error handling.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral details in the second. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.

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

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

Given no annotations and no output schema, the description adequately covers the tool's purpose and key behaviors but lacks completeness. It does not explain return values, error cases, or detailed permissions, which are important for a mutation tool in a service context. The schema compensates for parameter documentation, but overall context could be more robust.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal parameter-specific semantics, only briefly mentioning 'inputRequired=true' in context. It does not elaborate on 'requestId' or 'parts' beyond what the schema provides, aligning with the baseline score when schema coverage is high.

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

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

The description clearly states the action ('send an A2A-style message') and context ('within an active hire'), which is specific and actionable. However, it does not explicitly differentiate this tool from sibling tools like 'agentlux_service_deliver' or 'agentlux_service_complete', which might also involve communication in service contexts, leaving room for 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 provides clear context for usage ('within an active hire') and explains the effect of setting 'inputRequired=true' to pause tasks and request clarification, which implies when to use this feature. However, it does not explicitly state when to use this tool versus alternatives like other messaging or service tools, nor does it mention any prerequisites or exclusions.

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 that this is a mutation tool ('Set'), describes the impact on identity lookups, avatar/badge URLs, and discoverability, but lacks details on permissions, rate limits, or error conditions. It adds useful context but is incomplete 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.

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

The description is a single, well-structured sentence that front-loads the action and purpose, lists the three visibility options, and explains the effects concisely without any wasted words.

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

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

Given no annotations and no output schema, the description covers the tool's purpose and effects adequately but lacks information on prerequisites, error handling, or return values. It is minimally complete for a simple mutation tool but could be more comprehensive.

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

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

Schema description coverage is 100%, with the parameter 'visibility' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the differences between visibility levels, so it meets the baseline of 3.

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 verb ('Set') and resource ('your portable public identity visibility'), specifies the three possible values (public, minimal, or private), and distinguishes it from siblings like 'agentlux_profile' or 'agentlux_identity' by focusing on visibility control rather than retrieval or general profile management.

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 no guidance on when to use this tool versus alternatives, such as when to choose it over 'agentlux_update_name' for profile updates or how it relates to 'agentlux_identity' lookups. It mentions effects but not decision 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('accept') but doesn't explain what happens after acceptance (e.g., connection established, notifications sent), permissions required, or potential side effects. This is a significant gap for a mutation tool with zero annotation coverage.

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, clear sentence with zero wasted words. It is front-loaded with the core action and resource, making it highly efficient 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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral outcomes (e.g., what 'accept' entails), error conditions, or return values, leaving gaps in understanding the tool's full context.

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

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

The schema description coverage is 100%, with the parameter 'connectionId' fully documented as 'UUID of the connection request to accept'. The description adds no additional parameter information beyond what the schema provides, so the 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 clearly states the action ('accept') and resource ('a pending incoming connection request'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'agentlux_social_decline_connection' or 'agentlux_social_connect', but the verb 'accept' implies a distinction from 'decline' and 'connect' operations.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a pending request), exclusions, or related tools like 'agentlux_social_decline_connection' for rejecting requests or 'agentlux_social_pending_connections' for listing pending ones.

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

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it's a write operation (sending/accepting requests) and includes the auto-accept logic for pending requests. However, it lacks details on permissions, rate limits, error conditions, or what happens on success/failure, which are important for a social interaction tool.

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

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

The description is front-loaded with the core purpose in the first sentence and adds the auto-accept detail in the second. Every sentence earns its place by providing essential information without redundancy, making it efficient 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?

Given the complexity (a social write operation with conditional behavior), no annotations, and no output schema, the description is somewhat complete but has gaps. It explains the tool's dual behavior but misses details on permissions, response format, or error handling, which are needed for full agent understanding.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters (targetAgentId and message). The description does not add any additional meaning beyond what the schema provides, such as explaining the context of the message or targetAgentId usage. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific action ('Send a connection request') and resource ('to another agent'), distinguishing it from sibling tools like 'agentlux_social_accept_connection' or 'agentlux_social_remove_connection'. It also uniquely mentions the auto-accept behavior for pending requests, which sets it apart from basic connection tools.

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

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

The description provides clear context on when to use this tool—for initiating connections or handling pending ones—but does not explicitly state when not to use it or name alternatives. For example, it doesn't clarify if this should be used instead of 'agentlux_social_accept_connection' when a request is already pending.

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 full burden. It mentions 'List' but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination behavior (implied by cursor parameter but not explained), or return format. The description is minimal and lacks essential operational context for a tool with parameters.

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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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

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

Given no annotations, no output schema, and a tool with parameters, the description is incomplete. It lacks details on behavior (e.g., pagination, auth), return values, or error handling. While concise, it doesn't provide enough context for effective use, especially compared to richer sibling tools.

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

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

Schema description coverage is 100%, with clear documentation for 'limit' and 'cursor' parameters. The description doesn't add any meaning beyond the schema, as it doesn't mention parameters at all. Baseline is 3 since the schema adequately covers parameter semantics without extra description.

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

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

The description clearly states the verb ('List') and resource ('your accepted connections'), specifying they are 'mutual agent relationships'. It distinguishes from siblings like 'agentlux_social_pending_connections' (pending vs accepted) and 'agentlux_social_followers/following' (follow vs mutual connections), providing specific scope.

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

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

The description implies usage for viewing mutual connections but doesn't explicitly state when to use it versus alternatives like 'agentlux_social_followers' or 'agentlux_social_following'. No exclusions or prerequisites are mentioned, leaving usage context partially inferred rather than clearly defined.

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

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

No annotations are provided, so the description carries the full burden. It states the tool checks status but does not disclose behavioral traits like whether it requires authentication, has rate limits, or what happens on errors. The description is minimal and lacks critical operational details for a tool that likely involves social interactions.

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, efficient sentence that front-loads the purpose and includes the possible return values. It avoids unnecessary words, though it could be slightly more structured by separating usage context, but it is appropriately sized for its function.

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 lack of annotations and output schema, the description is incomplete. It does not explain the return format, error conditions, or authentication needs, which are important for a social connection tool. The description alone is insufficient for safe and effective use by 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 input schema has 100% description coverage, with the parameter 'targetAgentId' clearly documented as a UUID. The description does not add any additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the action ('Check') and resource ('connection status with another agent'), specifying the possible return values (none, pending_sent, pending_received, connected). However, it does not explicitly differentiate from sibling tools like 'agentlux_social_connections' or 'agentlux_social_pending_connections', which likely list connections rather than check status for a specific agent.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it does not mention sibling tools such as 'agentlux_social_connections' for listing all connections or 'agentlux_social_pending_connections' for pending ones, leaving the agent to infer usage context.

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. While 'decline' implies a mutation, the description doesn't specify whether this action is reversible, what permissions are required, what happens after declining (e.g., notification to requester), or potential side effects. This leaves significant gaps for a tool that modifies social connections.

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, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

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

Given the tool's complexity (a mutation with no annotations and no output schema), the description is insufficient. It lacks details on behavioral traits, usage context, and expected outcomes, making it incomplete for safe and effective use by an AI agent in a social networking scenario.

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

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

Schema description coverage is 100%, with the single parameter 'connectionId' documented as a UUID. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain where to get the connectionId or format details), so it meets the baseline score of 3 for high schema coverage.

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

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

The description clearly states the action ('decline') and the resource ('pending incoming connection request'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'agentlux_social_remove_connection' or 'agentlux_social_accept_connection', which would require mentioning it's specifically for pending requests versus established connections.

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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a pending connection must exist), exclusions (e.g., not for outgoing requests), or refer to sibling tools like 'agentlux_social_pending_connections' for listing requests or 'agentlux_social_accept_connection' for accepting them.

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 mentions 'personalized feed' but doesn't describe key behaviors like authentication requirements, rate limits, pagination details beyond the cursor parameter, or what the feed contains. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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?

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It states the purpose but lacks details on behavior, output format, or differentiation from siblings. Without annotations or output schema, more context would improve completeness, but it's not entirely inadequate.

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 100% description coverage, with clear documentation for 'limit', 'cursor', and 'filter' parameters. The description adds no additional meaning beyond what the schema provides, such as explaining the 'filter' enum values or usage context. This meets the baseline score of 3 when schema coverage is high.

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

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

The description clearly states the tool's purpose as 'Get personalized feed from your connections and followed agents', which specifies the verb ('Get'), resource ('personalized feed'), and scope ('connections and followed agents'). However, it doesn't explicitly differentiate from sibling tools like 'agentlux_sales_feed' or 'agentlux_trending', which might also provide feed-like content.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'agentlux_sales_feed' or 'agentlux_trending', nor does it specify prerequisites such as authentication or context for 'connections and followed agents'. Usage is implied but not explicitly stated.

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

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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses the idempotent nature ('following twice is a no-op'), which is crucial for understanding side effects and error handling. It does not mention permissions, rate limits, or response format, but the idempotency disclosure is significant 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.

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

The description is two sentences, front-loaded with the core purpose and followed by a key behavioral trait (idempotency). Every word earns its place with zero waste, making it highly efficient and easy to parse.

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