Mfuns MCP Server

by ymltsh

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, with three separate read tools clearly scoped by resource type (article/video/feed). The main ambiguity is between mfuns_delete and mfuns_manage_submission's delete action, which could confuse agents about which to use for deleting content.
Naming Consistency4/5
All tools share the mfuns_ prefix and mostly follow a verb_noun pattern (e.g., read_thread, create_post, publish_video). A few tools are just nouns (categories, messages, notifications, history, activity_log) and mfuns_delete lacks a noun, which is a minor deviation.
Tool Count4/5
19 tools is slightly above the ideal 3-15 range, but the breadth of the community platform (browsing, reading, creating, managing, social interactions, logs) justifies the count. Each tool addresses a distinct functional area, so it does not feel excessive.
Completeness3/5
Core workflows like browsing, reading, creating, and interacting are well covered, but private messaging is read-only (no send capability) and there is no way to update a feed post. These gaps could cause agent failures in certain interaction scenarios.
Average 4.2/5 across 19 of 19 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 provided, the description carries the burden of behavioral disclosure. It adds useful context: content is plain text and auto-converted to forum format, and the feed is visible site-wide. However, it does not mention authentication requirements, whether edits are allowed, rate limits, or error conditions, leaving gaps 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 concise and well-structured, with a brief intro and a clear Args list. Every sentence adds value, and the formatting makes it easy to scan. It is slightly repetitive with the parameter names but not wasteful.
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?
For a simple 3-parameter tool with an output schema, the description adequately covers the core purpose and parameter meanings. It lacks explicit usage guidance and differentiation from sibling tools, but given the low complexity, it is mostly complete. The visibility scope and auto-conversion note add helpful context.
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 provides only types and defaults (0% description coverage), so the description steps in. It explains that 'content' is plain text auto-converted to forum format, 'images' are URL lists, and 'tags' are limited to 10. This adds meaningful semantics beyond the schema, though it could be more detailed about formats or constraints.
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 a specific action ('发布动态' / publish feed) and resource ('Feed，全站动态流可见' / Feed visible across the site), making the tool's purpose clear. It distinguishes from sibling tools like mfuns_create_post by emphasizing the feed stream visibility, though it doesn't explicitly name the alternative.
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 publishing a feed with optional images and tags, but it does not explicitly state when to use this tool over alternatives like mfuns_create_post or mfuns_publish_video. There are no exclusion criteria or explicit context/conditions.
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 only states what the tool does (get browsing history) but does not mention whether it is read-only, requires authentication, returns data in chronological order, or any rate limits. This is a minimal behavioral disclosure.
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 compact, with the main purpose front-loaded and the parameter details following in a structured Args block. Every sentence earns its place, and there is no wasted wording.
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?
For a simple tool with only two optional parameters and an output schema, the description covers the core purpose and parameter semantics. However, it lacks behavioral context such as whether the history is user-specific, how ordering works, or if there are prerequisites. Overall, it is sufficient but not fully 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 provides no descriptions (0% coverage), but the description compensates by explaining both parameters: resource_type (with valid values article/video and default behavior) and limit (with default 50). This adds meaning beyond the raw schema types.
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 browsing history and explicitly explains its purpose ('了解自己看过什么，避免重复互动'). This is a specific verb+resource combination that distinguishes it from sibling tools like mfuns_browse or mfuns_read_feed.
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 purpose phrase implies when to use it (when checking past viewed content to avoid duplicate interaction), but it does not explicitly mention alternatives or when not to use it. The guidance is implied rather than explicit.
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 must disclose behavior itself. It explains key behaviors like list_id requirements for add/remove actions and the default list behavior. However, it does not mention what the tool returns, error conditions, idempotency, or side effects beyond the action itself, leaving some transparency 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 well-structured with a concise summary followed by an Args list. Every sentence provides necessary information, and there is no redundant or filler content.
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 all parameters and basic behaviors, and the presence of an output schema fills return-value details. It lacks explicit usage context and interaction nuances, but for a moderately complex tool, it is largely complete.
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?
The schema has 0% description coverage, but the description compensates fully by explaining each parameter in detail: resource_id, resource_type with allowed values, action with allowed values, and list_id with default/required conditions. This adds significant meaning 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 the tool's function as '收藏 / 取消收藏 / 查询收藏状态' (favorite/unfavorite/query favorite status), which is a specific verb+resource. It distinguishes itself from sibling tools like mfuns_react or mfuns_comment by focusing exclusively on favorite operations.
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 explains how to perform actions (add/remove/check) but does not mention scenarios, prerequisites, or exclusions relative to sibling tools such as mfuns_browse or mfuns_react.
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 are provided, so the description carries the transparency burden. It hints at the behavioral outcome (determining new vs old user) but does not disclose any side effects, permissions, or response behaviors. The get operation is inherently read-only, but no specific behavioral traits are described beyond the implicit purpose.
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 compact, consisting of one purposeful sentence and a parameter stub. Every word contributes, making it a model of brevity without losing essential 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?
For a simple user-retrieval tool with an output schema, the description covers the core purpose, the intended usage scenario, and the required parameter. It lacks only some peripheral details like error handling, but overall the context is sufficiently 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's Args section simply repeats the parameter name and type from the schema ('user_id: 用户 ID') without adding semantic details such as format constraints, source, or examples. With 0% schema coverage, the description fails to compensate, making this redundant.
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 user profile ('获取用户资料') and adds the purpose of assessing whether the user is new or old before interaction. This distinguishes it from sibling read tools that target threads, videos, or feeds.
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?
It provides explicit usage context: '互动前了解对象' (understand the target before interacting), which tells the agent when to use it. However, it does not mention alternatives or explicitly exclude other tools, so it lacks the when-not guidance.
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?
没有注释，描述承担行为透明责任。它说明了 update 不传 draft 会进入审核队列、草稿更新建议传 draft=true，以及 status 的数字含义，这些是重要的非显性行为。但未说明 delete 的不可逆性、权限要求或操作失败时的行为，覆盖不完整。
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?
描述采用分条 Args 格式，每行一个参数，信息密度高，先给出总体用途再列细节。虽然篇幅较长，但每个字段都有必要说明，没有冗余内容。
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?
作为多操作管理工具，描述覆盖了 list/update/delete 的参数要求、默认行为、状态过滤和更新审核行为，输出已有 output 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?
输入 schema 的 description 覆盖率为 0%，但描述对每个参数给出了含义、默认值、必填条件和可选范围，例如 action 的可选值、status 的枚举含义、draft 的行为影响，完全弥补了 schema 的缺失，甚至提供了超出 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?
描述明确指出'管理我的投稿'，并列出 list/update/delete 三种操作及类型参数，能区分于 mfuns_create_post 等兄弟工具。虽然未显式点名替代工具，但用途清晰，足以让智能体理解工具功能。
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?
描述详细说明了各操作的必要参数（update/delete 必填 contribute_id，update 必填 title/content/category_id），并给出 action 默认 list、size 上限等，使用场景清晰。但未提及与 mfuns_delete 或 mfuns_create_post 的明确分工，缺少排除性说明。
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, the description carries full burden. It adds valuable behavioral details: Markdown is auto-converted, category_id falls back to the first leaf child if a parent is given, copyright defaults to 2 (original), and draft=True only saves without publishing. These go beyond the schema, though auth prerequisites and error behavior are not mentioned.
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 opens with a crisp one-sentence purpose, then uses a structured Args list to convey parameter details. Each line is informative and necessary, with no redundant prose. The category example adds practical context without bloat.
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?
For a create operation with an output schema and no annotations, the description covers all parameter semantics and key behavioral defaults (category fallback, draft, copyright). It omits broader context like authentication requirements or when to use it, but the invocation details are sufficiently complete for correct tool use.
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 Args section fully compensates. It explains the 30-character title limit, Markdown support, category_id semantics with numeric examples, the 10-tag limit, copyright value mapping, cover URL scheme (https), and draft default behavior. Every parameter receives meaningful elaboration beyond its type.
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 '发布文章帖子' (publish article post), specifying it accepts plain text or Markdown with server-side conversion. This precise verb+resource distinguishes it from sibling tools like mfuns_publish_video and mfuns_create_feed.
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 simply lists arguments without mentioning use cases, exclusions, or situations where another sibling tool would be more appropriate, leaving the agent to infer from the tool name alone.
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 are provided, so the description carries the burden. The verb '查看' (view) indicates a read-only operation, which is a positive behavioral disclosure. However, it does not mention authentication requirements, pagination behavior, or potential side effects (though likely none exist). For a simple read tool, this is adequate but not rich.
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 compact and front-loaded with a one-sentence overview followed by a clear Args list. No filler; every sentence provides essential 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 tool's simplicity, the description covers the core behavior and parameters. An output schema exists, so return values are presumably defined elsewhere. It lacks explicit notes about auth or pagination, but for a basic private message viewer, it is sufficiently complete.
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?
The description adds significant meaning beyond the raw schema. It explains the 'action' parameter's allowed values (list/read) with defaults, and specifies that 'user_id' is required for 'read'. This fully compensates for the 0% schema description coverage and leaves no ambiguity about parameter usage.
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 views private message conversation lists or chat history with a user. It uses a specific verb (view) and resource (private messages), which adequately distinguishes it from sibling tools like mfuns_read_thread (public threads) and mfuns_browse. However, it does not explicitly contrast with alternatives, so it misses the full 'distinguishes from siblings' criterion.
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 Args section provides clear context for usage: action 'list' retrieves conversation lists (default), and 'read' retrieves chat history with a user, requiring user_id. This gives a clear sense of when to use each action though it does not explicitly mention when not to use the tool or compare with alternatives like mfuns_read_thread.
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 are provided, so the description carries the burden. It clearly discloses the mutating behavior (like, cancel like, dislike) and implies reversibility through 'cancel', but it does not mention authentication requirements, rate limits, or consequences like public reaction counts. This is adequate but not rich.
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 compact and front-loaded: one summary line followed by a clear Args block. Every line adds necessary parameter semantics with no filler.
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?
For a simple reaction tool, the description covers all parameters and core behavior, and an output schema exists so return values need no explanation. It omits optional context such as whether cancel also removes dislikes or whether authentication is required, but overall is complete enough.
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?
The input schema has no descriptions (0% coverage), but the description fully compensates by defining resource_type with labeled options, resource_id, and action with defaults and allowed values. This adds concrete meaning 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 uses specific verbs '点赞/取消点赞/点踩' and lists resource types (article/video/comment/feed), clearly distinguishing it from sibling tools like mfuns_favorite or mfuns_comment. The resource_id and action options further specify the operation.
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 via action options (like/cancel/dislike) and resource_type list, but does not explicitly state when to prefer mfuns_react over alternatives such as mfuns_favorite or mfuns_comment. No when/not or alternative guidance is present, so it only reaches implied usage level.
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 adds behavioral context by explaining how comment_depth controls the hierarchy (1 vs 2) and how comment_limit caps the number of comments. The read operation is implied non-destructive, though it does not state error handling or permissions.
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 and well-structured: a one-line purpose followed by a clean Args list with clear explanations. No redundant or irrelevant information, and every sentence earns its place.
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 is adequate for a simple read operation: it states the purpose and explains all parameters. An output schema exists, so return values are covered. However, it lacks explicit usage guidelines (e.g., when to prefer this over siblings) and does not mention edge cases like invalid feed_id, which would make it fully complete.
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%, and the description compensates fully by explaining all three parameters in detail: feed_id is the feed ID, comment_depth specifies the comment nesting level with defaults, and comment_limit caps the returned comments with a default. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads feed details and comments with a specific verb ('读取') and resource ('动态详情与评论区'). It is unambiguous and matches the tool name, though it does not explicitly distinguish from sibling tools like mfuns_read_thread or mfuns_read_video.
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 by explaining the parameters (comment_depth, comment_limit), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Usage context is implied from the operation name and description.
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 must carry the transparency burden. It discloses the read-only nature via '读取' (read) and explains comment_depth behavior (1=top-level only, 2=with replies). However, it does not describe the return structure, pagination, error handling, or whether the video details and comments are returned together. This leaves several behavioral aspects 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 concise and well-structured: a one-sentence purpose statement followed by a clear Args list. Every line conveys necessary information without redundancy or fluff. The parameter list is easy to scan, and the use of defaults is explicitly noted.
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 (though not shown), the description does not need to explain return values. It covers the purpose and all parameter semantics thoroughly. The only gap is the lack of usage guidelines relative to sibling tools, but for a straightforward read operation with three well-documented parameters, it is nearly complete.
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?
The input schema has 0% description coverage, but the tool description provides detailed meanings for every parameter: video_id as '视频 ID', comment_depth with explicit value semantics (1=top-level, 2=with replies), and comment_limit as the maximum number of comments. This fully compensates for the schema's lack of descriptions, adding real value.
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: '读取视频详情与评论区' (read video details and comments section). It uses a specific verb+resource structure that distinguishes it from siblings like mfuns_read_feed and mfuns_read_thread, which handle different content types. The scope is 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 this tool is for retrieving a specific video's details and comments, but it does not explicitly contrast with alternative tools like mfuns_read_feed or mfuns_read_thread. There are no 'when to use' or 'when not to use' instructions, leaving the agent to infer context from the tool name alone.
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 are provided, so the description bears full responsibility. It discloses the ownership restriction ('仅限本人内容'), which is a key behavioral trait. However, it does not mention irreversibility, side effects, or error behavior for invalid/unauthorized targets, leaving significant transparency 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 extremely concise: a one-line purpose followed by a two-line args list. It is front-loaded with the action and uses no filler words, making it highly efficient and easy to parse.
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 an output schema (though not shown), so return values are not required in the description. It covers the core action and parameters, but lacks critical context like permanence of deletion and error handling. For a delete tool, this is a notable gap, placing it at an adequate but incomplete level.
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 fully compensates by explaining both parameters: target_type enumerates the allowed values (feed=动态, comment=评论) and target_id is defined as the object ID. This adds essential semantics beyond the bare schema types.
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 deletes content (feed or comment) and restricts to own content. The verb 'delete' is specific, and the resource is defined, differentiating it from sibling read/write tools. It also lists the two possible targets, making the purpose unambiguous.
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 provides clear context that only the user's own content can be deleted, which is an important usage constraint. However, it does not explicitly mention when to use this tool versus alternatives, though it is the only delete tool among siblings. The ownership limitation is the only usage guidance, but it is helpful.
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 are provided, so the description must convey behavioral traits. It accurately describes the search operation and documents valid type values, but it does not disclose whether the operation is read-only, any authentication requirements, rate limits, or result ordering. The verb '搜索' implies a non-mutating action, which partially compensates.
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 and well-structured: a one-sentence purpose followed by a clean argument list. Every sentence provides value, and the front-loaded summary makes the tool's purpose immediately clear.
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?
For a search tool with three simple parameters, the description adequately covers the purpose and parameters. The presence of an output schema means return values do not need to be described in the text, so no critical information is missing.
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?
The input schema has 0% description coverage, but the description fully explains all three parameters: query, type (with values resource and user), and size (default 20, max 50). This adds essential meaning beyond the schema, which only provides type and default information without 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 states it searches Mfuns community content (articles/videos) or users, using the specific verb '搜索' and defining the resource scope. This distinguishes it from sibling tools like mfuns_browse or mfuns_read_thread, which focus on browsing or reading rather than searching.
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 searching but does not explicitly state when to prefer it over alternatives like mfuns_browse or mfuns_get_user. It provides no exclusionary guidance or comparison with sibling tools, so the usage context is only implied.
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 are provided, so the description carries the full burden. It discloses the main outputs (notifications and unread count) and parameter semantics, but does not mention potential side effects (e.g., marking notifications as read) or permission requirements. Since it's a 'get' operation, the impact is moderate, but the lack of explicit disclosures keeps it at a 3.
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 and well-structured: a single opening line states the purpose, followed by a clean argument list. Every sentence adds value without repetition or filler.
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 output schema exists, so return values are covered. The description adequately explains the tool's purpose and parameters. It includes unread count, which is a key output. Minor gaps like pagination details or notification behavior when empty could be added, but it's largely complete for a simple retrieval tool.
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?
The input schema has 0% description coverage, but the description fully compensates by explaining the semantics of `type` (like/comment/mention) and `page` (page number, default 1). This gives the agent clear guidance on parameter values and their meanings.
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 uses a specific verb '获取' (obtain) and clearly defines the resource as '通知消息' (notification messages) with received likes/comments/mentions and unread count. This precisely distinguishes it from sibling tools like mfuns_messages by focusing on notification-specific actions.
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 provides clear context for when to use this tool (fetching notifications by type), and explains the type parameter options. However, it does not explicitly mention when not to use it or name alternative tools, though the context is sufficient for most use cases.
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 explains the behavior of comment_depth and comment_limit parameters well, but does not disclose other traits such as return format, authentication requirements, or pagination details. For a read-only tool, this is adequate but not rich.
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 front-loaded with a clear purpose and usage context, followed by a compact parameter list. Every sentence is informative, with no unnecessary words or repetition.
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?
An output schema exists, so return values are already covered. The description covers purpose, usage, and all parameters thoroughly. It does not explicitly name alternatives, but for a straightforward read tool, this is reasonably complete.
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?
The schema description coverage is 0%, and the description fully compensates by explaining each parameter: article_id, comment_depth with its two levels, and comment_limit with default. This adds essential meaning beyond the typed 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 reads post details and comments, and identifies it as the most commonly used read tool and a must-read before replying. This specific verb+resource distinction separates it from siblings like mfuns_read_video and mfuns_read_feed.
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 phrase '回复前必读' (must read before replying) gives a clear context for when to use this tool, and '最常用的读取工具' (most commonly used read tool) implies it is the default choice for reading. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
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 must disclose behavior. It explains the log is organized by date as JSON files and that filters are optional, which is useful. However, it doesn't explicitly confirm read-only semantics beyond the word 'query' or mention error handling or permission requirements, leaving some burden unmet.
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 one introductory sentence plus a tight three-item Args list. Everything earns its place with no fluff or repetition, and the main purpose appears first.
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?
For a simple, three-parameter query tool with an output schema, the description covers purpose, parameters, and data organization. No critical context is missing, and the tool's role relative to siblings is distinct.
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?
The schema provides zero parameter descriptions, but the description's Args section fully compensates: it gives the date format (YYYY-MM-DD), clarifies 'tool' is an optional filter by tool name, and defines 'target_id' as filtering by affected object ID. This exceeds the minimal schema types.
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 queries the Activity Log, a record of every tool call stored as date-separated JSON files. It specifies the resource (Activity Log) and the action (query), and distinguishes it from sibling content-reading tools by focusing on operation logs.
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 implies usage: call this when you need to audit tool operations by date, optionally filtered by tool or target ID. It doesn't explicitly mention alternatives or exclusions, but the unique purpose among siblings makes the context clear.
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?
The description discloses that 'latest' mode returns LLM-optimized Markdown from a third-party aggregator (mfuns.wgen.top), and that category_id is ignored in non-category modes. It does not explicitly state that the operation is read-only or mention auth/rate limits, but for a browse tool the read-only nature is implied and the markdown detail adds useful context.
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 compact and well-structured: a one-line summary followed by a clean Args list with each parameter on a separate line. Every sentence adds necessary information with no fluff.
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?
With 4 optional parameters and an output schema present, the description covers all parameter semantics, mode-specific behavior, and the special markdown format for latest mode. It lacks error handling details but that is not critical given the tool's simplicity and the presence of an output 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?
The description explains every parameter in detail, including mode options with Chinese translations, category_id requirement and examples (51=交友专区, 49=站内互动), limit defaults/max, and content_type valid values for latest mode. This fully compensates for the schema's 0% description 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 clearly states the tool's function: browsing Mfuns community content streams, and enumerates specific modes (recommend, hot, feed, category, latest). This distinguishes it from sibling tools like mfuns_read_thread (reading a single thread) or mfuns_search (searching).
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 provides mode-specific guidance (e.g., category_id required for mode=category) but does not explicitly state when to use this tool versus alternatives like mfuns_search or mfuns_read_thread. Usage is implied rather than explicitly contrasted with other tools.
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 content is plain text and automatically converted to forum format, which is a useful behavioral trait. It also explains the conditional meaning of target_id based on target_type. It does not discuss auth or rate limits, but for a simple comment tool with an output schema, this is reasonably transparent.
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 and well-structured: a one-sentence purpose statement followed by a clear Args list. Every sentence adds value, and there is no repetition of schema-encoded information beyond what is needed for clarification.
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 low complexity, the presence of an output schema, and the complete parameter documentation in the description, the description is sufficiently complete. It covers what the tool does, how parameters behave, and a key behavioral conversion detail.
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 compensates by explaining each parameter in detail: target_type enumerates valid values and their meanings, target_id is mapped to the correct object type, and content is described as the comment/reply text. This goes well 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 opens with a specific verb and resource: '发表评论或回复评论' (post a comment or reply to a comment), and lists the exact target types (article, video, feed, comment). This clearly distinguishes it from sibling tools like create_post, react, and favorite.
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 provides clear context for when to use the tool by defining target_type options and their meanings. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous enough that an agent can infer it is for commenting/replies rather than creating posts or reactions.
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 discloses that the tool returns the complete category tree (返回完整分区树) and explains the semantic difference between leaf and parent categories (叶子分区可投稿，父级分区仅作导航). This goes beyond a basic query description, though it could mention potential authentication requirements or errors. Still, it is quite informative for a simple read-only tool.
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 exceptionally concise: two short sentences. The first sentence states the purpose and usage context, the second clarifies the parameter situation and return semantics. Every word earns its place, with no filler or redundant information.
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 zero-parameter schema, the presence of an output schema, and the tool's simple nature, the description covers all necessary context. It explains what the tool returns, the structural distinction between leaf and parent nodes, and when to use it. The output schema handles detailed return fields, so the description need not elaborate further.
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 tool has 0 parameters, so the baseline is 4. The description explicitly states '无参数' (no parameters), confirming the absence of inputs. Schema coverage is 100% with an empty properties object, so there is no additional parameter information needed.
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 queries the submission category tree (查询投稿分区树) and specifies its purpose: selecting category_id before publishing posts/videos. This specific verb+resource description distinguishes it from sibling tools like mfuns_create_post or mfuns_publish_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use the tool: '发布帖子/视频前用 mfuns_categories 选 category_id' (before publishing posts/videos, use mfuns_categories to select category_id). This provides clear context and implies it is the correct tool for category selection, differentiating it from other submission-related tools.
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, the description must disclose behavior. It explains category_id fallback behavior, copyright default meanings, and tag limits, which goes beyond the schema. However, it does not mention side effects, authentication, or error behavior, so it falls short of full 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 compact: one opening sentence plus a bulleted Args list. Each parameter entry provides essential information without redundancy, making it well-structured and 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?
For a publish tool with 7 params and an output schema, the description covers the purpose, all parameter semantics, and usage constraints. Since the output schema exists, the lack of return-value explanation is acceptable, making the description contextually complete.
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%, yet the description meticulously documents all 7 parameters with constraints (e.g., title max 30 chars, video_url https, category leaf behavior, copyright codes, tags max 10). This fully compensates for the missing 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 states '外链视频投稿' (external link video submission) with a specific verb and resource, and distinguishes it from local upload by noting '不含本地上传'. This differentiates it from sibling tools like mfuns_create_post or mfuns_manage_submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context: '如复活失效的 B 站外链视频' (e.g., reviving invalid Bilibili external link videos) and an explicit exclusion '不含本地上传'. This gives clear when-to and when-not-to use guidance, though no alternative tool is named.
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:

[![Mfuns_MCP MCP server](https://glama.ai/mcp/servers/ymltsh/Mfuns_MCP/badges/card.svg)](https://glama.ai/mcp/servers/ymltsh/Mfuns_MCP)

Score Badge

Copy to your README.md:

[![Mfuns_MCP MCP server](https://glama.ai/mcp/servers/ymltsh/Mfuns_MCP/badges/score.svg)](https://glama.ai/mcp/servers/ymltsh/Mfuns_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/ymltsh/Mfuns_MCP'

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