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

With no annotations, the description carries the full behavioral burden and discloses the non-obvious contract: the tool does not draw anything, the agent draws the SVG itself from the spec, and validation is a required downstream step. That is the single most important behavioral fact about this tool. It stops short of covering failure modes, whether spec generation consumes quota, or any auth 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?

Three short sentences, each doing distinct work: what you get, when to use it, and the mandatory next step. The critical instruction (validate before use) is placed last but flagged with "ALWAYS" so it is not skimmable-past, and the "(you)" aside removes ambiguity about who draws the SVG.

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 three-parameter tool with a fully described schema but no output schema, the workflow (spec -> draw -> validate) is complete and self-sufficient. The residual gap is that the return value is never characterized, so the agent cannot anticipate the spec's structure or size before calling, though it will be self-explanatory once returned.

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 size, style, and description are already fully documented in the schema, including defaults and the note that g_validate injects width/height. The description adds no syntax, format, or guidance for the description parameter beyond what the schema states, so baseline 3 applies.

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

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

States a specific verb and resource: it returns a generation spec for a custom SVG icon rather than the icon itself, and explicitly positions itself against i_search_all and g_validate. The one gap is that "a precise spec" is never concretized (format, contents), so the agent knows the role but not exactly what it will receive.

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?

Gives an explicit triggering condition ("Use when i_search_all finds nothing suitable") and an explicit mandatory follow-up step ("ALWAYS pass the SVG through g_validate"). An agent knows both when to select this tool and what to do immediately after, with no inference required.

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

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

With no annotations, the description carries the full burden and does well: it discloses the security filter's specific rejection list (<script>, event handlers, <foreignObject>, javascript:), the additive repairs (xmlns/viewBox, color/size), and the return shape (cleaned SVG plus warnings). It leaves ambiguous whether offending content causes rejection/error or silent stripping, which is the main behavioral 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?

A single dense sentence front-loads the action verbs, then the security scope, then the return value; each clause carries distinct information with no repetition of the title or filler.

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

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

For a 3-parameter sanitizer with no output schema and no annotations, the description supplies the security policy, the repair set, and the return payload plus warnings. An agent can decide to call it and predict the outcome; only error-vs-sanitize semantics remain unstated.

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 defines svg, size and color with examples and injection behavior. The description echoes 'injects color/size' without adding syntax, defaults, or edge-case semantics beyond the schema, so baseline 3 applies.

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

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

The description opens with a specific verb chain (validate, sanitize, normalize) and a concrete resource (SVG icon), then enumerates exactly what is checked and what is injected. It implicitly positions itself downstream of generation ('AI-generated') but never names the sibling g_generate, so it stops short of full 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?

Usage context is implied by 'AI-generated (or any hand-written) SVG icon' and the returned 'cleaned SVG ready for use', which suggests calling this before embedding an icon. However there is no explicit when-to-use statement relative to g_generate or i_download_svg, and no when-not guidance.

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

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

No annotations are supplied, so the description carries the full burden. It makes clear this is a non-mutating status check, which is useful, but it does not say what the result looks like (boolean, user object, error on failure) or whether it can trigger any auth flow.

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?

A single front-loaded sentence with no filler. It is appropriately short for a no-argument check, though it could have spent one more clause on the outcome without becoming bloated.

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

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

For a zero-parameter status check with no output schema, the description is adequate but leaves the return value and failure behavior unstated, which matters when the agent must branch on the result. It also omits any reference to the parallel ov_check_auth sibling.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no inputs 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?

States a specific verb ('check') and resource ('logged in to iconfont.cn'), so the agent knows exactly what is being verified. It does not mention the near-identical sibling ov_check_auth, so the distinction between the two is left implicit.

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?

There is no explicit guidance on when to call this versus i_login, i_login_wait, or ov_check_auth. An agent can infer it is a precondition check before login-gated operations, but that is inference rather than stated 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, the description carries the full disclosure burden and does reasonably well: it names the exact probes (DNS resolution and TCP connectivity) so the agent knows real network traffic occurs, and it discloses the conditional output ('provides troubleshooting steps (DNS change, hosts file, VPN)') when the check fails. It omits timeout/duration behavior and whether it makes any state changes, which keeps it short of a 5.

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

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

Three short sentences, zero filler. The purpose is front-loaded in sentence one, the method in sentence two, and the failure-path behavior last — an ordering that matches how an agent decides to call and then interprets the result.

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

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

For a zero-parameter, read-only diagnostic with no output schema, the description covers what is probed and what a failure yields, which is enough to call it correctly. The only meaningful gap is the success-case return signal (what 'reachable' looks like) and expected latency, which an agent may want before invoking it in a flow.

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 takes zero parameters, so there is no parameter semantics to add beyond the schema; the baseline for a no-param tool is 4. The description correctly presents it as a targetable, argument-free check (host is implied as iconfont.cn), with no misleading implication that arguments are accepted.

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

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

States a specific verb and resource ('Check if iconfont.cn is reachable from this machine') and names the mechanism ('Tests DNS resolution and TCP connectivity'), which cleanly separates it from siblings like i_check_auth (credential state) or i_login (session establishment).

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

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

Usage is implied rather than stated: an agent can infer this is a diagnostic to run when network problems are suspected, but the description never says when to run it (e.g., before i_login, after a failed i_download) or what alternative tools to use instead. There are no exclusions and no sibling routing.

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

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

With no annotations, the description carries the full burden, and it does disclose the key non-obvious trait: there is no per-icon detail endpoint and the data comes from the search cache. That implies staleness and failure modes an agent would otherwise not anticipate. It omits what the response contains and how it behaves when the cached entry is gone.

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

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

Two sentences, no filler, and the purpose is front-loaded ahead of the constraint. The parenthetical is doing real explanatory work rather than padding.

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?

There is no output schema, so the description is the only place a caller could learn what 'detailed information' means, and it never says which fields come back. The cache-dependency is well covered, but the return shape is left entirely to discovery. Adequate for invocation, incomplete for a tool whose whole value is the returned detail.

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% and there is a single required id, so the baseline would be 3. The description adds meaning beyond the schema by scoping the id to a search-cache-derived identifier, which explains why an id from elsewhere may fail. That is genuine added semantics rather than restating the schema.

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

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

States a specific verb and resource: 'Get detailed information about an icon on iconfont.cn'. That clearly separates it from i_search (which finds icons) and i_download_svg (which fetches assets). It stops short of naming a sibling explicitly, but the resource is distinctive enough that an agent can place it without opening a schema.

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?

Gives a hard precondition: the icon MUST have been returned by a recent search call. That is a real routing rule and prevents the agent from calling it with an arbitrary id. It does not, however, say when to prefer this over just reading the search result payload, nor what to do if the cache entry is stale.

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 supplied, the description does carry the useful facts that output is SVG text and that color/size are overrides rather than requirements. It does not disclose error behavior for unknown sources, authentication or plan requirements, or whether results are cached — meaningful gaps for a 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?

Four short sentences, front-loaded with the core action and followed by parameter notes and discovery pointers. No sentence is filler; the sibling-tool references double as usage guidance.

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 four-parameter read tool with no output schema, the description covers the return type (SVG text), the two required ids and where to get them, and the optional overrides. It would be complete with a note on failure modes or scope limits (e.g., private/project icons versus global sources).

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 all four parameters are already documented with examples and defaults, making 3 the baseline. The description adds only a little beyond the schema: it clarifies that color affects stroke/fill and size affects width/height, and that id comes from search results.

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?

"Download an icon as SVG text from ANY registered source" gives a specific verb, resource, and output format, and the "ANY registered source" phrasing separates it from source-scoped siblings. The one gap is the near-identical sibling i_download_svg, which the description never mentions or contrasts with, leaving an agent to guess which download tool to pick.

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

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

It explicitly routes the agent: use i_sources to discover valid source ids and i_search_all to obtain icon ids, which covers the prerequisite workflow for both required parameters. It stops short of stating when NOT to use it (e.g., versus i_download_svg) or what happens on an invalid source/id.

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 supplied, so the description carries the full disclosure burden. It usefully reveals the cache-backed retrieval mechanism and the absence of a detail endpoint, but says nothing about authentication, what happens when the ID is no longer cached, or whether the cache expires.

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 purpose and the critical precondition are front-loaded, and the four sentences are dense with useful content. The parenthetical explanation is justified because it explains a nonobvious retrieval constraint, though the phrasing could be tightened slightly.

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 three-parameter read tool with no output schema and no annotations, the description covers purpose, precondition, and both optional overrides adequately. It omits failure behavior for uncached or expired IDs, which matters given the cache dependency it introduces.

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's notes on color overriding fills and size overriding width/height largely restate the schema text, adding little new meaning beyond confirming the ID must come from search.

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

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

States a specific verb, resource, and return format: 'Download an icon as SVG text from iconfont.cn.' The output format (SVG text rather than a file) distinguishes it from a naive reading of the name and from siblings like i_download and l_download_svg.

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?

Gives an explicit precondition: the icon MUST have been returned by a recent search call, since there is no per-icon detail endpoint. It also tells the agent to pass an ID from search. It stops short of naming when to choose i_download or l_download_svg instead.

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 supplied, the description carries the behavioral burden and does add real context: no login is required and the response is a static guide rather than live data. It does not mention size, caching, or that the guide may go stale relative to actual tool behavior, which keeps it short of a 5.

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

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

Three short sentences, front-loaded with what is returned, then the call condition, then the auth note. No filler and no repetition of the tool name as a substitute for a description.

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

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

For a zero-parameter, no-output-schema meta tool, the description supplies everything an agent needs: what it returns, when to call it, and that no authentication step is required first. Nothing further is needed to invoke 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?

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning the description could add or omit. Nothing in the schema needs compensating for.

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

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

The description names a specific verb and resource ("Return the usage guide") and enumerates its contents (tool list, login flow, search→download workflow, key rules), which clearly separates it from the many action-oriented siblings like i_search, i_login, and i_download.

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

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

It gives an explicit trigger condition: "Call this first if unsure how to use the tools." That is clear when-to-use guidance, but it names no alternative or when-not-to-call case (e.g., that it is unnecessary once the workflow is known).

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 and no output schema, the description carries the full burden, yet it discloses nothing about return shape (collection names, IDs, counts), result limits, pagination, or whether network/login state is required. Given the presence of i_check_network, i_check_auth, and i_login siblings, the absence of any auth or connectivity precondition note is a real 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?

One short, front-loaded sentence with zero filler or repetition. It is efficient, though the terseness leaves room that could have been spent on differentiation instead of nothing.

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 one-parameter read tool with a fully documented schema and no output schema, the definition is minimally sufficient to attempt a call. It falls short of complete because it never clarifies how results relate to the other collection/search tools or what a caller should expect back.

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 is a single required parameter whose schema description ('Search keyword for collections') fully covers it at 100% coverage, so baseline 3 applies. The description adds nothing beyond that, such as matching behavior or whether empty/partial keywords are meaningful.

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 gives a specific verb ('Search') and resource ('icon collections') plus the target site, so an agent knows it queries collections rather than individual icons. It does not distinguish itself from the many search-like siblings (i_search, i_search_all, l_search, l_list_all), leaving the boundary implicit.

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?

There is no guidance on when to choose this over i_search, i_search_all, or l_list_all, and no prerequisites or exclusions are stated. The agent must infer from the resource name alone that this is the collection-level search entry point.

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

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

With no annotations, the description carries the full burden. It usefully discloses that no login is required and that the operation lists icons, but it does not explain return shape, pagination, error behavior for invalid URLs, or any 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?

Two short sentences, front-loaded with the action and resource. The login-free note is compact and no wording is wasted.

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

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

For a simple one-parameter listing tool, the description is nearly sufficient: it states the action, input source, and login requirement. It could say more about what is returned, but with such low complexity the core call requirements are covered.

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

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

The input schema already documents the sole parameter at 100% coverage, including a CDN Symbol JS URL example. The description reinforces that the parameter is a Symbol URL but adds no meaning beyond the schema.

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

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

The description states a specific verb and resource: list all icons in an iconfont.cn project via its Symbol URL. It is clear enough to distinguish from login and download siblings, though it does not explicitly contrast with listing-oriented siblings such as l_list_all.

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 'No login required' note gives useful context for when this tool is appropriate, but the description does not name alternatives or state when not to use it. Usage is implied rather than explicitly guided.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the server is short-lived ('serves it for a few seconds, then shuts itself down'), pre-empts a confusing failure ('a later "connection refused" on that tab is normal'), and states that cookies are captured automatically. It does not mention failure modes such as port conflicts or the case where no browser is available.

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?

Front-loaded with the action and the returned URL, then proceeds stepwise through the user flow and the follow-up call. It is slightly long and the parenthetical about the shutdown is wordy, but every sentence supplies information an agent needs to sequence the flow correctly.

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?

There is no output schema, and the description supplies the return value (the URL), the human-in-the-loop procedure, the expected post-login page state, and the required follow-up tool calls. For a one-optional-parameter tool this covers everything an agent needs to invoke and complete the flow.

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 single optional 'port' parameter is fully documented in the schema (100% coverage, default 7788), so the schema already does the work. The description never mentions the port or when a caller would override it, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('Start a local reverse-proxy login server for iconfont.cn') plus the return value ('return its URL'). It is clearly distinguishable from the sibling login variants (i_login_with_password, i_login_with_cookie, i_login_with_sms) because it is a browser-driven flow, and it explicitly labels itself the recommended method.

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?

Gives a clear when-to-use signal ('This is the recommended login method') and an explicit next step ('Then call i_login_wait (or i_check_auth) to confirm'). What is missing is an explicit exclusion, e.g. when a headless or credential-based sibling such as i_login_with_password should be chosen instead, which the 'open in your normal browser' requirement only implies.

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

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

With no annotations, the description carries the burden and does disclose real behavior: it opens a browser, triggers an outbound SMS to a real phone number, and the resulting code expires in 3 minutes. It omits rate limits, SMS cost, and whether a browser session must remain alive between the two calls.

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 short sentences, front-loaded with the purpose before the handoff instruction, with no filler. Slightly compressed phrasing ('fills the phone number') costs a bit of clarity but no real 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?

For a one-parameter, no-output-schema step tool, the description covers the essential contract: what it does, what it produces (an SMS code), and the time-bounded next step. Failure modes (invalid number, browser launch failure) and return payload shape are left unstated but are secondary.

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 is a single parameter at 100% schema coverage, and the schema already explains that it is the phone number that receives the code. The description adds nothing further about format, country code, or validation, so the baseline 3 applies.

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

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

States a specific action set (opens a browser, fills the phone number, requests a verification code) and labels itself 'Step 1 of SMS login', which cleanly separates it from the sibling i_login_with_sms that consumes the code. An agent can identify the tool and its role in the flow without opening the schema.

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 specifies the follow-up: call i_login_with_sms with the received code within 3 minutes. That is strong sequencing guidance, but it never names when NOT to use this (e.g., i_login_with_password or i_login_with_cookie alternatives) or what to do if the SMS never arrives.

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

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

With no annotations, the description carries the full load and does disclose the two most important traits: the call blocks, and it destroys the server afterward (a destructive teardown side effect). It adds that login info is returned. It omits what happens on timeout expiry (error vs. partial result) and whether it is safe to call more than once.

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 short sentences, front-loaded with the blocking precondition, followed by the side effect and the return value. No filler and nothing redundant with the 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?

The blocking/teardown semantics are covered, but with no annotations and no output schema, the description should say more about the timeout failure mode and roughly what 'captured login info' contains. As written an agent knows how to invoke it but not how it fails.

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% and the single `timeout` parameter is fully documented in the schema with its default and unit. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb sequence and resource: block until the login server reports success, then shut it down, and return the login info. It also ties itself to the sibling `login` as the producer of that server, which helps distinguish it from `i_login`/`i_check_auth`. It stops short of naming which sibling to use when this isn't the right call.

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 phrase 'started by login' implies the prerequisite call, which is genuinely useful ordering guidance. However, there is no explicit when-not, no mention of the alternative login paths (`i_login_with_password`, `i_login_with_sms`, `i_login_with_cookie`), and no statement of what to do if login was never started.

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

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

With no annotations, the description must carry the behavioral load; it does disclose the hard prerequisite that the cookie must come from an authenticated session and must contain a 'ctoken' entry. It says nothing about failure behavior (invalid/expired cookie), whether the session persists across calls, or whether success is verified, which are the traits an agent most needs for an auth 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?

Two tight sentences; the mechanism and its reliability advantage are front-loaded, and the concrete DevTools path is the kind of practical detail that earns its space. No redundant restatement of the name or title.

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

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

For a two-parameter auth tool with no output schema and no annotations, the description covers the prerequisite environment, the source of the credential, and the required token field, which is enough to invoke it correctly. Only the post-login outcome (session persistence, failure signaling) is left unaddressed.

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% and already explains both the cookie format and the ctoken fallback, so the description adds no parameter meaning beyond the schema. Its mention of '(or pass ctoken separately)' simply restates the schema's fallback rule.

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

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

States a specific verb and resource (log in to iconfont.cn) plus the exact mechanism (raw Cookie header from a logged-in browser). It clearly separates itself from password/SMS siblings by framing cookie auth as the most reliable, headless-friendly route.

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?

Gives clear conditions for choosing this tool: works in headless/CI environments and is the 'MOST reliable method', implicitly steering agents away from i_login_with_password and i_login_with_sms. It does not explicitly name an exclusion case or state what to do if login is already established (i_check_auth), so it stops short of a full when/when-not statement.

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, and it discloses the nontrivial behaviors: a visible browser window is opened, the form is auto-filled, a human may be required to solve a slider/captcha, and cookies are persisted automatically after success. It stops short of stating where cookies are stored, what happens on failed login, or whether the browser stays open, which would be the remaining gaps for a mutation-style auth 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?

Three short sentences, front-loaded with the core action, then the execution model, then the exception path. Every clause carries information an agent needs; nothing is redundant.

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

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

For a two-parameter, no-annotation, no-output-schema tool, the description covers the essential unknowns: interactivity, captcha blocking, and side effect (cookie capture). It omits the post-login return contract and failure behavior, which are the last meaningful 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% and both parameters are documented in the schema, so the baseline is 3. The description only reinforces that 'account' is a phone number, adding nothing about format (with/without country code) or password handling.

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

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

States a specific verb (log in) and resource (iconfont.cn account) and pins the credential mechanism to phone number + password, which implicitly separates it from the SMS and cookie siblings in the toolset. An agent can pick this tool over i_login_with_sms or i_login_with_cookie from the description alone.

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?

Use-when is implied by the credential requirement (you must already hold a phone number and password), but the description never names the alternatives it exists alongside or states exclusions such as 'use i_login_with_cookie if a session already exists'. The captcha sentence describes handling, not 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, the description carries the full behavioral burden. It does disclose the key side effect – cookies are captured automatically on successful login – which is the most important thing an agent needs to know about session state. It says nothing about what happens on an invalid or expired code, whether retries consume the pending code, or any rate limiting.

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 short sentences, front-loaded with the step position and immediately followed by the prerequisite sibling and the success side effect. No wasted wording.

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 one-parameter, no-output-schema tool the description covers the essential pieces: prerequisite, input source, and post-login session behavior. Only failure-mode guidance is missing, which is a modest gap rather than a blocker.

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% and the single parameter is already documented as the SMS verification code received on the phone. The description adds no format, length, or freshness detail beyond that, so the baseline 3 applies.

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

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

States a specific action (submit the SMS verification code) and positions itself as step 2 of the SMS login flow. The prerequisite sibling login_send_sms is named, which distinguishes it from i_login_with_password and i_login_with_cookie. It stops short of explicitly ruling out i_login_wait or i_login, but the resource is unambiguous.

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 when-to-use condition is explicit: call this after login_send_sms with the code received on the phone. No exclusion is stated for the password or cookie login siblings, but the sequence requirement effectively routes the agent to the correct flow.

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 disclosure burden. It usefully reveals non-obvious downstream behavior: illustration results are original SVGs that cannot be recolored, and icon downloads require a recent search. It omits whether a search requires login/auth, what a result record contains, and any rate limits, which are significant gaps for a no-annotation 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?

Three dense sentences, front-loaded with the core action and the type semantics before the download caveats. The second sentence's nested parenthetical is slightly tangled but nothing is redundant.

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 4-parameter, no-output-schema search tool, the description covers type semantics and the handoff to i_download_svg, which is the key workflow an agent needs. It would be stronger if it sketched what the results contain so the agent knows what IDs/URLs it can pass downstream.

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%, so keyword, page, pageSize and the type enum are already documented in the schema; baseline 3 applies. The description adds only marginal meaning, mainly the color-override caveat for illustration results, which is more a downstream behavior than a parameter semantic.

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

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

States a specific verb (Search) and resource (icons OR illustrations on iconfont.cn) and clarifies the two content types. It does not differentiate itself from plausible siblings such as i_search_all or l_search, so an agent cannot rule those out from the description alone.

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?

Gives explicit when-to guidance for the type parameter ("Set type='illustration' for multi-color artwork") and states the required follow-up workflow ("Icons must be downloaded via i_download_svg with a recent search"). It stops short of naming any alternative or exclusion, e.g. versus i_search_all or l_search.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses default scope, the source-labeling of merged results, and a login prerequisite for one source, but says nothing about pagination semantics across multiple sources, failure behavior when a source is unauthenticated, or result ordering/merging rules.

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?

Front-loaded with purpose then defaults, four short sentences, no filler. There is mild redundancy between "Search icons across ALL... sources" and "By default searches all sources," which costs it a point but does not obscure meaning.

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 4-parameter federated search with no output schema and no annotations, this covers purpose, defaults, source keywords, auth prerequisite, and roughly what comes back. Remaining gaps are pagination interplay across sources and error behavior for the login-gated source, which are secondary but would matter operationally.

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%, so the baseline is 3, but the description adds genuine meaning beyond the schema by defining the special source keyword values "free" (all open sources) and "all" (everything), which the schema's plain id-list example does not convey. It adds nothing for page or pageSize, which the schema already documents.

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

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

States a concrete verb and resource: "Search icons across ALL or specific data sources," and the word "ALL" plus "combined results with source labels" signals a federated search, which differentiates it from a single-source sibling like i_search. It never names i_search explicitly, so the contrast is implied rather than stated.

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?

Gives actionable usage context: default is all sources, use the sources parameter to narrow, shorthand keywords "free" and "all" exist, and Iconfont requires login. It also points to i_sources for valid ids. What's missing is guidance on when to pick this over i_search or i_list_collections for the same intent.

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 supplied, so the description carries the full disclosure burden. "List" implies a read-only operation and the parenthetical reveals the returned attributes, including that some sources have an auth requirement, but there is no statement about network calls, caching, failure behavior, or whether logged-out state truncates results.

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, front-loaded with the action and result shape, then the purpose. No redundant restatement of the tool name and no filler.

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

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

With no output schema, the description must convey return values, and it lists the four key attributes. It omits the source identifier/name field an agent would need to pass into i_search, leaving a small gap for a discovery tool whose output feeds other calls.

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 takes zero parameters, which is the baseline-4 case: there is nothing for the description to disambiguate beyond the empty schema it already has.

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

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

States a specific verb and resource ("List all available icon data sources") and enumerates what each entry contains (icon count, license, auth requirement, status). That distinguishes it from the sibling search/download tools, which consume the sources this tool enumerates.

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?

"Use this to discover which sources are available for search and download" gives a clear entry-point context and implicitly routes the agent to i_search/i_download afterward. It does not state exclusions (e.g. whether it is safe to call before login), but the intended moment of use is unambiguous.

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

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

With no annotations supplied, the description carries the full burden, and it does disclose one important behavioral trait: an outbound check against GitHub. It says nothing about network failure behavior, latency, authentication, or whether the GitHub check is optional or rate limited — meaningful gaps for a tool that reaches an external service.

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?

A single sentence with zero filler, front-loading the primary return value before the secondary GitHub comparison. Nothing could be cut without losing 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 zero-parameter, read-only version probe with no output schema, the description covers both the local version and the remote comparison, which is what an agent needs to decide to call it. It falls short only on what happens when the GitHub check fails or how the result is shaped.

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 takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter meaning is missing.

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 gives a specific verb and resource ('Return the current version of this freeicon MCP server') plus a secondary behavior ('check if a newer version is available on GitHub'). No sibling tool in the list does version reporting, so differentiation is implicit rather than stated.

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

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

Usage is only implied: an agent can infer this is for checking server version or update availability. There is no explicit statement of when to prefer it over nothing, no prerequisites, and no note about whether it should be called before updating or troubleshooting.

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 supplied, the description does add two genuinely useful behavioral facts: the return is SVG text (not a URL or binary) and no login is required ("open source, no login"). It stops short of disclosing failure behavior for unknown icon names, rate limits, or whether size/color alter the returned markup — the kind of detail that matters for a mutation-free but parameterized fetch.

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

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

Two sentences, no filler, with the identifying source prefix front-loaded and the alternative-tool pointer placed last. Every clause earns its place.

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

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

For a simple three-parameter read tool, the description plus fully documented schema covers what an agent needs: what it returns, that no auth is needed, and where to go for multi-source downloads. Without annotations or an output schema, a brief note on how the SVG text is delivered would have closed the remaining gap.

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 name, size, and color are already documented with examples in the schema. The description contributes no additional meaning about defaults, units, or what happens when size/color are omitted. Baseline 3 applies 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?

"[Lucide] Download a lucide icon as SVG text" gives a specific verb (download), resource (a Lucide icon), and output form (SVG text), plus the source library in brackets. It does not explicitly contrast with the near-identical sibling i_download_svg, so the agent must infer that the l_ prefix means Lucide and the i_ prefix means the other source.

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

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

It names a concrete alternative and the condition that selects it: "For unified download from any source, use i_download instead." That is clear routing guidance. The gap is that it never says when to prefer this over i_download_svg, the sibling it most closely resembles.

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 supplied, the description carries the full burden, and it does add one real behavioral fact: no authentication or login is required, unlike the i_login/ov_login siblings. It does not state whether the call is read-only or what the tags response looks like, leaving gaps for a 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?

One sentence, front-loaded with the action and resource, with the qualifier in parentheses. No wasted wording, though the parenthetical is compressed to the point of terseness.

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 one-parameter read tool with no output schema, the description covers what it does and the auth situation, but never indicates what a caller gets back (a tag list, tag names, or counts). That is a modest but real gap in an otherwise simple definition.

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 single parameter has 100% schema description coverage with a concrete example ("home", "arrow-right"), so the schema already does the work. The description adds nothing about the name parameter, which is acceptable at this coverage level but not additive.

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

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

The description names a specific verb and resource ("Get tags for a specific lucide icon") and the "[Lucide]" prefix distinguishes it from the iconify-family siblings (i_search, i_detail). It does not explicitly name a sibling alternative, but the namespace framing makes the family boundary clear.

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?

There is no guidance on when to call this versus l_detail, l_search, or l_list_all, all of which plausibly surface icon metadata. The "open source, no login" note implies availability but says nothing about selecting this tool over its 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 supplied, so the description carries the full burden, and it does add one genuinely useful behavioral fact: no login is required, so i_login/ov_check_auth flows can be skipped. It says nothing about what a result entry contains (names only? SVG bodies?), whether ordering is stable, or that the 2007+ icon catalog is paginated rather than returned whole.

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?

A single front-loaded sentence with the scope constraint and the auth fact packed into it; nothing is redundant or padded.

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

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

For a simple two-parameter list tool with full schema coverage and no output schema, the definition is mostly sufficient, but it omits the one thing an agent needs to plan around: the catalog is 2007+ items against a default page size of 50, so multiple calls are required.

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

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

Schema description coverage is 100% — both page and pageSize are documented with defaults and the 200 max — so the baseline is 3. The description adds no guidance on traversal, such as roughly 40 pages of 50 being needed to enumerate 2007+ icons.

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

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

States a specific verb and resource ("List all available lucide icons") and the bracketed "[Lucide]" prefix separates it from the Iconify-prefixed siblings. It remains ambiguous versus the sibling l_search, which also operates on the Lucide catalog, so the listing-versus-searching distinction is only implied by the word "all".

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

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

Usage is implied rather than stated: "List all" suggests catalog browsing, and "(open source, no login)" hints that no authentication step is needed first. It never names an alternative such as l_search for targeted lookups or l_get_tags for filtering, and gives no condition for choosing between 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the source is open source and requires no login, and gives a corpus size of 2007+ icons, but says nothing about result shape, pagination limits, or whether search matches tags versus names.

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?

Short and front-loaded: action and scope first, then the alternative routing advice. The middle sentence about the Feather fork and icon count is mild filler but still helps an agent recognize the icon source, so it earns marginal keep.

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?

This is a simple keyword search with a fully documented schema and no output schema, and the description covers purpose, auth-free access, and the multi-source alternative. Only the return format remains unstated, a minor gap for such a lightweight tool.

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

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

Schema description coverage is 100% and all three parameters (keyword, page, pageSize with max 100) are documented inline, so baseline 3 applies. The description adds no extra meaning about keyword syntax, matching behavior, or paging semantics beyond the schema.

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

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

States a specific verb and resource plus its scope: '[Lucide] Search lucide icons by keyword.' The bracketed source tag and the explicit contrast with multi-source search let an agent distinguish it from the many i_* siblings without opening a schema.

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?

Names a concrete alternative and the condition that selects it ('For multi-source search, use i_search_all instead'), and notes 'no login' required. It does not address related Lucide siblings such as l_list_all, l_get_tags, or l_download_svg, so routing is clear but not exhaustive.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses the two possible states and the concrete rate limits attached to the anonymous mode, which is real value. However, it does not state that the call is side-effect-free/read-only, nor what the response looks like (flag? message?), leaving the outcome shape to inference.

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?

A single sentence, front-loaded with the verb and subject, with the rate-limit detail placed as a parenthetical clarification. No filler or redundancy. Size is well matched to the tool's simplicity.

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

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

For a zero-parameter diagnostic with no annotations and no output schema, the description conveys what is being probed and the practical meaning of each outcome (rate-limit tiers). Only the exact return format and the recommended next step when unauthenticated are missing, which is a minor gap at this complexity level.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No misleading parameter hints are present.

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

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

The description names a specific check ('whether Openverse API credentials are configured') and pairs it with the observable consequence: authenticated rate limits versus anonymous '20/min + 200/day'. A reader knows exactly what the tool reports. It stops short of naming a sibling to contrast with (e.g. ov_login / ov_register), so it is clear but not fully 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?

Usage is only implied: the mention of credentials and rate limits suggests calling it before or when hitting throttling, but there is no explicit 'use this when...' or 'do not use for...' guidance. No prerequisites or follow-up actions (e.g. call ov_login if unconfigured) are 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?

No annotations are provided, so the description carries the full burden, and it meets most of that burden. The description discloses that the credentials are persisted, that the exchange is validated immediately, and that anonymous access remains available. It is missing details on where credentials are stored, whether they overwrite prior ones, and what happens on invalid input, which prevents a 5.

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?

It is written in three dense sentences that each add value: what the tool does, the rate-limit payoff, the prerequisite URL, and the fallback behavior. The information is front-loaded, with no filler.

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

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

For a two-parameter tool with no output schema, the description covers the essential context: the purpose, the rate limits, the prerequisite, and the fact that the credentials are verified. The only gap is that it does not describe the failure mode for invalid credentials, which keeps it from a 5.

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%, and both parameters are already documented as the Openverse client_id and client_secret. The description adds nothing parameter-specific beyond the schema, so the baseline 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 states a specific verb and resource: 'Save Openverse API credentials (OAuth2 client_id/client_secret)', and it quantifies the benefit (rate limits from 20/min + 200/day to 100/min + 10,000/day), so the agent knows exactly what the tool does. It does not explicitly differentiate itself from the closely related siblings ov_register and ov_check_auth, which keeps it from 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?

It states clearly when to use the tool: when you want higher rate limits, and it names the prerequisite (register an app at https://api.openverse.org/v1/). It also says the tool is optional because 'anonymous access keeps working without this'. It could go further by pointing to ov_check_auth or ov_register, but the usage context for this tool alone is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool hits the public API, creates an application, persists credentials, and triggers a verification email. It also clarifies a non-obvious behavioral detail — the emailed link is recommended but credentials work immediately. It does not say what happens on repeat invocation when credentials already exist, which is the main remaining 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 core action and its payoff are front-loaded, and the exclusion of ov_login closes the description cleanly. It is dense but every clause (rate numbers, email link, immediate validity) carries information an agent needs; the em-dash chain is slightly packed but not wasteful.

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?

There is no output schema, and the description compensates by describing what the tool produces (client_id/client_secret, an exchanged token, saved credentials) and the side effect of an email. For a two-parameter registration tool that is nearly complete; only the storage location of the saved credentials and repeat-run behavior are left unspecified.

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 both the email and name parameters are already documented, including the default of 'freeicon-mcp'. The description restates that the email receives the verification link but adds no format, validation, or behavioral nuance beyond the schema, so the baseline 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 names a specific verb and resource ('registers an application' on Openverse) and spells out the full flow: register, receive client_id/client_secret, exchange for a token, save credentials. It also explicitly distinguishes itself from the sibling ov_login, so an agent can tell the two apart without opening either schema.

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

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

It gives a concrete reason to call it (rate limits jump from 20/min + 200/day to 100/min + 10,000/day) and an explicit alternative with a condition: 'If credentials already exist, use ov_login instead.' The when-not case is stated; the when case is conveyed through the benefit rather than a direct instruction, which keeps it just short of a perfect 5.

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