site-mcp

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

With no annotations, the description carries the full load, and it does disclose the return shape (markdown with front matter, body, and date annotation) — genuinely useful since there is no output schema. However, it says nothing about permissions, error behavior for invalid url/slug, or rate limits, so the behavioral picture is only partially filled in.

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 resource and then enumerates the returned content. There is no filler or redundancy.

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

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

Because no output schema exists, the description's enumeration of returned content (front matter, body, date annotation) is exactly the right compensation. For a simple read tool with fully documented parameters this is close to complete, though failure modes and the url/slug fallback 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 100%, and both url and slug are documented there, including the source of the url value. The description adds no semantics about when to prefer url versus slug or how they interact, 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 (取/fetch) and resource (单篇文章全文 markdown), and enumerates the content included (front matter, body, publication-date annotation). '单篇' implicitly contrasts with the plural siblings list_articles/search_articles, but no sibling is named explicitly, so it falls short of full 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?

The description gives no when-to-use or when-not-to-use guidance and never points to list_articles/search_articles as the way to obtain an article URL. The only routing hint ('url comes from list_articles/search_articles results') lives in the schema's parameter description, not in the tool description itself.

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 add real behavioral value: it discloses the return format (markdown full text) and a non-obvious versioning rule (same-day reposts do not overwrite; the first sync of the day wins). It still omits error behavior for missing dates and the read-only nature is only implied by 取.

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 a parenthetical caveat, no filler, and the resource named first. Every clause earns its place; it is about as tight as this tool needs.

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 does state what comes back (full-text markdown), which covers the main return-value question. For a one-parameter read tool the remaining gaps (error/empty-date handling, explicit read-only framing) are minor.

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 schema itself documents the accepted date formats, so the description need not repeat them. However, the description adds nothing parameter-specific beyond the schema, so this sits at the baseline for fully-covered params.

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 (取/fetch) and a specific resource (single issue full-text markdown of the 每日 AIGC 早报). The word 单期 ('single issue') implicitly separates it from the sibling list_daily_issues, but no sibling is named explicitly, so the differentiation is only implied.

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

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

The description implies you call it to retrieve one issue's full text, and the sibling set contains an obvious list counterpart, but it never says when to use this vs. list_daily_issues or search_articles. No exclusions or prerequisites are given.

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 behavioral burden. It usefully discloses sort order (发布时间倒序) and the exclusion of article bodies (不返回正文), which routes the agent to get_article for content. However, it says nothing about auth requirements, rate limits, or maximum result behavior beyond the schema's page_size cap.

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 terse, front-loaded sentences: scope+pagination first, filters second, the important exclusion (不返回正文) last. Nothing is wasted and no sentence merely restates the tool name.

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 and no annotations, so the description must carry the load, and it covers scope, ordering, filtering dimensions, and what is omitted from results. It is nearly complete for a paginated list tool, missing only guidance on choosing it over the sibling search/list tools.

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

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

Schema coverage is 100%, so the schema already documents all six parameters (q, tag, page, year, category, page_size). The description restates the filter dimensions at a high level but adds no syntax or format detail beyond the schema, matching the baseline-3 case.

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

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

States a specific verb and resource (分页浏览航通社全站文章), plus sort order and scope (全站), so an agent can distinguish it from get_article (single item) and search_articles. It stops short of naming those siblings explicitly, so differentiation is inferred 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?

The description implies the browsing use case via '分页浏览全站文章' and lists supported filters, but never says when to prefer this over search_articles or get_article. Usage is implied by scope, not spelled out as an explicit rule.

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 behavioral burden alone. It usefully discloses the sort order (date descending) and pagination support, but says nothing about permissions, result size limits beyond the schema, or that results are read-only snapshots. Adequate but thin 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?

Two compact sentences, zero waste. The core operation is front-loaded and the filtering capability follows immediately.

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 paginated list tool with full schema coverage and no output schema, the description covers purpose, ordering, and filtering. It omits guidance on when to choose this over search_articles/list_articles, which is the main 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 all five parameters (page, page_size, year, date_from, date_to) are already documented in the schema. The description restates the year and date-range filters but adds no syntax, defaults, or interaction rules 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 ('分页浏览「每日 AIGC 早报」期号') and adds the ordering semantics (date descending), which distinguishes it from the singular sibling get_daily_issue and from list_articles/search_articles. It stops short of explicitly naming those siblings, 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?

It implies a browse-and-filter use case via '分页浏览' and the filter mention, but there is no explicit when-to-use guidance, no statement of when to prefer search_articles or get_daily_issue, and no prerequisites. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden, and it does disclose the ranking model (title weighted, then tags/categories, summary as fallback) plus the fact that results are returned with scores. It omits any statement about read-only behavior, rate limits, or pagination semantics, which keeps it below 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?

A single front-loaded sentence covering purpose, search scope, ranking behavior, and return content, with the parenthetical detail earning its place. 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?

There is no output schema, so the description usefully states that results come back as a hit list with scores. Combined with the fully documented parameters, this is nearly complete for a simple search tool, though result shape and paging behavior could be spelled out further.

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 query (space-separated multi-word) and limit (default 10, max 30) are fully documented in the schema. The description only restates that search is keyword-based and adds no format or constraint detail beyond the schema, so the baseline of 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 (search) and resource (全站文章), and scopes it as keyword-based site-wide search, which distinguishes it from the single-item get_article and the browsing list_articles. It does not explicitly name those siblings, so it stops short of 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?

Usage is only implied by the word 搜索 (search) – the agent can infer it is for keyword lookups rather than direct retrieval or listing. There is no explicit when-to-use/when-not statement and no reference to list_articles as the alternative for browsing, leaving routing to inference.

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 tells the agent this is an aggregate/orientation read and what it contains (counts, latest content, entry points), which is useful, but never explicitly states read-only safety semantics; for a zero-argument overview this is adequate without being rich.

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 front-loads the site identity, then the returned contents, then the usage trigger. Every clause earns its place with no redundancy.

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

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

With no output schema and no annotations, the description still communicates what the tool yields (totals, latest content, agent entry points). It is complete enough for an agent to invoke and interpret a zero-argument overview, though it does not specify return formatting or ordering.

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

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

There are zero parameters, so there is no parameter semantics to document. Baseline 4 applies; the description adds no misleading parameter claims.

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 resource (站点概览 / site overview for lishuhang.me) and enumerates its payload: article and daily-issue totals, latest content, and all agent entry points. This clearly distinguishes it from the listing and search siblings, which return individual items rather than a site-wide orientation snapshot.

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 when first encountering this site), which routes the agent to this tool before the more specific siblings. It does not, however, name alternatives or contrast with list_articles/search_articles, so the guidance is clear but not fully differential.

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