fanfou-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct action or resource: deletion, timeline retrieval, status info, user info, publishing, favoriting, friendship management, and OAuth generation. No two tools have overlapping purposes; agents can easily differentiate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., delete_status, get_home_timeline, manage_favorite). The verbs (delete, generate, get, manage, publish) clearly indicate the action, and nouns specify the resource, forming a predictable and readable set.
Tool Count5/5
With 11 tools covering authentication, multiple timeline retrievals, user info, status CRUD, favoriting, and friendships, the count is well-scoped for a microblogging service. Each tool serves a necessary function without redundancy.
Completeness4/5
The tool set covers core operations: publishing text and photos, deleting, favoriting, managing follows, and viewing timelines. However, notable gaps include missing tools to list followers/friends or view a user's favorites list, which an agent might need for full user interaction.
Average 4.1/5 across 11 of 11 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses that the tool calls an API to post text, requires a confirm parameter for a two-step process, and returns a dictionary with status info and review reminders. However, it does not mention potential irreversible effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with Args and Returns sections, but it includes some redundancy (e.g., restating '发布饭否内容' in the first line and again in the API reference). It could be more concise by combining these, but it is not overly long.
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 tool has an output schema and only two parameters, the description provides enough detail: what it does, parameters with constraints, and return value structure. It lacks sibling differentiation but covers the essentials for a simple text-posting tool.
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 0%, so description must compensate. It explains 'status' has a 140-character limit and 'confirm' is a secondary confirmation parameter. The return structure is detailed with keys like publish ID, timestamp, result, and tips. This adds meaningful context beyond the raw schema.
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 publishes text-only content on Fanfou via a specific API endpoint. It explicitly says '(仅文字)' distinguishing it from sibling tools like publish_photo. The verb '发布' (publish) and resource '饭否内容' (Fanfou content) are specific.
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 does not provide any guidance on when to use this tool versus alternatives like publish_photo or get_home_timeline. There is no mention of prerequisites, context, or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the API endpoint, the delete action, the restriction to own content, and the confirm parameter for safety. It also describes return values, including a confirmation dictionary when not confirmed. This gives a transparent view of 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?
Description is organized with sections (overview, notes, Args, Returns). It is not overly verbose, though some redundancy exists. The structure helps readability, and every sentence adds information.
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 moderate complexity (2 params, output schema exists), the description covers purpose, restrictions, parameters, and return values. It provides sufficient information for an agent to use the tool correctly without additional 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 coverage is 0%, so description must add meaning. It explains status_id as the ID of the status to delete and confirm as a secondary confirmation parameter. This adds some value, but the explanations are minimal and could benefit from examples or sources for the ID.
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?
Description clearly states the tool deletes fanfou statuses, and specifies the restriction to own content. It distinguishes from sibling tools like publish_status or manage_favorite, but does not explicitly contrast with them.
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?
Description notes that only own content can be deleted, which is a usage constraint. However, it does not provide guidance on when to use this tool versus others, nor does it mention prerequisites or alternatives. The confirm parameter is explained as a safety measure, which provides limited context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details the API endpoints, data source (public content), and return structure. It is clear it is a read operation. However, it does not discuss authentication or rate limits, but given the detail, it is above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy (approx. 30 lines) but well-structured with sections. While informative, some details in the return format could be streamlined. It is not maximally concise, but structure earns a baseline score.
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 tool has three simple parameters and a detailed return description (despite an output schema not being fully provided), the description covers behavior, input, and output comprehensively for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains all three parameters: count (default 5), max_id (for pagination), and q (search keyword). This adds significant meaning beyond the schema's bare titles and types.
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 the public timeline from Fanfou API, specifying two modes: normal retrieval and search. It distinguishes between them but does not explicitly differentiate from sibling tools like get_home_timeline or get_user_timeline.
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 explains when to use each mode (when q is provided vs not), but lacks guidance on when to choose this tool over alternatives such as get_home_timeline or get_user_timeline. No when-not or exclusion conditions are given.
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?
No annotations provided, so description carries burden. It details return fields and formats, but lacks disclosure about authentication, rate limits, or side effects. Read-only nature implied but not stated.
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?
Description is detailed, especially the returns section, which is justified for complex data. However, it could be more structured (e.g., bullet points) and slightly shorter.
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 single parameter and presence of output schema, the description compensates by detailing the return dictionary. It covers expected fields and special cases (e.g., retweets, audits), making it complete for the tool's complexity.
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?
Parameter status_id is described as '饭否内容的 ID', which adds meaning beyond the schema (only title and type). With 0% schema coverage, this is valuable.
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 it retrieves detailed information about a specific Fanfou status, specifying the API endpoint and distinguishing it from sibling tools that deal with timelines or user 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?
Purpose is implied: use when you need details of a known status ID. No explicit when-not-to-use or comparison with alternatives like get_home_timeline.
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 should disclose behavioral traits like authentication needs, rate limits, or side effects. It only mentions API endpoints and output format, lacking details on permissions, error conditions, or data mutability.
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 well-structured with sections for summary, usage, args, and returns. It is somewhat lengthy but front-loaded with key purpose. Could be slightly more concise, but overall effective.
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 presence of an output schema, the description covers return format in detail (HTML formatting, forwarding, topics, audit status). It explains two modes of operation. Missing error handling, but overall provides sufficient context for an agent.
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 description coverage is 0%, but the description explains each parameter's meaning and behavior (e.g., user_id empty gets current user, q enables search, max_id for pagination). This adds significant value beyond the bare schema.
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 it retrieves a user's timeline via specific API endpoints, distinguishes between current user and other users based on user_id, and handles search functionality. It differentiates from siblings like get_home_timeline and get_public_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides conditions for when to use different parameter values (empty user_id, q provided). However, it does not explicitly state when to use this tool over sibling tools, though the name and context imply typical usage.
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 discloses the API endpoint, conditional behavior, and return fields, but does not mention authentication requirements or rate limits, which are important for a tool accessing user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and structured, but the extensive list of return fields makes it somewhat verbose; it could be more concise by summarizing the return type.
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 tool's simplicity, the description covers purpose, parameter semantics, and return values adequately, though it omits error handling or authentication notes.
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 description adds significant value beyond the schema by explaining the default behavior when user_id is empty and detailing the return structure, compensating for the schema's lack of description.
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 it retrieves detailed user info via a specific API, and distinguishes itself from sibling tools (timelines, status, etc.) by focusing on user resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that it gets info for a specified user or the current user if user_id is empty, providing clear context for use, though it does not explicitly exclude alternative scenarios.
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 full burden. It discloses the API call and confirmation flow but omits authentication needs, rate limits, and mutability. It adds some value but leaves 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 concise with clear section headers for Args and Returns. No unnecessary words; structured meaningfully.
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?
The description covers input parameters and return values well. However, it omits error handling, authentication requirements, and potential side effects. For a posting tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: status with max length, photo_url as URL, confirm as confirmation flag. It also details return fields.
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: posting content with images to Fanfou via the /photos/upload.json API. It distinguishes from the sibling publish_status by specifying image inclusion.
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 for image posts but does not explicitly guide when to use this vs. publish_status or when to set the confirm parameter. It lacks explicit when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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. It discloses that the token is output to the console, the user must manually save it to an environment variable, and lists required environment variables. This provides good transparency about the manual step and prerequisites, though it lacks details on error handling or token persistence.
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 well-structured with a clear title, explanation, prerequisite list, and return description. It is front-loaded with the purpose. The environment variable list is necessary but slightly verbose; overall concise.
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 zero parameters and no annotations, the description adequately covers the tool's purpose, method, prerequisites, and output. It does not mention error cases or token lifecycle, but for a simple authentication tool it is fairly complete.
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, so schema coverage is 100%. The description clarifies that there are no input parameters but instead relies on environment variables (FANFOU_API_KEY, etc.), adding meaning beyond the empty schema. It also describes the return value structure.
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 generates an OAuth token using username/password for subsequent passwordless login. It specifies the verb 'generate', the resource 'OAuth Token', and the method 'x_auth'. This clearly distinguishes it from sibling tools which focus on statuses, users, favorites, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the token is for subsequent passwordless login (when to use) and lists required environment variables (prerequisites). However, it does not explicitly state when not to use this tool (e.g., if a token already exists) or contrast with alternatives, though no alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It describes the API call, the data retrieval nature, and provides detailed output structure including HTML formats, mentions of reposts, topics, and audit status. It implicitly indicates it's a read operation. However, it does not explicitly state authorization requirements or rate limits, which would further enhance transparency.
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 well-structured with a clear purpose statement, an API reference, a usage note, and a detailed returns section with bullet points. It is front-loaded with the core purpose. Could be slightly more concise, but no unnecessary sentences.
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 that the tool has a detailed output schema described in the returns section and the two parameters are fully explained, the description is complete for this simple read tool. It also addresses an edge case (user referring to 'my fanfou'). The lack of error handling or rate limit information is acceptable for a basic read operation.
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?
Input schema has 0% description coverage, but the description compensates by explaining both parameters: 'count: 获取数量，默认 5 条' and 'max_id: 返回列表中内容最新 ID，用于分页获取更早的内容'. This adds meaning beyond the schema's title and default 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 the home timeline of the current user's followed users, and distinguishes it from a specific user's timeline. It references the API endpoint and provides context that normally when users say 'my fanfou', this tool applies, differentiating it from sibling tools like get_user_timeline and get_public_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance on when to use this tool: '通常用户询问「我的饭否」时，指的是该时间线，除非用户明确指出「某个用户的饭否」'. This helps the agent decide between home timeline and specific user timelines. However, it does not explicitly list all alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses important behavior: it calls get_user_info first, and for protected accounts it becomes a follow request. It does not cover rate limits or auth needs, but the key side effects are explained.
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 well-structured with paragraphs and an Args/Returns section. It is slightly lengthy but each part earns its place. Minor redundancy, but generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the main use case, the special protected account scenario, and the confirm parameter. Return values are detailed, making it comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: user_id, action ('create'/'destroy'), and confirm (secondary confirmation). This adds significant meaning beyond the schema.
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 as managing user follow status (关注/取消关注), using specific API endpoints. It distinguishes from sibling tools like manage_favorite and publish_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to follow/unfollow) and provides context about protected accounts. However, it does not explicitly mention when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
详细说明了调用的API、操作影响、二次确认流程和返回结果，弥补了无注释的不足。
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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
覆盖了输入、输出、行为，配合输出schema说明，对工具使用场景描述充分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
所有3个参数均有详细说明，包括status_id含义、action的create/destroy取值、confirm的确认作用，补充了schema的缺失。
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?
明确指定了管理饭否内容的收藏状态，通过调用具体API接口，与其他发布、删除等工具区分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述了收藏/取消收藏的操作，但未明确排除其他场景或提供替代方案。
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:

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

Score Badge

Copy to your README.md:

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

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/kingcos/fanfou-mcp'

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