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

Annotations provide readOnlyHint=false (mutation), destructiveHint=false (safe), and idempotentHint=true (repeatable). The description adds valuable behavioral context beyond annotations: it explains the multi-step process (Puppeteer fallback, manual login, auto-detection), mentions browser closure, storage of cookies for future API calls, and notes it may take longer due to manual login. No contradiction with 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 well-structured with bullet points for steps, a returns section, notes, and examples. It is appropriately sized for a complex tool, though slightly verbose; every sentence adds value (e.g., explaining fallback mechanisms, manual login, and timing). Could be slightly more concise but remains effective.

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 (browser automation, manual login) and lack of output schema, the description provides good completeness: it details the process, return values (success message with login status), and operational notes. It covers key aspects like authentication cookie storage and timing, though could briefly mention error handling or prerequisites.

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

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

There are 0 parameters, and schema description coverage is 100% (no parameters to describe). The description appropriately explains the tool's behavior without needing parameter details, adding context about the login process and outcomes. Baseline is 4 for zero parameters, and it meets this by providing relevant operational semantics.

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 ('Automatically open browser to log in to Iconfont and obtain authentication cookie') and distinguishes it from siblings like 'iconfont_login' (likely manual) and 'iconfont_check_login' (verification). It explicitly mentions the resource (Iconfont) and the outcome (authentication cookie).

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 with 'Use when: "I want to log in without manually copying cookie"' and distinguishes from alternatives by specifying this tool opens a browser for secure login, unlike other login methods. It clearly indicates when to use this tool versus other login approaches.

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

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

Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), indicating a safe, non-destructive, and deterministic operation. The description adds value by specifying the return details ('Current login status and whether a cookie is available'), which isn't covered by annotations. No contradiction with annotations is present.

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 purpose, and the second clarifies the return values. Every sentence earns its place with no 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 low complexity (0 parameters, simple purpose) and rich annotations covering safety and behavior, the description is mostly complete. It adds return value details, which is helpful since there's no output schema. However, it could slightly improve by mentioning typical use cases or error conditions, but this is minor for such a straightforward tool.

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

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

The tool has 0 parameters, and the input schema has 100% description coverage (though trivial). The description doesn't need to explain parameters, so it meets the baseline of 4 for tools with no parameters. It appropriately focuses on the return values instead.

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 if currently logged in to Iconfont.' This is a specific verb ('Check') and resource ('login status'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'iconfont_login' or 'iconfont_auto_login', which would require 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 implies usage by stating what it returns, suggesting it should be used to verify login status before performing actions that require authentication. However, it lacks explicit guidance on when to use this tool versus alternatives like 'iconfont_login' or 'iconfont_auto_login', and doesn't mention 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?

Annotations indicate idempotentHint=true but no readOnly or destructive hints. The description explains it retrieves SVG and optionally saves to file, which is consistent with mutable but non-destructive behavior. It does not detail potential overwrite scenarios, but the idempotent hint mitigates that.

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?

Description is well-structured with intro, args list, returns, and examples. Every section is concise and adds value, with the main purpose stated upfront. No unnecessary 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?

Despite not having an output schema, the description explains return formats (JSON vs Markdown) and provides usage examples. It covers all parameters and gives clear instructions on parameter dependencies, making it complete for the tool's complexity.

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

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

Schema coverage is 100%, but description adds valuable context: icon_id from search, project_id from list_projects, output_path defaults to current directory, filename without extension. The returns section also clarifies output formats, enhancing schema information.

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?

Title 'Download Iconfont Icon SVG' and description 'Download SVG data for a specific icon from Iconfont' clearly state the verb (download) and resource (SVG for an icon). The description also specifies optional file saving, distinguishing it from sibling search/list 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?

Examples provide specific use cases (download icon, from private project, to specific folder) and mention how to obtain icon_id from search results and project_id from iconfont_list_projects. However, it does not explicitly state when not to use this tool versus siblings, though the context implies 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?

Annotations already cover read-only, non-destructive, idempotent, and open-world hints, so the bar is lower. The description adds valuable behavioral context beyond annotations by disclosing caching behavior ('Results are cached for 5 minutes based on the project's update time to reduce API calls'), which is not captured in annotations. No contradictions with annotations exist.

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 well-structured with clear sections (purpose, caching, args, returns, examples) and front-loaded key information. It avoids redundancy, though the parameter descriptions in the 'Args' section slightly repeat schema details. Overall, it's efficient and easy to scan.

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 (read-only, 3 parameters), rich annotations, and 100% schema coverage, the description is largely complete. It adds caching behavior and usage examples, though without an output schema, it could briefly clarify return value structure beyond listing fields. Still, it provides sufficient context 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 fully documents all parameters. The description repeats some parameter information (e.g., cookie and pid details) but adds minimal extra semantics beyond the schema, such as noting the pid source. This meets the baseline 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 with a specific verb ('retrieves') and resource ('detailed information about a specific Iconfont project'), and distinguishes it from siblings by focusing on project details rather than listing projects (iconfont_list_projects) or downloading/searching icons. The title reinforces this specificity.

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 this tool ('Get details of project 1997925') and references a sibling tool for obtaining the required pid ('can be obtained from iconfont_list_projects'). It also clarifies the optional cookie parameter as an alternative to environment variables, offering clear 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?

The description adds valuable behavioral context beyond annotations. While annotations indicate read-only, non-destructive, idempotent operations, the description discloses authentication requirements ('requires authentication via Iconfont cookie'), multiple authentication methods (cookie arg, environment variable, or iconfont_login tool), and cookie sourcing details ('from browser dev tools after logging into iconfont.cn'). No contradiction with annotations exists.

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

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

The description is well-structured with clear sections (purpose, authentication details, args, returns, notes, examples) and front-loaded with the core purpose. While comprehensive, some information like cookie sourcing details could be considered slightly verbose, but most sentences earn their place by providing necessary context.

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 (list operation with authentication), rich annotations covering safety aspects, and detailed parameter documentation in the schema, the description provides complete context. It covers authentication requirements, usage examples, return format details, and distinguishes from sibling tools, making it fully adequate for 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 schema already fully documents both parameters. The description's 'Args' section repeats the schema information without adding significant semantic value beyond what's in the schema descriptions. 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 specific action ('List all projects') and resource ('in the user's Iconfont account'), distinguishing it from siblings like iconfont_get_project_detail (which gets details for a specific project) and iconfont_project_search_icons (which searches within a project). The verb 'List' is precise and the scope 'all projects' is explicit.

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 guidance with 'Examples' section stating 'Use when: "See all my icon projects"' and 'Use when: "Find project ID for a specific project"'. This clearly indicates when to use this tool versus alternatives like iconfont_get_project_detail (for specific project details) or iconfont_search_icons (for searching icons across projects).

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

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

The description adds valuable behavioral context beyond the annotations: it specifies that the cookie is stored in memory only and lost on server restart, which clarifies the transient nature of the authentication. The annotations (idempotentHint: true, destructiveHint: false) are not contradicted, as login is typically idempotent and non-destructive. However, it doesn't detail rate limits or specific 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 well-structured with clear sections (purpose, args, how-to, returns, note, examples), making it easy to scan. It is appropriately sized, though the 'How to get the cookie' steps are somewhat detailed; every sentence serves a purpose, such as clarifying storage persistence and providing usage examples.

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 (authentication with a single parameter) and the absence of an output schema, the description is mostly complete: it explains the purpose, usage, parameter, and behavioral aspects like storage limitations. However, it lacks details on return values beyond 'Success or error message,' which could be more specific, and doesn't cover potential error scenarios or authentication scopes.

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 input schema fully documenting the single required 'cookie' parameter. The description adds minimal extra meaning by reiterating how to obtain the cookie in the 'Args' section, but this largely overlaps with the schema's description. No additional parameter insights are provided beyond what the schema already covers.

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 ('Authenticate with Iconfont using browser cookie') and resource ('Iconfont account'), distinguishing it from siblings like iconfont_check_login (which checks status) and iconfont_auto_login (which might use different authentication methods). It explicitly mentions accessing private projects and features requiring authentication.

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 this tool ('Login to access my private projects' in the examples section) and distinguishes it from alternatives by noting that for persistent login, the ICONFONT_COOKIE environment variable should be used instead. It also implicitly contrasts with iconfont_check_login by focusing on authentication rather than status verification.

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

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

The description adds valuable behavioral context beyond what annotations provide: it explains authentication requirements (cookie, environment variable, or login tool), describes pagination behavior, and specifies output formats. While annotations cover safety (readOnly, non-destructive), the description provides practical implementation details that help the agent use the tool correctly.

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 well-structured with clear sections (purpose, authentication, args, returns, notes, examples). While slightly longer than minimal, every sentence adds value. The information is front-loaded with the core purpose 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 search tool with comprehensive annotations and full parameter documentation, the description provides excellent contextual completeness. It covers authentication methods, output formats, practical examples, and distinguishes from siblings. The lack of output schema is compensated by clear return format descriptions.

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 schema already documents all parameters thoroughly. The description adds minimal additional semantic context - mainly reinforcing that 'pid' can be obtained from another tool and providing usage 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 specific action ('search for icons'), resource ('within a specific Iconfont project'), and scope ('using keyword'). It distinguishes this tool from the sibling 'iconfont_search_icons' by specifying it searches within a specific project rather than globally.

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 this tool with concrete examples ('Search copy icons in project 1997925'), mentions authentication requirements, and distinguishes it from the global search sibling. The 'Examples' section gives clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by specifying the data source ('Iconfont database'), scale ('millions of icons'), and output format details (JSON structure vs markdown presentation). It doesn't mention rate limits or authentication requirements, but annotations provide openWorldHint=true, so this is reasonably complete.

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 well-structured with clear sections (overview, Args, Returns, Examples) and front-loads the core purpose. Some redundancy exists between the Args section and schema descriptions, but the examples add practical value. The text is appropriately sized for a tool with 5 parameters and no output schema.

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 (search operation with pagination and format options), rich annotations (covering safety and idempotency), and 100% schema coverage, the description provides excellent contextual completeness. It explains what the tool does, when to use it, parameter usage through examples, and output format differences, making it fully self-contained 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 parameters. The description repeats parameter information in the Args section but adds minimal extra context (e.g., 'max 100' for page_size is already in schema). It provides helpful examples showing parameter usage, but doesn't add significant semantic value beyond what's in the structured schema.

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

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

The description clearly states the specific action ('search for icons'), target resource ('Iconfont icon library'), and scope ('millions of icons from various designers and collections'). It distinguishes itself from siblings like iconfont_download_icon (download) and iconfont_project_search_icons (project-specific search) by focusing on general icon search across the entire library.

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 examples with specific scenarios ('Find home icons', 'Search outline-style arrows', 'Get page 2 of search results'), effectively demonstrating when to use this tool. It also implicitly distinguishes from siblings by not mentioning project-specific searches or download operations, guiding users toward the appropriate tool for general icon discovery.

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