AstrBot MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as config management, message handling, and logging. However, send_platform_message and send_platform_message_direct could be confusing as both involve sending messages, though one targets WebChat and the other real platforms. The descriptions help clarify this, but some overlap exists.
Naming Consistency4/5
Tool names generally follow a consistent snake_case pattern with descriptive verbs and nouns, like apply_astrbot_config_ops and get_astrbot_logs. There are minor deviations, such as browse_plugin_market using 'browse' instead of 'list' or 'get', but overall the naming is predictable and readable.
Tool Count5/5
With 11 tools, the count is well-suited for managing an AstrBot instance, covering config operations, messaging, logging, and system control. Each tool serves a clear function without redundancy, making the set comprehensive yet manageable for the domain.
Completeness4/5
The toolset provides strong coverage for AstrBot management, including config inspection, editing, messaging, logging, and system restarts. A minor gap is the lack of tools for plugin installation or management beyond browsing the market, but core workflows are well-supported.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool returns only matched key paths (no big values) and describes return format, which is helpful. However, it doesn't address important behavioral aspects like whether this is a read-only operation, potential performance impacts, rate limits, authentication needs, or error conditions.
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 efficiently structured with clear sections (purpose, modes, returns). Every sentence earns its place, with no redundant information. The front-loaded purpose statement is followed by necessary details in bullet format.
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 6 parameters with 0% schema coverage and no annotations, the description provides some context but has significant gaps. While it explains the tool's purpose and return format (and an output schema exists), it doesn't adequately cover parameter semantics or behavioral aspects needed for a search tool with multiple configuration options.
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?
Schema description coverage is 0%, so the description must compensate for all 6 undocumented parameters. While it explains the purpose of key_query and value_query in the 'Modes' section, it doesn't address the semantics of conf_id, system_config, case_sensitive, or max_results parameters. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches AstrBot config and returns matched key paths without big values, specifying the verb 'search' and resource 'AstrBot config'. It distinguishes from siblings like 'inspect_astrbot_config' by focusing on searching rather than inspecting, but doesn't explicitly differentiate from all siblings like 'list_astrbot_config_files'.
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 implied usage through 'Modes' section, explaining when to use key-only vs. key+value queries. However, it doesn't explicitly state when to use this tool versus alternatives like 'inspect_astrbot_config' or 'list_astrbot_config_files', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states it retrieves a list but doesn't disclose behavioral traits such as permissions needed, rate limits, pagination, or error handling. The API endpoint reference adds minimal context, leaving key operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and includes the API endpoint without unnecessary elaboration. It is front-loaded and wastes no words, making it highly concise and well-structured.
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 (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and siblings present, it lacks context on usage scenarios and behavioral details, making it incomplete for optimal agent guidance despite the output schema covering return values.
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 with 100% schema description coverage, so no parameter details are needed. The description doesn't add parameter semantics, but this is acceptable given the absence of parameters, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('获取' meaning 'get') and the resource ('消息平台列表' meaning 'message platform list'), specifying it retrieves configured platforms in AstrBot. It doesn't explicitly differentiate from siblings like 'get_platform_session_messages' or 'send_platform_message', but the purpose 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 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. It mentions the API endpoint ('/api/config/platform/list'), but doesn't explain scenarios, prerequisites, or exclusions relative to siblings like 'inspect_astrbot_config' or 'list_astrbot_config_files'.
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 states the action ('List') and API endpoint, but lacks details on permissions, rate limits, pagination, or response format. For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List AstrBot config files (abconfs)') and includes the API endpoint as supplementary detail. There is zero waste, and every word earns its place.
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 (0 parameters, read-only list operation) and the presence of an output schema, the description is minimally adequate. However, it lacks context on behavioral aspects like permissions or pagination, and no annotations compensate. For a tool with siblings, more guidance would improve completeness.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description correctly omits parameter details, aligning with the schema. A baseline of 4 is appropriate as it avoids redundancy, though it doesn't add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('AstrBot config files (abconfs)'), making the purpose unambiguous. It distinguishes from siblings like 'inspect_astrbot_config' (which inspects rather than lists) and 'search_astrbot_config_paths' (which searches paths rather than listing files). However, it doesn't specify if this lists all files or has implicit filters, preventing a perfect score.
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 like 'search_astrbot_config_paths' or 'inspect_astrbot_config'. It mentions the API endpoint ('/api/config/abconfs'), but this is technical detail rather than usage context. No exclusions, prerequisites, or comparative advice are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'step-by-step exploration' and drilling down, which hints at iterative use, but doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what happens with invalid inputs. For a tool with 7 parameters and no annotations, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a brief explanation of usage. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 complexity (7 parameters, no annotations, but with an output schema), the description is incomplete. It covers the purpose and basic usage but lacks details on parameter meanings and behavioral traits. The output schema helps by documenting return values, but the description doesn't fully address the gaps in parameter semantics and transparency, making it only minimally adequate.
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?
Schema description coverage is 0%, meaning none of the 7 parameters are documented in the schema. The description only mentions 'path' and implies its usage for exploration, but doesn't explain other parameters like conf_id, system_config, include_value, max_children, redact_secrets, or max_string_length. This fails to compensate for the low coverage, leaving most parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inspect a node in an AstrBot config JSON.' It specifies the verb ('inspect') and resource ('node in an AstrBot config JSON'), making it distinct from siblings like list_astrbot_config_files or search_astrbot_config_paths. However, it doesn't explicitly differentiate from all siblings, such as get_astrbot_logs, which might also involve inspection but of logs rather than configs.
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 usage: 'This tool is designed for step-by-step exploration' with examples like starting with path=None and drilling down. This implies when to use it (for exploration) but doesn't explicitly state when not to use it or name alternatives like list_astrbot_config_files for listing files instead of inspecting nodes. The guidance is helpful but lacks explicit exclusions.
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 full burden. It discloses that the tool triggers a restart and waits for AstrBot to become available again, which is useful behavioral context. However, it lacks details on permissions required, whether it's idempotent, potential downtime duration, or error handling (e.g., what happens if restart fails).
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 with two sentences that directly explain the action and post-action behavior. It's front-loaded with the core purpose. While efficient, it could be slightly more structured by explicitly separating purpose from behavioral notes.
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 complexity (a system restart operation with no annotations), the description is minimally adequate. It explains what the tool does but lacks critical context like permissions, side effects, or error scenarios. The presence of an output schema helps, but the description doesn't leverage it to clarify return values or success criteria.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's effect. A baseline of 4 is applied as per rules for 0-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('重启' meaning restart) and the target resource ('AstrBot Core'), making the purpose understandable. It distinguishes from siblings by focusing on core restart rather than configuration, messaging, or logging operations. However, it doesn't explicitly contrast with potential similar tools like 'apply_astrbot_config_ops' which might also affect system state.
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 doesn't mention prerequisites (e.g., needing admin permissions), when it's appropriate (e.g., after config changes, during troubleshooting), or what side effects might occur (e.g., temporary service interruption). Without such context, an agent might misuse it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it calls a specific endpoint (POST /api/platform/send_message), handles media uploads for local files, and forwards URLs as-is. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the output contains, which are important 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 appropriately sized and front-loaded with the core purpose in the first sentence. The 'Notes' section efficiently covers key behavioral details. However, the second sentence about the endpoint is somewhat technical and could be integrated more smoothly, and there's minor redundancy in the media parts explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 9 parameters, 0% schema coverage, no annotations, but an output schema, the description is moderately complete. It covers the purpose, some behavioral traits, and media handling, but lacks parameter explanations, error handling, authentication needs, and doesn't leverage the output schema to describe return values. It's adequate but has significant gaps.
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?
Schema description coverage is 0%, so the description must compensate for 9 parameters. It only provides semantics for 'file_path' and 'url' in media parts, ignoring 'platform_id', 'target_id', 'message_chain', 'message', 'images', 'files', 'videos', 'records', and 'message_type'. The description adds minimal value beyond what the bare schema provides, failing to explain parameter purposes or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Directly send a message chain to a platform group/user (bypass LLM).' It specifies the verb ('send'), resource ('message chain'), and target ('platform group/user'), but doesn't explicitly differentiate from its sibling 'send_platform_message' (without '_direct'), leaving some ambiguity about what 'bypass LLM' means in practice.
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 some usage context with 'This is for sending to a real platform target (group/user), not WebChat,' which implies when to use it (real platforms) and when not (WebChat). However, it doesn't explain when to choose this tool over its sibling 'send_platform_message' or other messaging alternatives, leaving the 'bypass LLM' distinction unclear for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'save + hot reload' which implies mutation and side effects, but does not address critical aspects like permissions needed, error handling, or whether changes are reversible, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose upfront, followed by specific details on operations and path syntax. Every sentence adds value without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema coverage, and an output schema (which reduces need to explain returns), the description covers core operations and syntax but lacks completeness in addressing behavioral risks, parameter details for 'conf_id' and 'create_missing', and integration context with siblings.
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?
Given 0% schema description coverage, the description compensates well by detailing the structure and examples of the 'ops' parameter (e.g., set, add_key, append operations with path/value formats) and mentions 'path' syntax, adding substantial meaning beyond the bare schema. However, it does not explain 'conf_id' or 'create_missing' parameters.
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 specific action ('apply multiple edits', 'save + hot reload') and resource ('AstrBot config'), distinguishing it from sibling tools like inspect_astrbot_config or list_astrbot_config_files by emphasizing batch editing and reloading functionality.
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 ('batch in a single tool call') and implies usage for multiple edits, but does not explicitly state when not to use it or name specific alternatives among siblings like inspect_astrbot_config for read-only operations.
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 key behavioral traits: the tool can operate in two modes (immediate historical retrieval vs. live streaming via SSE), mentions specific API endpoints (/api/log-history, /api/live-log), and describes time-based triggering. It doesn't cover aspects like rate limits, authentication needs, or error handling, but provides substantial operational 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 extremely concise and well-structured: a brief purpose statement followed by two bullet points that clearly explain the conditional behavior. Every sentence earns its place with no wasted words, and it's front-loaded with the core functionality.
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 (which handles return values), no annotations, and simple parameters, the description is reasonably complete. It explains the dual-mode operation and API endpoints well. The main gap is the undocumented 'max_events' parameter, but overall it provides sufficient context for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of 'wait_seconds' thoroughly (immediate vs. streaming behavior based on value). However, it doesn't mention 'max_events' at all, leaving one of the two parameters undocumented. The description adds significant value for one parameter but misses the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool '获取 AstrBot 日志' (gets AstrBot logs), which is a clear verb+resource combination. However, it doesn't distinguish this from potential sibling tools that might also retrieve logs or differentiate between historical vs. live log retrieval. The purpose is understandable but lacks specificity about what kind of logs or scope.
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 explicit guidance on when to use different behaviors based on the 'wait_seconds' parameter: immediate return for historical logs vs. streaming live logs. This gives clear context for parameter-driven usage. However, it doesn't mention when to use this tool versus sibling tools like 'get_platform_session_messages' or other logging-related tools that might exist.
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 full burden of behavioral disclosure. It describes the tool's core functionality (sending message chains) and mentions some behavioral aspects: optional parameters that auto-build message chains, automatic session creation if session_id is empty, and that enable_streaming affects SSE event types. However, it doesn't cover important behavioral traits like whether this is a read-only or destructive operation, rate limits, authentication requirements, error conditions, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter explanations. It's appropriately sized for a complex tool with 19 parameters. Most sentences add value, though some parameter explanations could be more concise. The information is front-loaded with the core purpose first.
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 complexity (19 parameters, no annotations, 0% schema description coverage, but with output schema), the description is moderately complete. It explains the core functionality and many parameters but leaves 8 parameters undocumented. The existence of an output schema means the description doesn't need to explain return values, but for a mutation tool with no annotations and poor schema documentation, more behavioral context would be helpful.
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?
With 0% schema description coverage, the description must compensate for the schema's lack of parameter documentation. The description provides meaningful semantic information for 7 parameters (platform_id, message_chain, message, images, files, videos, records, session_id, selected_provider, selected_model, enable_streaming), explaining what they represent and how they interact. However, it doesn't cover the remaining 8 parameters (target_id, message_type, conversation_id, use_last_session, new_session, reply_to_message_id, reply_to_last_saved_message, reply_to_last_user_message), leaving significant 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 purpose: '通过 AstrBot 的 Web Chat API 发送消息链（支持文本、图片、文件等）' which translates to 'Send message chains via AstrBot's Web Chat API (supports text, images, files, etc.)'. It specifies the verb 'send', the resource 'message chains', and the mechanism 'AstrBot's Web Chat API'. It also distinguishes from sibling 'send_platform_message_direct' by implying this is the standard API-based method.
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 usage: it's for sending messages via AstrBot's Web Chat API. It mentions alternative parameters ('message / images / files / videos / records') that can be used instead of 'message_chain' for convenience. However, it doesn't explicitly state when to use this tool versus the sibling 'send_platform_message_direct', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It effectively describes key behaviors: pagination mechanics (start and count parameters), sorting order (updated_at descending), and what fields are returned in the output. However, it doesn't mention potential rate limits, authentication requirements, or error conditions, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It begins with a clear purpose statement, followed by a '用法' (usage) section detailing modes, and a '返回字段' (return fields) section. Each sentence adds specific value—no wasted words—and information is front-loaded with the most critical details about modes and parameters.
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 moderate complexity (6 parameters, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage modes, parameter semantics, and output structure. Since an output schema exists, the description doesn't need to exhaustively explain return values, and it provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 6 parameters, the description compensates excellently. It explains the semantics of 'mode' (latest vs. search), 'query' (search across multiple fields), 'start' (starting index from 1), and 'count' (number of results). While it doesn't cover 'custom_registry' or 'force_refresh', it provides substantial value beyond the bare schema, making parameter purposes clear.
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: '查看 AstrBot 插件市场（支持搜索与按时间排序）' which translates to 'Browse AstrBot plugin market (supports search and sorting by time)'. It specifies the exact resource (plugin market) and actions (browse with search/sorting), distinguishing it from sibling tools that handle configuration, logs, messages, or restart operations.
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?
The description provides explicit usage guidelines with two distinct modes: 'mode="latest"' for chronological browsing and 'mode="search"' for query-based filtering. It explains when to use each mode based on the user's intent (browse latest vs. search), including details on how results are ordered and paginated, making it clear when this tool is appropriate versus alternatives.
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 full burden and does well by explaining the data source rationale, polling behavior when wait_seconds > 0, and that it returns 'history items from the tail.' It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial behavioral context beyond basic functionality.
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 efficiently structured with a clear purpose statement, usage rationale, and well-organized parameter documentation. Every sentence earns its place, with no redundant information. The parameter explanations are front-loaded with the most critical information 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?
Given the tool's complexity (6 parameters, polling behavior, multiple data sources) and the presence of an output schema (which handles return values), the description provides excellent context. It covers the why (source rationale), when (build-specific usage), how (polling behavior), and what (parameter semantics) without needing to duplicate output schema information.
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?
With 0% schema description coverage for 6 parameters, the description fully compensates by providing clear semantic explanations for all parameters: target_id examples, platform_id default behavior, message_type options and default, wait_seconds polling behavior, max_messages scope, and poll_interval_seconds usage context. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get'), resource ('platform target's recent messages'), and source ('from AstrBot logs'). It explicitly distinguishes this tool from alternatives by explaining it uses '/api/log-history' instead of '/api/conversation/detail' for certain builds, making it distinct from any potential sibling tools that might use different endpoints.
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?
The description provides explicit guidance on when to use this tool versus alternatives: 'This tool intentionally uses AstrBot's log broker history... since some AstrBot builds do not persist platform conversation history under /api/conversation/detail.' This clearly indicates this is the preferred tool for certain build configurations and implicitly suggests alternatives might exist for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![astrbotmcp MCP server](https://glama.ai/mcp/servers/xunxiing/astrbotmcp/badges/score.svg)](https://glama.ai/mcp/servers/xunxiing/astrbotmcp)

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/xunxiing/astrbotmcp'

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