juejin-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.4
Disambiguation2/5
Many tools have overlapping purposes: analyze_pin_trends, analyze_trends, get_simple_trends, and get_hot_topics all focus on trends; get_recommendations, get_article_recommendations, get_pin_recommendations, get_trending_recommendations, and get_simple_recommendations are difficult to distinguish. An agent would struggle to select the right tool for a given request.
Naming Consistency4/5
All tool names follow a verb_noun pattern in snake_case, which is consistent. However, the verbs are sometimes vague or repeated across many tools (e.g., get_, analyze_), making names less informative than they could be, but the style itself is uniform.
Tool Count2/5
With 34 tools, the server is heavy. Many tools appear to be variations of similar functionality (e.g., five recommendation tools, four trend analysis tools, five performance tools), which inflates the count without adding distinct value. A more consolidated set would be easier to navigate.
Completeness3/5
The server covers reading, searching, liking, collecting, following, and user profile, which are core interactions. However, it lacks single-item retrieval (e.g., get_article, get_pin), and does not support creating/updating content or commenting, leaving notable gaps for a platform like Juejin. The performance and system stats tools seem out of place, further muddying the domain.
Average 3.1/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must carry the burden of behavioral disclosure. It implys a read-only analysis but does not explicitly state safety, permissions, or side effects. It only mentions that it provides assessment and suggestions, missing details on data handling or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and output. It is efficient and free of redundant wording, though it could be slightly more structured with separate usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain the return format and how parameters affect results. It only offers a high-level output description ('detailed quality assessment and improvement suggestions') without specifics like whether predictions are included or the structure of the assessment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions, so the schema has 100% coverage. The description adds no additional meaning to parameters—it does not explain how include_predictions influences the analysis or what article_id expects beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as analyzing article quality and providing a detailed assessment with improvement suggestions. It uses a specific verb+resource construction and distinguishes from sibling tools by focusing on articles, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool versus similar analysis tools like analyze_content_quality or analyze_pin_trends, nor does it mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as whether this is a read-only analysis, what 'popularity' means, or what the report contains. It only says it evaluates and provides a report, leaving the actual behavior and output largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the core purpose and deliverable without unnecessary detail. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex analysis tool with no output schema and no annotations. The description does not clarify what the 'quality analysis report' includes, how to interpret results, or how it relates to similar sibling tools, leaving significant gaps for an agent trying to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all three parameters, including enums and defaults. The description adds no parameter-level meaning beyond what the schema provides, meriting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates content quality and popularity and produces a detailed analysis report. It is specific enough to distinguish from analyze_pin_trends and analyze_article_quality, though it does not explicitly mention that it covers both articles and pins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like analyze_article_quality or analyze_pin_trends. The description gives no context for tool selection, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. 'Analyze' implies a read-only operation, but the description does not explicitly state safety, side effects, or any constraints on time_range or sentiment analysis. It only promises statistics and insights without detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the tool's function. It is front-loaded and contains no filler, though it might be too sparse to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description provides minimal context. It does not specify what statistics or insights are returned, how time_range affects results, or why a user would choose this over similar tools. The sibling context suggests many overlapping analysis tools, making this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (time_range in hours, include_sentiment_analysis as a boolean), giving 100% coverage. The description does not add any parameter-specific meaning beyond this, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes trends ('分析沸点趋势') and provides detailed statistics and insights, which is a clear verb-resource pairing. However, it does not distinguish this tool from sibling tools like analyze_trends or get_simple_trends, which may cover similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of preferred scenarios, exclusions, or distinctions from other trend analysis tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states a generic comparison action. It does not mention return format, side effects, required permissions, or error handling. The read-only nature is implied but not explicitly stated, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundant information. It gets straight to the point, making it highly concise and well-structured for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with enums and no output schema, yet the description fails to explain what the comparison result looks like (e.g., a report, scores, sorted list) or provide any use-case context. Given the lack of annotations and output schema, this is insufficient for an agent to fully understand tool behavior and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all three parameters (content_ids, content_type, comparison_metrics) adequately described in Chinese. The tool description adds no additional parameter semantics beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '比较不同内容的表现和特征' clearly states it compares content performance and characteristics, with a specific verb ('compare') and resource ('content'). This differentiates it from sibling tools such as get_performance_stats or analyze_content_quality, but the phrase 'performance and characteristics' is somewhat vague and could be more specific about content types or metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like analyze_performance or direct comparison. The description lacks any context about prerequisites, when not to use it, or how it relates to sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It mentions the report includes cross-platform data and predictions, but does not disclose operational traits such as side effects, permissions, rate limits, or performance implications. For a report-generation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the main purpose without extraneous words. It is appropriately sized for the tool's simplicity, though it sacrifices content richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, and the presence of many trend-related sibling tools, the description is too thin. It does not explain the structure of the report, what 'predictions' entail, how parameters affect the outcome, or how this tool differs from similar ones, leaving significant ambiguity for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (time_range and include_platform_insights), so the schema already defines their meaning. The description adds no extra parameter context beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('生成' / generate) and resource ('综合趋势分析报告' / comprehensive trend analysis report), and mentions cross-platform data and predictions, giving some specificity. However, it does not differentiate from sibling tools such as analyze_trends or get_simple_trends, which also analyze trends, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does, without any contextual triggers, prerequisites, or comparisons to sibling tools, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not mention whether the tool has side effects, requires specific permissions, or what the output format is. For a report generation tool, this leaves important behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action. It contains no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a straightforward purpose, the description lacks essential context about the report format, return value, or any prerequisites. With no output schema and no annotations, the agent is left uncertain about what the tool actually produces or if it has side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description adds context about report contents but does not elaborate on how parameters affect the output beyond what the schema states. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a user analysis report with specific components (interest analysis, behavior patterns, growth suggestions). However, it does not explicitly distinguish itself from sibling tools like generate_trend_report or analyze_user_interests, which overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tools include similar report-generating and analysis tools, but the description does not mention any specific use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only hints at the recommendation basis (user interests and content quality). It does not mention authentication requirements, pagination, rate limits, or any potential side effects. The description is minimal and lacks operational transparency beyond the algorithm's intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It conveys the core purpose efficiently and is front-loaded with the action, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should help the agent understand what to expect, but it offers no hints about return format or behavior. It also lacks context on how parameters interact (e.g., how user_interests are used) and does not differentiate from sibling recommendation tools, leaving significant gaps for a tool with this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the description does not need to explain them. The description adds no extra parameter semantics, but the schema already documents each parameter (limit, exclude_ids, content_types, user_interests). Baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '获取个性化沸点推荐' (get personalized pin recommendations), which identifies the verb and resource. It also adds context by mentioning it's based on user interests and content quality, but it does not distinguish this from similar sibling tools like get_user_recommendations or get_simple_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of preferred scenarios, exclusions, or comparison with sibling recommendation tools, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions personalization and algorithm support but does not disclose side effects, required authentication, rate limits, or what the response contains. The behavioral traits beyond parameters are essentially absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It is front-loaded with the primary action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no output schema, and no annotations, yet the description is minimal. It lacks any information about return structure, defaults, or how this tool differs from the many sibling recommendation tools, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all six parameters documented. The description adds little beyond the schema, only vaguely referring to 'multiple recommendation algorithms and filter conditions.' Baseline 3 is appropriate since the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets personalized content recommendations with multiple algorithms and filters. However, it does not distinguish this from many similar sibling tools like get_article_recommendations, get_pin_recommendations, or get_trending_recommendations, leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many alternative recommendation tools. It does not mention prerequisites, such as whether user_id is needed for personalization, or when a specific algorithm is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only 'get' but does not explicitly state non-destructiveness, required permissions, rate limits, or output format. The term 'simplified' is ambiguous about what is simplified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core function ('get simplified recommendations') and adds a concise context clause ('based on hot content and user interests'). No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 4 parameters and no annotations or output schema, the description fails to provide usage context, behavioral expectations, or differentiation from many sibling recommendation tools. The 'simplified' qualifier is unexplained, leaving the tool incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 4 parameters (limit, sort_by, content_type, user_interests), achieving 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond referencing user interests and hot content, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves simplified content recommendations based on hot content and user interests. It uses a specific verb (get) and resource (simplified content recommendations), but does not explicitly differentiate from sibling recommendation tools beyond the word 'simplified'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention any context, exclusions, or sibling tools, leaving the agent without direction for tool selection among many recommendation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the type of information returned (performance metrics, resource usage, recommendations) but does not disclose whether this is a read-only operation, how the data is structured, whether any side effects occur, or any rate limits/auth requirements. The absence of these details leaves significant behavioral uncertainty for a health-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and content scope. It avoids unnecessary words and is appropriately sized for a simple health-check tool. However, the term '建议' (recommendations) is slightly ambiguous and could be more specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only a one-sentence description, the tool is underspecified. It does not explain what constitutes 'system health', how the returned recommendations are formatted, or how this tool relates to sibling tools like get_performance_stats and optimize_performance. The agent would need to guess at output structure and use context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional parameter 'include_recommendations' (default true), which is fully documented as controlling whether optimization suggestions are included. Per the baseline rule, a score of 3 is appropriate because the schema handles the parameter semantics and the description adds no additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('获取系统健康状态' / get system health) and lists its content areas (performance metrics, resource usage, recommendations). It is unambiguous and distinct from most siblings, though it does not explicitly differentiate from the similar-looking get_performance_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_performance_stats or get_cache_stats. There is no mention of typical scenarios, prerequisites, or exclusion criteria, leaving the agent to infer usage from the tool's name and generic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what it returns, how it handles missing user_id or user_interests, or any side effects. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the key action '获取用户推荐'. It is not bloated, but it is slightly tautological with the tool name and could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters, the description is insufficient. It does not explain return values, expected input combinations, or behavior under edge cases. For a tool with this complexity and no structured safety context, the description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific details; it merely says 'discover similar users or influential users', which loosely reflects the algorithm enum but does not explain parameter usage, defaults, or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取用户推荐，发现相似用户或有影响力的用户' clearly states the tool's purpose: getting user recommendations focused on similar or influential users. It distinguishes from sibling tools like get_article_recommendations and get_pin_recommendations by specifying 'users', but it does not explicitly differentiate from other generic recommendation tools like get_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or context in which this tool should be preferred over the many sibling recommendation tools. It only implies usage by its name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It mentions actions like clearing cache and resetting stats but does not warn about potential data loss, performance impact, or required permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and uses 'etc.' to signal additional operations. It is appropriately concise but could be tightened by focusing on the most critical examples. No fluff present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover usage conditions and effects. It only lists generic operations, missing side effects, return behavior, and prerequisites. For a mutation tool with enums, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 examples (clearing cache, resetting stats) mirror the enum values and add no additional meaning beyond the schema. The relationship between target and operation is not clarified, but the schema already documents both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs performance optimization operations with concrete examples (清理缓存, 重置统计), identifying it as a mutation/action tool distinct from read-only siblings like get_cache_stats and get_performance_stats. However, it does not explicitly contrast with sibling tools, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. While the examples imply it is for maintenance actions, the description does not state conditions, exclusions, or distinguish it from similar tools like run_performance_benchmark. The agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only states what the tool does (predicts) without indicating whether it is read-only, what data it uses, whether it modifies anything, or what the output format is. This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It is appropriately front-loaded, but its brevity leaves out important context. Still, it is efficient and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a very brief description. It fails to explain what 'popularity' means, how predictions are made, what the output looks like, or when to use it compared to sibling tools. This is insufficient for an AI agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add any additional meaning beyond the schema, so it neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to predict content popularity and dissemination potential. It uses a specific verb ('predict') and resource ('content'), but does not differentiate it from sibling tools like analyze_trends or get_trending_articles, which could also relate to popularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of ideal scenarios, exclusions, or how it compares to similar analysis tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose key behaviors like whether results are paginated, sorted by relevance, or what 'smart filtering' actually does. The phrase '智能过滤' is vague and does not help predict the tool's output format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the core function. It is front-loaded and contains no filler words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters and no output schema or annotations, the description is under-specified. It does not explain what 'smart filtering' entails, what the response structure looks like, or any caveats like rate limits or authentication requirements, leaving the agent without enough context to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes all three parameters (keyword, limit, include_analysis) with Chinese descriptions, giving 100% coverage. The tool description adds the notion of 'smart filtering' but does not clarify how parameters like include_analysis relate to it, so it adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Juejin articles and supports keyword search and intelligent filtering. It uses a specific verb and resource, and the keyword/search concept distinguishes it from general listing tools like get_articles, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_articles, search_pins, or get_trending_articles. The description only states capabilities, not when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It does not state whether the tool is read-only, what 'content analysis' does to results, whether pagination applies, or any rate limits. The ambiguity around 'content analysis' is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without redundancy. It is front-loaded with the main purpose. However, it is slightly under-specified, which prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should clarify return values or behavior. It does not mention what results look like, whether analysis accompanies search results, or how filters interact. Given the sibling tools and parameter complexity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds 'keyword search' which aligns with the keyword parameter, but does not explain limit or content_type beyond what the schema already says. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Juejin pins (沸点) with keyword search and content analysis. The verb 'search' and resource 'pins' are specific, but 'content analysis' is vague and could confuse with analyze_trends or analyze_content_quality siblings, so it doesn't fully distinguish.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_pins or search_articles. The description does not mention exclusions, prerequisites, or a decision context. The only implicit cue is the presence of 'search' in the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It only states the action without mentioning whether it is read-only, what credentials are needed, or what response is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, appropriately compact for a zero-parameter tool. However, the brevity sacrifices potentially useful context, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 alone must convey what the agent will receive and any caveats. 'Check authorization status' leaves unclear what statuses are possible and what action the agent should take based on them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so parameter semantics are trivial. The baseline score of 4 applies, and the description doesn't need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('authorization status'), making the core function clear. It doesn't explicitly differentiate from sibling status-related tools, but the resource is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_system_health or get_cache_stats. The description offers no context for selection or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the auth requirement, which is a behavioral trait, but does not disclose what happens on failure, what data is returned, or any side effects. This is minimal disclosure for a potentially sensitive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. It is appropriately sized for a zero-parameter getter, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return values and error behavior. It only states 'requires authorization' and gives no information about what user data is returned, response format, or how auth failures are handled, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the schema description coverage is 100%. The description adds no parameter information because none exist, so the baseline of 4 applies as per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get current user information', which is a specific verb and resource. It is distinct from sibling tools like check_auth_status (auth status) and get_user_recommendations (recommendations), though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that authorization is required, but gives no guidance on when to use this tool versus alternatives like check_auth_status or generating user reports. It lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose that authorization is required, which is a useful trait, but fails to mention side effects, idempotency, or the nature of the mutation (e.g., creating a bookmark, adding to a collection). For a state-changing operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single short phrase. It front-loads the action and includes the key prerequisite (authorization). There is no wasted wording, and it is easy to parse quickly, making it an excellent example of conciseness and structure for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable but has gaps. It does not explain what happens after collection, whether it can be undone, or how it relates to other features like recommendations or pins. While not critically incomplete for such a simple operation, it could provide more context to fully orient the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter article_id, with 100% description coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. The parameter is straightforward, and the description does not need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '收藏文章' (collect/favorite article) clearly identifies the action verb and target resource, making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like like_article or get_articles, so it lacks explicit sibling distinction, which is required for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The only additional note, '需要授权' (authorization required), is a precondition rather than a usage directive. There is no mention of scenarios, exclusions, or relationships to other tools, so it falls at 'no guidance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无注解，描述承担全部行为披露责任，但仅提获取统计信息，未说明是否只读、所需权限、返回格式或潜在副作用。缺乏对详细统计信息参数的影响说明。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述为单句，简洁无冗余，核心功能被前置，信息呈现流畅。虽然缺少细节，但作为简洁性评估，适当的字数而非冗长是得分依据。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
无输出模式、无注解，且描述仅简要说明返回指标类型，未提及参数如何影响结果、返回值结构或使用场景。对于统计类工具，信息不足以让智能体充分理解工具行为。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式已完整描述两个参数及其枚举值，schema覆盖率为100%，描述未额外解释参数含义或使用方式。描述提及命中率、大小等指标，但未与参数关联，因此给予基线3分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确说明工具功能为获取缓存系统统计信息，包含命中率、大小等具体指标，动词和资源清晰。与兄弟工具如get_performance_stats、get_system_health等相比，聚焦于缓存系统，区分度高。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未提供任何使用时机或替代工具的指引，未说明在何种场景下应优先使用此工具而非其他统计类工具。例如，没有提及与get_performance_stats或get_system_health的区别和选择依据。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It does not explicitly state read-only semantics, return format, ordering, or any potential side effects, providing only a bare operational statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the purpose without any filler or redundancy. It is concise and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-optional-parameter schema and no output schema, the description is functional but lacks context about return format, expected data structure, or use-case fit. It is not inadequate but leaves the agent to infer many details from the tool name and schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full 100% description coverage for both parameters (limit and time_range), with clear Chinese descriptions of their meaning and constraints. The tool description itself adds no additional parameter semantics, but the schema is self-sufficient, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('hot topics') with a clear goal of identifying the most discussed topics. It is clear but does not explicitly differentiate from sibling tools like get_simple_trends or analyze_trends, which could overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the many similar analysis and recommendation tools in the sibling list. There are no mentions of alternatives, exclusions, or prerequisites, leaving the agent to infer appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden but only mentions 'based on current data' and 'quickly' as behavioral hints. It does not disclose return format, data scope, or any side effects, which is insufficient for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It front-loads the purpose and provides a brief behavior note, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 optional params, no output schema), the description is adequate but incomplete. It fails to explain what 'simplified' means, how it differs from full trend analysis, or what the return structure looks like, leaving gaps for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond the schema; it only vaguely mentions topics and tags, but the parameters (limit and include_authors) are already well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides simplified trend analysis of hot tags and topics ('获取简化版趋势分析，基于当前数据快速分析热门标签和话题'). It has a specific verb and resource, but does not explicitly differentiate from sibling tools like analyze_trends or get_hot_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as analyze_trends or get_hot_topics. The description only implies quick analysis of current data, but there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the context that results are based on real-time data analysis, which is a behavioral trait. However, it does not disclose what the response looks like, whether pagination exists, or any limitations, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, but extremely brief—could benefit from a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a minimal description, the tool is under-specified. It does not mention return values, sorting, or whether parameters are required, which is necessary for an agent to use it effectively given 3 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 limit, category, and time_range. The description adds no parameter-specific meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets hot trending articles based on real-time data analysis. It specifies the resource (articles) and the criterion (trending), which distinguishes it from generic get_articles or search_articles, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_hot_topics or analyze_trends. The description implies a use case but does not state when to prefer it or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions authorization is required, which is useful, but it does not disclose side effects (e.g., whether the like is idempotent, increments a count, can be undone), failure modes, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the core action and includes a useful authorization note. Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool, the description plus schema provides the basic essentials: what to like and that authorization is needed. However, it lacks behavioral details such as idempotency, error handling, or expected return values, and there is no output schema to compensate. It is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter 'article_id' with its type and description. The tool description adds no additional meaning to the parameter beyond what is already in 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '点赞文章' clearly states the action (like) and resource (article), and the parenthetical '需要授权' adds a key condition. It is specific enough to be understood, though it does not explicitly differentiate from the sibling 'like_pin' beyond the article/pin distinction implied by the names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like like_pin or collect_article. The only context is '需要授权' (authorization required), which is a prerequisite, not a usage guideline. There is no mention of scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It states what the tool does but does not disclose any behavioral traits such as the output structure, data sources, authentication requirements, or whether it performs predictions despite having an 'include_predictions' parameter. This lack of behavioral detail leads to a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without any filler. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters, no output schema, and no annotations, and it sits among many sibling tools with overlapping purposes. The description fails to explain return values, usage scenarios, or differences from siblings. This makes the description incomplete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full description coverage (100%) for all three parameters, providing a baseline of 3. The description does not add any extra meaning to the parameters; it mentions 'rising trends' but does not connect it to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'analyze' and 'identify' with clear objects (current trends, rising trends, cross-platform hotspots). It conveys the tool's purpose effectively. However, it does not explicitly differentiate from sibling tools such as analyze_pin_trends or get_hot_topics, which also deal with trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to analyze current trends, but it provides no explicit guidance on when to use it versus alternative tools like analyze_pin_trends or get_simple_trends. There are no mentions of exclusions or alternative recommendations. This gives only an implied usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It merely says 'analyze' and 'build profile' without clarifying whether this is read-only, whether it persists data, or what side effects occur. The lack of safety/disclosure info is a significant gap for a tool that could involve user data processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose. No wasted words or redundant phrasing. It is appropriately front-loaded and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too minimal. It does not explain expected return values, how the flags affect the result, or whether any data is persisted. The complexity of user-profile building calls for more context than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear meaning (e.g., include_behavior_analysis: 'whether to include behavior analysis'). The tool description adds little beyond that, but the schema already provides sufficient semantics. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '分析用户兴趣和行为模式，构建用户画像' (analyze user interests and behavior patterns, build user profile). This distinguishes it from sibling tools like get_user_recommendations (recommendations) and get_user_profile (retrieval), making its scope specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like generate_user_report and get_user_recommendations could overlap, but the description offers no context for selection, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry full burden for behavioral transparency. It mentions that the list includes quality scores and trend analysis, but the schema shows include_trend_info defaults to false and include_quality_score defaults to true, so the unprompted claim about trend analysis is potentially misleading. No information is given about pagination behavior, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then lists key features. It is concise and every part of the sentence adds value. There is no fluff or repetition, making it an excellent example of concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 optional parameters, no output schema, and no annotations. The description provides only a high-level summary and does not explain return values, pagination mechanics, default behaviors, or how it compares to sibling tools. For a tool with this complexity, the description is incomplete and leaves significant gaps in an agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for all 7 parameters, so the baseline is 3. The description mentions category, sorting, pagination, quality score, and trend analysis, but these are already fully explained in the schema descriptions. The description adds no new semantic meaning beyond what the schema provides, so it neither improves nor degrades parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取掘金文章列表' (get Juejin article list), which specifies the verb and resource. It also mentions support for category, sorting, pagination, and inclusion of quality scores and trend analysis. However, it does not explicitly differentiate this tool from siblings like search_articles or get_trending_articles, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a filtered, paginated list of articles, which gives some context. However, it provides no explicit guidance on when to use this tool versus alternatives such as search_articles or get_trending_articles, and it does not mention any exclusions or conditions. The usage is inferred from the feature list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the operation is read-only, has side effects, requires specific permissions, or could be resource-intensive. The only clue is the word 'get', implying read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without any unnecessary words. It is well-structured and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides partial information about return values by mentioning response time and memory usage. It covers most expectations for a performance stats tool, though it doesn't explicitly mention the slow operations aspect, which is present in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have detailed descriptions in the schema (100% coverage), so the baseline is 3. The description adds minimal extra meaning beyond the schema, only hinting at response time and memory usage which align with metric_name and include_memory_stats, but it doesn't enhance understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as fetching system performance statistics, mentioning response time and memory usage. It is specific enough to distinguish it from content-related tools, but it does not explicitly differentiate from similar performance tools like get_system_health or get_cache_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_system_health or run_performance_benchmark. The description only states what it does, leaving the user to infer the appropriate context without any exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits like resource impact, side effects, or output format. It only says 'run benchmark' which implies execution but does not state safety, duration, or system changes. This is insufficient for a tool that likely performs heavy operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It efficiently communicates the core purpose and fits the simple two-parameter tool interface, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide sufficient context. It fails to mention return values, potential side effects, or how it differs from related tools like get_performance_stats. This leaves the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (both test_type and iterations have descriptions), so the description does not need to add parameter details. The tool description itself adds no extra meaning, but the baseline is 3 due to complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'run' and the resource 'performance benchmark test', and adds purpose 'evaluate system component performance'. This clearly differentiates it from siblings like get_performance_stats or optimize_performance, as it indicates an active benchmarking task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_performance_stats or get_cache_stats. The description does not mention any exclusions or alternative tools, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the need for authorization ('需要授权'), which is valuable, but it does not describe the effects of following, reversibility, or expected response. This is only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, front-loaded and free of redundant information. It earns its place entirely with the core action and the authorization note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter, but with no output schema and no annotations, the description could benefit from mentioning return behavior or side effects. It offers minimal context, which is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter user_id with the description '用户ID'. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '关注用户（需要授权）' clearly states the action (follow) and the target resource (user), making its purpose evident. It distinguishes itself from sibling tools like like_article or collect_article, though it doesn't provide additional contextual detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It only mentions an authorization requirement, which is not usage direction. There are no prerequisites, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that recommendations are updated, but does not disclose side effects (e.g., overwriting existing recommendations), reversibility, required permissions, or whether the update is asynchronous. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action ('update user recommendations') and providing the key context ('based on latest user behavior and interests'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is too minimal. It does not explain return values, errors, or what happens after the update (e.g., whether recommendations are immediately refreshed). The schema covers parameters but not the overall behavior, leaving the agent under-informed for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The tool description adds no extra parameter details beyond what the schema provides, but it does not need to compensate since the schema fully covers the parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'update' and the resource 'user recommendations', and distinguishes this mutation tool from the many get_* and analyze_* sibling tools. It also specifies the basis (latest user behavior and interests), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when user behavior has changed ('based on latest user behavior and interests'), but it does not explicitly state when to use this tool versus alternatives like get_user_recommendations or like_article. There are no exclusions or alternative tool mentions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the recommendation basis (user interests and content quality) but does not disclose potential side effects, authentication requirements, pagination behavior, or return format. The verb '获取' implies a read-only operation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the core action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has simple parameters and no output schema, so the description is moderately sufficient. However, the lack of usage guidance and behavioral details, combined with the abundance of sibling tools, makes the context incomplete. It describes what it does but not fully when or how it behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described, but the description adds cohesive meaning by framing the parameters around 'personalized' and 'content quality'. This explains how user_interests and min_quality_score interact, providing value beyond the individual schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取个性化文章推荐，基于用户兴趣和内容质量' clearly identifies the action (get recommendations), the resource (articles), and the distinguishing criteria (personalized, based on interests and content quality). This effectively differentiates it from sibling tools like get_trending_articles or get_pin_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There are multiple recommendation-related siblings (e.g., get_trending_recommendations, get_user_recommendations, get_simple_recommendations) but the description does not state when to use this tool instead of alternatives or what exclusions apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. The verb '获取' implies a read-only operation, but it does not disclose return format, pagination behavior, or any limitations on trend analysis. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose with no unnecessary words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain the return structure or how 'trending' is determined. While the input schema is well-documented, the lack of output details and behavioral context leaves some ambiguity for an agent, especially given the many sibling recommendation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a Chinese description. The tool description does not add extra meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '获取基于当前趋势的推荐内容' clearly states the tool retrieves recommended content based on current trends, using a specific verb and resource. This distinguishes it from generic recommendation tools like get_recommendations and sibling tools specifically for articles or pins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_recommendations, get_article_recommendations, or get_trending_articles. The description only states what it does without mentioning conditions, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that authorization is required, which is useful, but it does not disclose side effects, idempotency, error behavior, or what happens on success. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It directly states the action and the key prerequisite, making it easy to parse and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and no output schema. The description covers the essential context (like pin, auth required) but omits return behavior or error conditions. Given the low complexity, the description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'pin_id' as '沸点ID' (pin ID), yielding 100% coverage. The tool description adds no extra meaning about the parameter's format or usage, but the schema is already sufficient given the simplicity of a single identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '点赞沸点' clearly means 'like pin', a specific verb+resource action. It distinguishes from sibling tools like like_article and collect_article by targeting pins specifically. The added '需要授权' (requires authorization) further clarifies the operation's context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool's name and description: use it to like a specific pin. There are no explicit when-to-use or when-not-to-use instructions, and no mention of alternatives, but for such a direct action the purpose itself strongly implies the appropriate situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds value by mentioning that results include sentiment analysis and trend information. However, it does not disclose pagination behavior, authentication requirements, or the read-only nature explicitly, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource, then adds key features. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 6 parameters and no output schema, the description provides essential context but lacks depth. It does not explain the return structure beyond mentioning sentiment/trend info, nor does it differentiate from the many analysis sibling tools. Schema covers parameter details, but the description could better frame when this tool is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description only loosely mentions 'topic, sorting, etc.', which does not add meaningful detail beyond what the schema already provides. It does not explain parameter interactions or values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of Juejin pins ('获取掘金沸点列表'), specifies it supports topic and sorting parameters, and distinguishes it from siblings like get_articles and search_pins by focusing on pin listing with sentiment/trend info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: for getting a list of pins. However, there is no explicit guidance on when to use this vs. alternatives like search_pins or analyze_trends, nor any exclusion criteria. The description does not mention alternatives or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![juejin-mcp-server MCP server](https://glama.ai/mcp/servers/ztxtxwd/juejin-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ztxtxwd/juejin-mcp-server)

Score Badge

Copy to your README.md:

[![juejin-mcp-server MCP server](https://glama.ai/mcp/servers/ztxtxwd/juejin-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ztxtxwd/juejin-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ztxtxwd/juejin-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server