sau-mcp

by xyc667

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool is uniquely identified by platform (douyin, kuaishou, xiaohongshu, bilibili) and action (check, upload_video, upload_note). No two tools overlap in purpose; check tools validate cookies while upload tools publish content.
Naming Consistency5/5
All tools follow a consistent pattern of platform_action (e.g., kuaishou_upload_video, bilibili_check), with douyin_upload_note as a logical variant. The utility sau_health also uses snake_case and fits the naming scheme.
Tool Count5/5
10 tools serve four platforms, each with a check and upload video action, plus an extra Douyin note upload and a health check. This is well-scoped and not excessive for the apparent purpose.
Completeness4/5
Core functionality (cookie validation and video upload) is covered for all platforms, and Douyin additionally supports image notes. Minor gaps exist, such as no note upload for other platforms and no management operations (list/delete), but these are not critical for the upload-focused domain.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states the operation itself and provides no information about side effects (e.g., publishing publicly), required authentication, rate limits, or potential failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified, consisting of a single generic sentence that adds little beyond the tool's name. While brief, it fails to include essential context expected for a tool with 7 parameters, making it incomplete rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters), no annotations, no parameter descriptions, and no usage context, the description is severely incomplete. It does not mention what 'sau CLI' entails, how the upload behaves, or what the output schema contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description offers no explanation of parameters such as account, file, title, tags, headless, or schedule. The agent receives no additional meaning beyond the raw property names.
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 action (upload and publish), the resource (a Douyin video), and the mechanism (via sau CLI). It distinguishes itself from sibling tools like douyin_upload_note by specifying 'video' as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as douyin_upload_note or other platform uploaders. The description lacks any context about prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'upload and publish' which implies mutation but fails to mention authentication requirements, rate limits, or consequences of publishing. This is insufficient for a publishing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the primary purpose. While it's short, it earns each word for stating the core action, though it lacks detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters), lack of annotations, and 0% schema description coverage, the description is far from complete. It only addresses purpose, not usage details, parameter explanations, or behavioral outcomes, making it inadequate for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. With 7 parameters including account, images, title, tags, headless, and schedule, the description provides zero semantic guidance beyond the schema names, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (upload and publish), the target platform (Douyin), the content type (image note), and the method (sau CLI). It clearly differentiates from sibling tools like douyin_upload_video by specifying 'image note'.
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 vs alternatives like douyin_upload_video. The description implies usage for image notes but does not mention exclusions, prerequisites, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the high-level action. It fails to disclose important traits such as authentication requirements, side effects of publishing, headless mode behavior, or scheduling semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence and is front-loaded, containing no redundant filler. However, it is terse to the point of under-specification for a 7-parameter tool, which limits its usefulness but still maintains structural efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 3 required, and an output schema, the one-sentence description is grossly incomplete. It omits parameter semantics, usage context, side effects, and any behavioral detail, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/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 with zero parameter information. It does not clarify the meaning of required fields (account, file, title) or optional fields (desc, tags, headless, schedule), leaving the agent without any semantics beyond raw parameter names.
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 with a specific verb ('Upload and publish') and resource ('Xiaohongshu video'), which distinguishes it from sibling check tools (e.g., xiaohongshu_check) and upload tools for other platforms (e.g., douyin_upload_video, bilibili_upload_video).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or any comparison with other Xiaohongshu or upload tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the action and the CLI ('sau CLI'), without disclosing side effects, authentication requirements, upload behavior, scheduling, headless modes, failure modes, or return values. This is minimal transparency for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is front-loaded and easy to parse. While brief, it earns its place by stating the tool's purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter upload tool with no annotations, the description is severely incomplete. It provides no context about required arguments, optional settings, scheduling, headless behavior, or prerequisites. Even with an output schema present, the description fails to convey essential usage context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the 8 parameters. It does not explain the meaning of 'account', 'file', 'title', 'tid', 'desc', 'tags', 'headless', or 'schedule', leaving the agent to rely solely on parameter names and defaults.
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 verb phrases 'Upload and publish' and names the resource 'a Bilibili video' via 'sau CLI', clearly identifying the tool's action and scope. It distinguishes itself from sibling tools like bilibili_check and other platform uploaders by naming Bilibili and the upload/publish action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to upload/publish a Bilibili video. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., bilibili_check for status checks) or any exclusions. The context is clear but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It only states 'upload and publish' and 'via sau CLI', offering no details on side effects, authentication requirements, or operational risks. The agent knows it is a write/publish operation but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler, which is concise. However, it is so brief that it sacrifices essential detail, making it minimally useful despite its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a tool with 7 parameters, 3 required, and a complex operation like uploading and publishing to a social platform, the one-sentence description is severely incomplete. It provides no guidance on parameter semantics, success/failure behavior, or return value, and the output schema does not compensate for the lack of explanatory context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage (0%), and the description adds no parameter-specific meaning. It does not explain what 'account', 'file', 'title', 'desc', 'tags', 'headless', or 'schedule' mean or how they should be used, leaving the agent with only parameter names to infer from.
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 action ('Upload and publish'), the target resource ('a Kuaishou video'), and the mechanism ('via sau CLI'). This is specific and distinct from sibling tools like douyin_upload_video or bilibili_upload_video by naming the platform.
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 use for Kuaishou video uploads, which differentiates it from other platform upload tools, but it does not explicitly state when to use it versus alternatives or provide exclusions. The context from sibling names offers indirect guidance only.
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?
Without annotations, the description must carry the full burden of behavioral disclosure, but it only states what the tool does. It does not reveal whether the operation is read-only, whether network calls are made, what side effects might occur, or what the output structure looks like despite having an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose with no redundant words. It is front-loaded and appropriately sized for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and sparse schema (0% description coverage), the description leaves significant gaps: no usage guidelines, no behavioral disclosures, and no parameter explanation. The output schema is present but not described in text, so the agent lacks crucial operational context for a complete understanding.
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 schema provides only a parameter named 'account' with type string and no description; the description also does not explicitly define the parameter. However, the tool's description hints that 'account' refers to the Bilibili cookie, giving slight semantic context, but it does not clarify expected format or examples.
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 with a specific verb ('Check') and resource ('a Bilibili account cookie is valid'), distinguishing it from sibling tools that check other platforms or upload content. It uniquely identifies the Bilibili platform and the validity-check intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like kuaishou_check or douyin_check. It does not mention prerequisites, scenarios, or exclusions, leaving the agent without context for tool selection beyond the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states that the tool 'checks' cookie validity, but does not explain whether this involves network requests, side effects, or what constitutes an invalid cookie. For a read-only check, this is 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 a single, clear sentence with no unnecessary words. It front-loads the action and resource, achieving maximum conciseness with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks essential context such as parameter semantics and usage guidelines. It is minimal and leaves the user to infer the tool's role and input requirements. For a simple tool this is somewhat acceptable, but clear gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning or expected format of the 'account' parameter. The name 'account' could refer to an account ID or the cookie string itself, but the description does not disambiguate. This is a significant gap given the schema offers no help.
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 ('Check') and identifies the exact resource ('Xiaohongshu account cookie') and the purpose ('is valid'). This clearly distinguishes the tool from sibling check tools like kuaishou_check and bilibili_check, which target different platforms.
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 used to validate a cookie before performing Xiaohongshu operations, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites. The context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the core behavior (checking cookie validity) but does not disclose what constitutes 'valid', whether it makes a network request, what error conditions exist, or what side effects (e.g., session refresh) might occur. This is thin for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence that directly states the tool's purpose. Every word earns its place with no filler or redundancy; it is appropriately minimal for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema (which presumably defines return values), the description covers the primary purpose. However, it lacks critical contextual details such as behavioral prerequisites, response format specifics, or failure modes. The absence of any annotation makes it only minimally complete.
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 input schema has a single 'account' parameter with no description, and schema description coverage is 0%. The description mentions 'Kuaishou account cookie' but does not explicitly define whether 'account' refers to the cookie string itself, an account ID, or a credential object. Since the description does not clarify the parameter semantics, agents must rely on inference, which is risky.
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 specifies the verb 'Check', the resource ('Kuaishou account cookie'), and the intended outcome ('is valid'). It is unambiguous and distinguishes itself from sibling check tools for other platforms (xiaohongshu, bilibili, douyin) by naming the specific platform.
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 used to validate a Kuaishou cookie, which is clear enough for the main use case. However, it does not explicitly state when to use it over alternatives (e.g., other check tools) or mention any preconditions like needing a logged-in account or cookie format. There is no exclusionary 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?
No annotations are provided, so the description carries the full burden. It mentions checking config and running a command, which implies a diagnostic read-only operation, but does not explicitly confirm safety, side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a clear action verb and objects. It is front-loaded and contains no filler.
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 zero-parameter diagnostic tool with an output schema, the description adequately covers the tool's behavior. It explains what is checked and the condition verified, which is complete for this simple 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?
The tool has zero parameters, and the schema is empty, providing complete coverage. No parameter explanation is needed, so the description does not need to compensate for schema gaps.
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: checking MCP wrapper config and verifying that `sau --help` runs. It distinguishes this tool from platform-specific upload/check siblings by focusing on the wrapper health check.
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?
No explicit guidance on when to use this tool versus alternatives. The intended use as a wrapper health check is implied, but the description does not state conditions for use or exclude other tools.
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 carry the transparency burden. It discloses the output format ('stdout: valid/invalid'), which is valuable, but it does not explicitly state read-only behavior, network usage, or potential side effects. For a simple check tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains the essential purpose and output format without any filler. Every word contributes value.
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 one-parameter check tool, the description is nearly complete: it states the action, the resource, and the expected output. The output schema is present (even if not shown), and the description aligns with it. Minor gaps exist, such as not describing error behavior, but the tool's simplicity mitigates this.
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 schema only provides a bare string parameter named 'account' with 0% description coverage. The description adds critical meaning by specifying it is a 'Douyin account cookie', clarifying that the parameter is the cookie string itself, not just an account name.
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 specifies the action ('Check'), the target resource ('Douyin account cookie'), and the outcome ('valid/invalid'). It distinguishes from sibling tools by explicitly naming the platform and the operation type, unlike upload or other platform checks.
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 clearly implies usage for validating a Douyin cookie, which is a distinct context from sibling checks for other platforms. No explicit alternatives are named, but the platform-specific purpose makes it unambiguous when to use this tool.
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:

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

Score Badge

Copy to your README.md:

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

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