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

With no annotations, the description carries the full behavioral burden. It discloses the core check (login state validity and qualified-investor data unlock), which is useful. However, it does not state what the tool returns, whether it has side effects, or what happens if the check fails.

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

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

The description is a single, front-loaded sentence that states the purpose and the key contextual detail (qualified investor data unlock). It is appropriately sized and contains 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 simple zero-parameter auth check with no output schema, the description explains what is being verified but omits what the result looks like and how to act on it. The parenthetical clarifies the gated data, but an agent still lacks return-value context.

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

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

The tool takes zero parameters, so there is no parameter semantics to document. The baseline score for zero-parameter tools is 4; the description adds no parameter-related detail because none is needed.

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

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

The description states a specific verb (验证/verify) and resource (登录态/login state) and adds the context that it checks whether qualified investor data is unlocked. It is clearly distinct from set_token in the sibling list, though it does not explicitly name alternatives.

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

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

The description gives no explicit guidance on when to call this tool versus set_token or other siblings. Usage is only implied by the purpose — an agent can infer it checks authentication status, but there is no 'use before X' or 'if invalid, do Y' instruction.

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 usefully discloses a non-obvious edge case (nav=None when the fund is absent from the ranking because the site image-ized the nav), but it is silent on auth/permission needs despite set_token/check_auth siblings implying a gated API.

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 and the id format, then return contents and the None edge case. The enumeration of returned fields (strategy, inception date, custodian, filing number, etc.) is somewhat long but each item is informative for a tool with no output schema.

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

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

With no output schema, the description responsibly enumerates the return payload and flags the nav=None caveat, which is exactly the missing structured information. The main remaining gap is auth expectation, which the sibling tools imply but the description never states.

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 0% and the single fund_id param is bare. The description compensates by giving an example identifier shape and telling the agent how to obtain a valid id via search_funds, adding meaning well beyond the empty 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+resource (query fund details) and pins the fund_id format with a concrete example (HF0000DEHO). It distinguishes itself from search_funds but not from close siblings like get_fund_returns, get_fund_performance, and get_fund_asset_size, whose data this description says it also returns (nav, YTD/inception returns).

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 parenthetical '可先用 search_funds 检索' gives a clear prerequisite/alternative for obtaining the id, which is real guidance. However, it offers no when-not-to-use or routing against the overlapping performance/returns/asset-size siblings, leaving usage only partially explicit.

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 does reveal the shape of the returned series (per-period size plus period-over-period change), which is useful, but says nothing about read-only status, authentication/token requirements (notable given the set_token and check_auth siblings), units, or date-range 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?

A single compact sentence with the key output content front-loaded and no filler. Nothing is padded, though it is arguably too terse given the missing usage and parameter detail.

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 read tool with no output schema, describing the returned series is a reasonable core, but the absence of usage context, parameter format, and any behavioral notes (auth, limits) leaves 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 0% and the description adds no meaning to fund_id — it never states whether it is an internal ID or a fund code, nor its format. With a single parameter that is the sole input, this gap is small but real, and the description does not compensate for it.

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 ('查询基金规模变动序列') and even names the returned content (各期规模与环比变化), so an agent knows exactly what comes back. It does not, however, distinguish itself from close siblings such as get_fund, get_fund_performance, or get_fund_returns.

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 indication of when to call this tool versus get_fund_performance or get_fund_returns, no prerequisites, and no exclusions. The agent must infer the selection from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the breadth of data returned but says nothing about side effects, permissions/auth requirements, data freshness, rate limits, or error behavior; 'query' implies read-only but that is inference, not disclosure.

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

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

A single front-loaded sentence with the verb first and the detailed enumeration quarantined in a parenthetical. The parenthetical is dense but every item earns its place by describing the payload, and there is 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 and no annotations, the description usefully enumerates the returned metrics and horizons, which is the main thing an agent needs to judge relevance. It is nearly complete for a one-parameter read tool, though units, currency and data recency are 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 0% and the description never mentions fund_id, so it adds no meaning beyond the parameter's already self-evident name and string type. With low coverage the description is expected to compensate, and here it does not.

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 (基金业绩/指标), then enumerates the concrete contents returned: NAV date, return/drawdown/Sharpe, multi-horizon interval returns, benchmark comparison and peer ranking. It is clear what the tool does, but it never distinguishes itself from siblings like get_fund_returns or get_ranking, which overlap heavily with the '区间收益' and '同类排名' content it claims.

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

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

No statement of when to use this tool versus get_fund, get_fund_returns, get_fund_asset_size or get_ranking, and no prerequisites or exclusions. The overlap with get_fund_returns and get_ranking is left entirely for the agent to infer.

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 the data source, that the payload is plaintext-decodable, and what each granularity returns (benchmark comparison, plus peer ranking/quartile for yearly), but says nothing about auth requirements, error behavior, or result size/pagination.

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-loads the purpose, then presents granularity semantics in a compact line, then a short usage note. No filler; only the parenthetical data-source detail is arguably extraneous.

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 2-parameter read tool with no output schema and no annotations, the description covers the return shape reasonably well (benchmark, ranking, quartile) but leaves fund_id semantics, permissions, and failure modes 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 0%, so the description must compensate. It does define the three granularity values (monthly/quarterly/yearly), which the schema leaves as a bare un-enumerated string, but fund_id — the only required parameter — gets no explanation of format or where to obtain it.

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 names the upstream data source, so the agent knows exactly what is retrieved. It does not, however, differentiate itself from the sibling get_fund_performance, which plausibly returns overlapping data.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named, despite siblings like get_fund_performance and get_ranking that could serve similar needs. Usage is only weakly implied by the granularity enumeration and the note about synthesizing a cumulative NAV curve.

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. It usefully reveals the default ordering (near-half-year returns), pagination (50 per page, ~3460 total, paginable), and the per-entry fields, but says nothing about auth requirements, rate limits, or whether results are a snapshot.

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 dense sentence that front-loads the core purpose and then the default ordering and return contents. Efficient, though it packs many clauses together.

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?

Without annotations or an output schema, the description does describe the returned fields (fund_id, nav, multi-period returns), which partly substitutes for a missing output schema. It remains silent on authentication and on distinguishing this from sibling retrieval tools, leaving real 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 coverage is 0% and the single 'page' parameter is undocumented in the schema. The description compensates partially by noting 50 records per page and that the list is paginable, implying how 'page' behaves, but adds no further syntax or bounds.

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 clarifies scope (private fund ranking, ~3460 funds). It does not explicitly distinguish itself from siblings like search_funds or get_fund_performance, so it is clear but lacks 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The default sort and page size are described, but an agent must infer when this ranking list is preferable to search_funds or get_fund_performance.

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 behavioral burden. It does disclose the return content (company_id and basic info), which is useful, but says nothing about pagination behavior despite a page_size parameter, nor about auth requirements or result 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?

A single compact sentence that front-loads the action and scope. Nothing is wasted, though brevity here is partly the result of under-specification rather than disciplined editing.

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 annotations, no output schema, and 0% schema coverage, the description should do far more. It gives the return shape at a high level but omits pagination, matching behavior (exact vs fuzzy name), and any auth or rate-limit context 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 0%, so the description must compensate. It only implies that query is a name string (按名称) and gives no explanation of page_size, its default of 10, or the pagination semantics — half the parameters remain unexplained in both places.

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 (search companies) plus the scoping criterion (by name) and even the return payload (company_id and basic info). It is clearly distinguishable from search_funds by the resource noun, though it never explicitly contrasts with that sibling.

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 when-to-use guidance, no prerequisites, and no mention of the sibling search_funds, which is the closest alternative. Usage must be inferred entirely from the name and the word 名称.

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 the shape of the result (fund_id, company, manager, dates, returns, drawdown), which compensates for the absent output schema, but it says nothing about matching behavior (exact vs fuzzy name), pagination limits, or 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?

Two tight sentences: the first front-loads the action and return summary, the second handles tool routing. No redundant phrases and nothing that fails to earn 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 two-parameter search with no output schema and no annotations, the description covers purpose, return fields, and next-step routing, which is nearly everything an agent needs. The only missing piece is pagination/limit behavior implied by page_size.

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 0%, so the description must compensate. '按名称搜索' gives implicit meaning to the required query parameter, but page_size is never explained and no format/syntax guidance is added. Query being intuitive by name keeps this from dropping lower.

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 ('按名称搜索私募基金' – search private funds by name) and enumerates the returned fields, so the agent immediately knows the operation. It also distinguishes itself from get_fund by assigning detail retrieval to that sibling, making the boundary clear 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?

It explicitly routes the agent to the follow-up tool ("后续用 get_fund 查详情"), giving clear context for when this tool's role ends and another begins. It does not, however, address when to prefer this over search_companies or other siblings, so no hard exclusions are provided.

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 does disclose meaningful behavior: the token is persisted to ~/.ppw-mcp.json and must be refreshed after expiry. It omits whether a bad token is rejected or overwritten silently, but the persistence and lifecycle behavior are genuinely useful.

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-loads the purpose, then the acquisition steps, then persistence/lifecycle. Every sentence earns its place for a credential-setting tool, though the multi-step F12 walkthrough makes it denser than strictly minimal.

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?

An output schema exists so return values need not be explained, and the description covers persistence, the acquisition path, and refresh-after-expiry. What an agent needs to call it correctly is essentially present, missing only failure/validation semantics.

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

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

With 0% schema description coverage on the single 'token' parameter, the description fully compensates by explaining the exact source (F12 -> Application -> Cookie -> http_tK_cache) and that the raw cookie value is what gets passed.

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: it saves the login credential (http_tK_cache cookie value) for 排排网. An agent can tell this persists an auth token rather than reading anything, which separates it from siblings like check_auth. It does not explicitly name a sibling, so it stops short of 5.

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

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

Gives clear context for when to invoke: after logging into simuwang.com and, crucially, again after the token expires. It does not name alternatives (e.g. use check_auth to verify validity first), but the usage trigger is unambiguous.

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