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 add genuine context beyond the schema — the live auth state (未登录) and the fact that other tools are blocked until this runs — but it never explains how login actually works, whether credentials or a browser flow are required, or what the result looks like.

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: identity, then the blocking state, then the call to action. No wasted sentences, though the emoji-laden formatting adds noise rather than 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 single-parameter, no-output-schema auth gate the description covers the essential precondition and current state. It still leaves open what a successful login entails (credential source, redirect, session persistence) and what happens after logout, which matters for an authentication tool.

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

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

Schema coverage is 100% and the enum values are fully documented in the schema itself, so the description's operation list is largely redundant. It also adds nothing about the default or the meaning of logout, and actually lists fewer actions than 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?

It states a specific verb+resource (authentication management) and enumerates the operations (login, status), making it instantly distinguishable from siblings like uno_call_tool or uno_search_tools. It loses a point for omitting logout from the listed operations even though the schema's enum includes it, creating a small internal mismatch.

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 prerequisite condition — call this before the other tools. It supplies a clear when-to-use context without naming alternatives, which is reasonable for a gating auth tool.

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

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

With no annotations, the description carries the load well: it discloses automatic connection creation, the OAuth auth_required/auth_url round-trip, the retry requirement, and the rating_hint side-effect. It does not cover failure/error semantics for tool execution itself, which keeps it from 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?

Bracketed sections front-load identity format, then connection behavior, then workflow, then follow-up scoring. Each block is short and every sentence earns its place; nothing is 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?

For a two-parameter dispatcher with a nested free-form arguments object and no output schema, the description covers format, auth, and lifecycle sufficiently. It stops short of describing error handling or response shape, but rating_hint is noted as the notable return signal.

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 value with concrete tool_name examples (amap-maps.maps_weather, time.get_current_time) and clarifies that arguments follow each tool's own inputSchema — information the schema text alone does not supply.

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+resource (执行 MCP Server 上的具体工具) and immediately defines the identity format for the target tool. The typical-flow section makes clear how it differs from the search/routing siblings (uno_search_tools finds, uno_call_tool invokes).

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 【典型流程】 block explicitly routes the agent: search first, then call, then rate with uno_rate_server. It also distinguishes normal vs OAuth servers and tells the agent to retry after browser authorization, which is exactly the when/when-not guidance needed.

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 so: it discloses the divergent return behavior (full tools+inputSchema vs auth_url), the multi-step authorize-then-retry pattern, and the follow-up action of using uno_call_tool. This is behavioral context an agent cannot get from the schema.

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

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

Sectioned as 使用场景 / 返回内容 / OAuth 流程, which is well front-loaded and scannable. It is somewhat long for a single-parameter tool, but nearly every sentence carries distinct information, so little 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?

No output schema exists, yet the description explains both possible return shapes (tool list or auth_url) and the required re-invocation after authorization. Combined with usage scenarios and the flow, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the parameter is documented there with examples; the description reinforces the parameter by using server_name in the flow but adds no new syntax or constraint. 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 (连接/connect) and resource (指定 MCP Server), plus the secondary purpose of handling OAuth authorization. It explicitly contrasts with uno_call_tool in step 4 of the OAuth flow, so an agent can distinguish it from siblings without opening schemas.

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 two explicit when-to-use scenarios (uncached servers needing auth from uno_search_servers, and known server names where full tool definitions are wanted) and a numbered OAuth flow that shows exactly when to call versus re-call versus delegate to uno_call_tool.

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

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

No annotations are provided, so the description carries the full burden. It correctly frames this as a read-only balance query and discloses the return contents plus the recharge_url follow-up action. It omits any note on auth requirements or rate limits, which keeps it from 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 the purpose before the return contents and the follow-up action. Every sentence earns its place 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?

There is no output schema, so the description appropriately enumerates the return fields (current credits, daily free quota, total consumed, recharge link). For a zero-parameter read tool this is essentially complete, though it could mention auth or failure modes.

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 per the rubric sets the baseline at 4; there is nothing for the description to compensate for. The description's mention of recharge_url is about a return value, not an input, so it adds no parameter meaning.

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 (查询工具调用积分余额) and even enumerates what is returned. It is clearly distinct from siblings like uno_search_tools or uno_call_tool, but it never explicitly names or contrasts with them, 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?

Gives clear contextual guidance: when credits are insufficient, direct the user to recharge via recharge_url. It does not state any when-not conditions or name a specific alternative tool, but for a simple balance query this context is sufficient.

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 burden, and it does disclose a real behavioral consequence: submitted scores influence search recommendation ranking. It does not state whether a new rating overwrites a prior one, whether authentication is required, or whether rating is idempotent. The ranking-impact disclosure is the significant piece and it 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 content is front-loaded: the action and its consequence come first, then the tool/skill branches are bulleted, then the scoring guidance. It is compact and every line carries actionable information, with only minor redundancy between the bullet list and the scoring sentence.

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

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

For a 5-parameter mutation-ish tool with no annotations and no output schema, the description covers purpose, trigger, target selection, and score semantics adequately. It does not say what a successful rating returns or whether repeated ratings replace earlier ones, which are the remaining gaps.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description earns above that by explaining the intent-to-parameter mapping: pass tool_name for tools (with a fully qualified server.tool example) and skill_id for skills. The legacy server_name parameter is left to the schema only, which is the sole gap.

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

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

The description opens with a specific verb+resource: giving a rating/feedback after using a tool or skill, and immediately states the consequence (ratings affect search recommendation ranking). It also disambiguates the two rating targets (tool vs skill) via named parameters, so an agent can distinguish this from siblings like uno_search_tools or uno_call_tool 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?

It gives explicit triggering conditions: rate after a successful call, use the 4-5 range when satisfied and 1-2 when not, and rate proactively when a rating_hint is received. It also routes the agent between tool_name and skill_id depending on what is being rated, which functions as the when-to-use branch.

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, and it does well: it discloses that results include inputSchema, that some servers are OAuth-gated ('uncached', requiring uno_connect_server), and it explains the meaning of the statistics fields (calls_7d/rating/avg_ms). It stops short of covering error behavior, rate limits, or latency caveats, so it is strong but not exhaustive.

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 uses bracketed sections (可用资源/用法/返回内容/工作流) that make it skimmable and scannable. Slightly verbose with repeated tool-name spellings in the examples, but every section 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?

No output schema exists, yet the description fully describes the return shape (tools with tool/desc/inputSchema, uncached OAuth list, statistics), the auth follow-up path, and the end-to-end workflow. For a discovery/routing tool this is complete enough to call correctly on the first try.

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 baseline is 3, but the description adds real value beyond the schema by showing worked examples of query semantics (natural-language queries), the practical difference between mode values, and category strings. It does not elaborate on limit beyond what the schema already says.

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?

Opens with a precise verb+resource ('搜索 MCP 工具' / search MCP tools) and immediately states the scope (144 MCP servers) plus what is returned ('最相关的 tools 及完整参数定义'). An agent can distinguish this from search-oriented siblings like uno_skills_search because the domain (MCP tools vs skills) and the immediate-callability of results are named.

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

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

Provides three explicit invocation patterns with concrete argument examples (keyword, semantic/hybrid, category browse) and a named end-to-end workflow ending in uno_call_tool. The mode distinction ('keyword 精确/快' vs 'semantic 语义理解' vs 'hybrid 推荐') tells the agent exactly which mode to pick for which query shape.

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 at all, the description carries the full behavioral burden and mostly succeeds: it details the returned fields and adds a useful operational hint that executable-script skills can be retrieved as a full ZIP via download_url. It does not mention auth requirements, rate limits, or confirm the read-only nature explicitly, leaving a minor 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?

Front-loaded with the purpose and usage order, then a scannable bulleted breakdown of return fields plus one actionable download note. No filler sentences, though the bullet list is slightly more verbose than strictly necessary.

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?

Because there is no output schema, the description appropriately compensates by enumerating the returned fields, and the single parameter is fully covered by the schema. It is complete for invocation, with only peripheral gaps (auth, limits) that a fetch tool ideally would mention.

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% for the single skill_ids parameter, including the maxItems=10 constraint and the note that IDs come from uno_skills_search results, so the schema does the heavy lifting. The description's only addition is the implicit 'batch' framing, which the schema already conveys via the array type.

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+resource: batch-fetching full content of skills, with an explicit distinction from the uno_skills_search sibling that only searches. It also enumerates exactly what 'full content' means (skill_md, files, download_url, repo_url), so an agent knows the payload shape before 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?

It explicitly names the predecessor workflow ('通常在 uno_skills_search 后使用'), routing the agent to search first and fetch second. It does not state when-not to use it or address precedence relative to other data-returning siblings, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the return shape (meta + quality signals) and enumerates every returned field including stars/forks/token_count as quality signals. It omits whether the operation is read-only, result ordering/ranking behavior, and pagination, which are gaps but minor for a search 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?

Well-structured and front-loaded: purpose, usage scenario, and next-step routing come first, followed by a scannable field-by-field return list. The field enumeration is slightly verbose but each entry earns its place by explaining 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?

There is no output schema, and the description compensates by explaining every returned field and the search→fetch workflow. Combined with the usage scenario and alternatives, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents query, limit (default 20, max 20) and category. The description adds no syntax or format detail beyond what the schema provides, 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?

The description states a specific verb and resource: 语义搜索 (semantic search) over Cursor Agent Skills, from thousands of entries. It clearly distinguishes itself from siblings by noting it returns meta/quality signals and that uno_skills_fetch retrieves full content, so an agent can tell it apart from uno_search_tools and uno_skills_fetch.

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 usage scenario (当你需要一个「能力/指南/工作流」而不是单个工具时) and names the follow-up tool uno_skills_fetch for retrieving full content. It implies the alternative for single tools without naming uno_search_tools explicitly, so it stops just short of full when-not guidance.

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