Archery MCP Server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Tools are generally distinct across domains (users, groups, workflows, SQL query, instances). Minor overlap exists between sqlquery_resources and instance_resource, both retrieving resources inside an instance, but descriptions clarify different contexts (user-access vs admin config).
Naming Consistency3/5Most tools follow a snake_case pattern, but styles vary: some are noun_verb (user_create), while others are noun_noun_verb (resource_group_list) or noun_noun (sqlquery_instances). The verb position is inconsistent, e.g., sqlquery_describe_table places the verb in the middle.
Tool Count4/527 tools cover multiple domains (users, groups, workflows, SQL, instances). The count is slightly high but justified by the broad scope of a database management platform. Each tool serves a specific operation without excessive redundancy.
Completeness3/5Core workflows (SQL ticket lifecycle, CRUD for users/instances) are covered. Notable gaps: resource groups and auth groups lack update and delete tools; user management lacks role/permission assignment. Some domains feel incomplete.
Average 3.1/5 across 27 of 27 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
No annotations are provided, so the description carries full burden. It only says 'list' without disclosing pagination behavior, result ordering, permissions needed, or whether it returns all or paginated results. This is severely lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity sacrifices completeness. It does not earn its place because it lacks critical context that would help the agent. An effective description should be front-loaded with purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description must explain return values. It fails to do so, and does not mention pagination behavior, sorting, or any example. The tool is simple but the description is insufficient for an agent to confidently use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should compensate. It adds minimal Chinese translations ('页码' for page, '每页数量' for page_size) but does not explain constraints like range, starting index, or effect of defaults. The schema already provides names and defaults, so added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取资源组列表' (get resource group list), specifying the verb and resource. However, it does not differentiate from sibling list tools like 'workflow_list' or 'instance_list', missing a chance to highlight unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention when not to use, prerequisites, or context (e.g., 'use for listing resource groups; use auth_group_list for authentication groups').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'create' without mentioning side effects (e.g., uniqueness checks, permissions, can it fail?). This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus argument list, which is concise but at the cost of missing essential details. It is well-structured for consumption but under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and zero annotations, the description fails to cover return values, error conditions, or behavioral constraints. It is far from complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It merely restates the parameter name and its Chinese meaning ('权限组名称') without adding format, constraints, or examples. The schema already shows the 'Name' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '创建权限组' (create permission group), indicating a specific verb and resource. It is distinct from sibling tools like auth_group_list (listing) and user_create (users), so differentiation is adequate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, what prerequisites exist, or how it differs from alternatives like resource_group_create. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, authentication needs, side effects). For a DESCRIBE operation, it should explicitly state it is a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with an argument list. It could be slightly more structured, but it efficiently conveys the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations, output schema, or parameter details, the description falls short. It does not explain the return format (e.g., which columns or metadata) or when to use this tool over SQL query tools. The mention of 'DESC TABLE' hints at output but is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only lists parameter names in Chinese without adding meaning beyond the property names. For example, 'schema_name' is marked optional with default empty, but no explanation of its usage or format is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves table structure details using 'DESC TABLE', providing a specific verb and resource. However, it does not differentiate from sibling tools like sqlquery_execute or sqlquery_logs, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context about when to choose sqlquery_describe_table over siblings like sqlquery_execute or instance_table_lookup.
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 clarify behavioral traits. It fails to indicate whether the delete is permanent, reversible, or has cascading effects, which is critical for a destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no wasted words, but it is under-specified for a destructive tool. The extreme brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with no output schema, the description should still clarify important details like permanence, return value, and potential side effects. It currently lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only repeats the parameter name and adds 'user ID', which is already implied by the parameter name and schema title 'User Id'. No additional context or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete user' and lists the required argument, distinguishing it from sibling tools like user_create and user_update. However, it is essentially a restatement of the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. Users are left to infer appropriate usage.
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?
The description indicates a destructive operation ('delete'), but without annotations, it fails to clarify side effects like cascading deletion or required permissions. The agent cannot assess risks beyond the basic destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, but this conciseness comes at the cost of completeness. No irrelevant text exists, so structure is fine.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter, the description lacks critical context about effect, return value, and preconditions. For a delete operation, more details about cascading behavior are expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should add meaning but only repeats 'instance_id: 实例 ID', which is nearly identical to the schema. It does not explain how to obtain the ID or any validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'delete' and resource 'instance configuration', making the tool's purpose clear. However, it does not differentiate from sibling tools like instance_create or instance_update, which also operate on instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as when to use instance_update instead, or any prerequisites or potential consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, result limitations, or authentication needs. The description only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) and includes an Args section. It is concise with no extraneous text, though it could benefit from slightly more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required input, no output schema), the description lacks information about return format, pagination, or limitations. It does not fully equip the agent to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 describes the parameter 'table_name' as '表名', which is already evident from the schema property name 'Table Name'. No additional semantics or constraints are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (查找), resource (实例列表), and filter criterion (按表名). It distinguishes itself from siblings like instance_list (lists all instances) and sqlquery_instances (SQL-based query). However, the phrasing '包含该表的实例' could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No preconditions, exclusions, or mention of related tools like sqlquery_instances or instance_list are provided.
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 full burden. It does not disclose behavioral traits such as read-only nature, pagination behavior, ordering, or potential rate limits. The tool lists groups but no behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with a clear separation between the purpose and parameter list. It uses minimal words, which is efficient for agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should at least hint at what is returned (e.g., list of group objects). It does not. For a list tool with no annotations, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It provides Chinese labels for 'page' (页码) and 'page_size' (每页数量), which clarify the parameters' purpose beyond the schema's type and default. However, no additional constraints or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a list of auth groups ('获取权限组列表'). However, it does not differentiate from sibling tools like 'resource_group_list', which targets a different resource type. The verb 'list' is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., auth_group_create, resource_group_list). No mentions of prerequisites or context for invocation.
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. The description only states 'create', implying mutation, but does not disclose any behavioral traits such as idempotency, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of one line. It front-loads the purpose but may be too brief to be fully helpful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is minimal. It does not explain return value, effects, or edge cases. More context is needed for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage. The description adds 'group_name: 资源组名称' (resource group name), which provides basic meaning for the parameter beyond the schema's type. However, no additional details like format or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '创建' (create) and the target resource '资源组' (resource group), which distinguishes it from sibling tools like resource_group_list (list) and auth_group_create (create auth group). The verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, permissions, or conditions required for creating a resource group.
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 cover behavioral traits. It only states the tool retrieves history, with no details on read-only nature, auth requirements, rate limits, or response characteristics. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a parameter list, but the list repeats schema information without adding value. It is not overly verbose, but could be restructured to be more efficient by integrating parameter details into the main sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description should provide more context about the return format, pagination behavior, and search semantics. The current offering is inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should add meaning to parameters. However, it merely lists parameter names (e.g., 'start_date: 开始日期') without any semantic details like format, behavior, or constraints. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '获取 SQL 查询历史记录' (get SQL query history), clearly indicating the verb (get) and resource (SQL query history). This distinguishes it from sibling tools like sqlquery_execute or sqlquery_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or specific use cases. The description lacks any usage recommendations.
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 provided, so the description carries full burden. It implies a read operation ('获取') but does not explicitly state it is read-only, nor does it describe permissions, error behavior, or output structure. The lack of output schema makes this more critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one line for purpose followed by a parameter list. It is front-loaded and to the point, though a more structured format (e.g., bullet points) would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the need for return format details, the description is incomplete. It does not describe what the tool returns, how to interpret results, or error conditions. For a resource retrieval tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear explanations for all five parameters, including their roles (e.g., '数据库名' for db_name). Since the input schema only has titles, this adds meaningful semantic value and compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves resource information within an instance, listing the hierarchy (database/schema/table/column). However, it does not differentiate from sibling tools like sqlquery_resources or instance_table_lookup, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context about when it is appropriate. Sibling tools include similar resource queries, making this gap impactful.
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?
The description states it is a SELECT-only query and subject to permission control, which implies it is read-only and access-restricted. However, with no annotations provided, it does not disclose other behavioral traits like error handling, whether data is returned, or potential side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose followed by a parameter list. It is front-loaded with the essential verb and constraint. Every sentence is necessary, though the parameter section could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool executes SQL queries (a potentially powerful action) and has no output schema, the description fails to explain return values, error behavior, or how results are presented. It is incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds basic meaning by listing parameters with Chinese labels (e.g., '实例名称', '数据库名'). This helps map parameter names to their purpose but lacks detailed constraints, formats, or examples, providing only minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes SQL queries and explicitly restricts to SELECT only, which clarifies its scope. However, it does not explicitly differentiate from sibling tools like sql_check or sqlquery_describe_table, so it lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only mentions permissions and SELECT-only constraint but does not reference sibling tools or scenarios for using sql_check instead.
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 only states the basic function without disclosing read-only behavior, permissions, or pagination limits. Assumes non-destructive listing but provides no warning or details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose followed by parameter descriptions. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical details such as return format, total count, error handling, and authorization requirements. Given no output schema and no annotations, the description is incomplete for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful explanations for all three parameters (username for filtering, page and page_size for pagination) beyond the schema's type/default information. Compensates for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取用户列表' which translates to 'get user list', indicating the verb and resource. It distinguishes from sibling tools like user_create or user_delete by action and resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., user_create for new users, or other list tools). No prerequisites or context provided.
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?
The description does not disclose behavioral traits such as read-only nature, permission requirements, pagination, or error handling. Since no annotations are provided, the description carries the full burden, but it fails to inform the agent about important aspects like whether the tool requires specific roles or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence and an args list. It is well-structured and front-loaded with the key action. However, it could benefit from clearer separation of purpose and usage notes, and the use of Chinese may limit accessibility for multilingual agents, though that is not a direct fault.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should compensate with richer behavioral details. It does not mention return format, potential errors, or pagination. While the tool is simple, the description leaves gaps that could lead to incorrect usage, such as assuming the user exists or that the list is exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'engineer' of type string with no description. The tool description adds 'engineer: 用户名' (username), providing minimal context about the parameter's meaning. This adds some value over the bare schema, but it does not specify format, constraints, or validation rules, so it is only moderately helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the list of work orders pending review for a specified user. It uses a specific verb ('获取') and resource ('待审核的工单列表'), and it effectively distinguishes itself from sibling tools like 'workflow_list' (which likely lists all workflows) and 'workflow_audit' (which performs audit actions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention prerequisites, context, or exclusions. For example, it does not indicate that 'workflow_list' should be used for non-pending workflows or that 'workflow_audit' is for taking action on pending items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits beyond 'submit'. It doesn't mention side effects (e.g., triggers approval, modifies state), required permissions, or whether the operation is reversible. The agent cannot infer safety or side effects from this minimal text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact bullet-like list following a clear header. It wastes no words and is easy to scan. However, it could be slightly more concise by avoiding repetition of parameter names in both the schema and the list. Overall, it's well-structured for a parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns, what happens after submission (e.g., workflow created, pending audit), and any required conditions. It lacks all of this, making it incomplete for an agent to understand the full impact of the submission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides brief Chinese comments for each parameter (e.g., '目标实例 ID' for instance_id). This adds some meaning beyond the schema's type and title, but the comments are terse and essentially repeat the property names. The agent gets basic clarification but not deep semantics like expected formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '提交 SQL 上线工单' (submit SQL deployment ticket). It uses a specific verb and resource, and the tool name 'workflow_submit' aligns. Among siblings like workflow_audit and workflow_execute, this tool's role is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists parameters but provides no guidance on when to use this tool vs alternatives (e.g., workflow_execute, workflow_audit). There is no mention of prerequisites, workflows, or context that would help an agent make appropriate choices.
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 provided. The description only mentions creation but does not disclose any behavioral traits like permissions, idempotency, side effects, or potential impacts. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single-line action followed by a clean Args list. Every sentence serves a purpose with no redundancy. It is well-structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description lacks context on return values, effects, or how this operation fits into the broader workflow. It does not explain what constitutes a 'database instance configuration' or any post-creation steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds Chinese comments for each parameter (e.g., '实例名称' for instance_name, 'master/slave' for type). This provides basic semantics beyond the schema titles. However, it does not explain formats, constraints, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '创建新的数据库实例配置' (create new database instance configuration) with a specific verb and resource. It distinguishes from sibling tools like instance_update and instance_delete by focusing on creation. The parameter list further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as instance_update or instance_delete. Missing prerequisites, context, or when-not-to-use scenarios. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It mentions filtering and pagination parameters but does not describe side effects, authentication requirements, response format, ordering, or any constraints. This leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, front-loading the main purpose followed by a clean bullet list of parameters. Every line adds value without redundancy. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description covers parameters adequately but omits output details (e.g., fields returned, pagination structure, default ordering). It is minimally sufficient but could be more informative for an agent to fully understand the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaningful explanations for all 5 parameters: instance_name (filter by name), db_type (filter by type like mysql/redis/pgsql), type (master/slave), page, and page_size. This compensates well for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取数据库实例列表' (get database instance list) with a verb and resource. It lists filter parameters, making the tool's purpose specific. While it doesn't explicitly distinguish from sibling list tools like resource_group_list, the database focus is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, exclusions, or context where this tool is preferred over other list tools. Users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits such as permissions required, destructive potential, or side effects (e.g., does updating host/port disrupt connections?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating purpose followed by a clean Args list. No redundant information, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter semantics but omits return values, error handling, and update behavior (e.g., is it a partial update? what happens if a field is omitted?). Given the lack of output schema and annotations, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description lists all 6 parameters with brief Chinese labels (e.g., '新地址' for host), adding meaning beyond the schema's generic titles. However, it lacks details like validation rules or format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '更新实例配置' (update instance configuration), indicating the action and resource. The name 'instance_update' differentiates it from siblings like 'instance_create' and 'instance_delete', but the description could be more specific about what configuration elements are updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., instance_create, instance_delete). There are no prerequisites, conditions, or examples of appropriate use cases.
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 full behavioral burden. It only states the basic action and lists parameters, but fails to disclose side effects (e.g., duplicate checks, notifications) or behavioral traits beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for the main action and a list of parameters. No wasted words, but could be expanded to include usage notes. The structure is clean and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 3 required) and lack of annotations or output schema, the description is insufficient. It omits important context such as uniqueness constraints, password policies, or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameters with Chinese labels (e.g., '用户名' for username), but these are direct translations of the schema titles. No additional meaning, constraints, or examples are provided beyond the schema itself. Schema description coverage is 0%, but the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '创建新用户' (create a new user), which clearly identifies the action and resource. It distinguishes the tool from sibling tools like user_update, user_delete, and user_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and sibling names, but no exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not reveal any behavioral traits such as read-only nature, side effects, authentication requirements, or rate limits. The term '获取' (get) implies a read operation, but this is not explicit, and there is no mention of the result format or any potential limitations. The description carries the full burden but fails to provide sufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of a single line stating the purpose followed by a clear parameter list. It avoids unnecessary elaboration and presents information in a front-loaded manner. Every sentence adds value, making it highly efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the purpose and parameter meanings adequately. However, it lacks any information about the return format, pagination, or examples of usage. Given the absence of an output schema, some indication of what the logs contain or how they are structured would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to both parameters: it explains that workflow_id is the workflow ID and workflow_type is an integer with specific mappings (1=query permission, 2=SQL online, 3=data archiving). This compensates for the 0% schema coverage, as the schema only defines types. The mapping of workflow_type values provides critical guidance that the schema alone does not offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取工单操作日志' (get workflow operation logs). It identifies the main action (retrieve logs) and resource (workflow operation logs), and the specific parameters help narrow down the scope. However, it does not explicitly differentiate from sibling workflow tools, though the presence of 'log' in the name and the unique parameter set somewhat mitigate this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or hints about preferred contexts are provided. The description merely states the function without helping the agent decide when to invoke it over other workflow tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the list is user-scoped ('当前用户可访问的'), implying authorization-based filtering, but does not disclose read-only nature, rate limits, or whether the tool triggers any side effects. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose, followed by two lines for parameter semantics. Every sentence adds value, and the key information is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema, no annotations), the description is adequately complete. It specifies the user-scoped nature and filtering options. However, it could clarify what constitutes a 'query instance' to avoid ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description compensates by explaining both parameters: db_type filters by database type (comma-separated values like mysql,redis) and type filters by instance type. While it doesn't list all valid values, it provides meaningful guidance beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists query instances accessible by the current user. It uses a specific verb ('获取列表' - get list) and resource ('查询实例' - query instances), and distinguishes from siblings like sqlquery_resources or sqlquery_execute by focusing on instance enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sqlquery_resources or instance_list. The description does not specify prerequisites or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies mutation but does not mention side effects, required permissions, idempotency, or error behavior. For an update operation, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose followed by a parameter list. It front-loads the action and uses bullet points. No unnecessary sentences, though some behavioral info is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description lists only parameters, failing to explain return values (e.g., success flag or updated user object), error conditions, or prerequisites. Incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds Chinese explanations for each parameter (e.g., '邮箱' for email, '是否启用' for is_active), which provides meaning beyond the English schema titles. Since schema description coverage is 0%, this addition is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'user_update' and description '更新用户信息' clearly describe updating user information. This distinguishes it from sibling tools like user_create, user_delete, and user_list, which have different CRUD 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only states the action and lists parameters. There is no guidance on when to use this tool versus alternatives (e.g., when to use user_create instead) or any prerequisites (e.g., user must exist). No context about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions pass or terminate but does not disclose side effects, required permissions, or what happens after the audit (e.g., workflow progression). The behavioral impact is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a one-line summary followed by a parameter list, all in Chinese. It is front-loaded and concise, with no wasted words. The structure is straightforward, though the parameter list could be formatted more neatly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description provides basic parameter explanations but lacks usage context, error conditions, return values, or post-audit behavior. It is incomplete for understanding the full tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining workflow_type (1,2,3) and audit_type (pass, cancel). However, engineer, workflow_id, and audit_remark lack additional context beyond their names. Two of five parameters get clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reviews work orders (pass or terminate), which is a specific verb and resource. It distinguishes from siblings like workflow_submit and workflow_execute by focusing on the audit 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like workflow_list, workflow_pending_list, or workflow_submit. The context is implied from the tool name and siblings, but no guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, authorization requirements, or rate limits. It only explains the basic toggle 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with a clear sentence, and uses a structured format for parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool, the description covers the essential purpose and parameters. Missing output/return details, but acceptable given simplicity. No output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section explains each parameter's meaning (query_log_id, star with true/false interpretation, alias), which adds significant value beyond the schema's type-only definitions. However, schema description coverage is 0%, so the description carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (favorite or unfavorite) and the resource (query record), distinguishing it from siblings like sqlquery_execute or sqlquery_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., sqlquery_logs for listing). The description only explains what it does, not when it's appropriate.
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 provided, so description carries full burden. It fails to disclose pagination behavior, default sorting, or any side effects. Only lists parameters without explaining the underlying 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose. Parameter list is clean and well-organized. No redundant or missing sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return values. Given 5 parameters and no annotations, missing behavioral context like pagination behavior, default ordering, or what fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning by explaining each parameter in Chinese (e.g., status values, filter purposes). Compensates well for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with clear verb '获取' and resource 'SQL上线工单列表', distinguishing it from sibling tools like workflow_submit or workflow_audit which perform actions rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for listing workflows with filters, but does not explicitly state when to use this tool over alternatives such as workflow_pending_list or other companion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It only describes parameters without disclosing side effects, how the execution happens, or required permissions. This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single-line purpose followed by a parameter list. It is front-loaded and efficient, though the parameter list format is somewhat terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers input parameters but lacks any mention of output, errors, or behavior beyond execution. Given the lack of an output schema, this leaves gaps for understanding the tool's full effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains each parameter: workflow_id, workflow_type (with enum values), engineer (with condition), and mode (with values). This adds essential meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '执行已审核通过的工单' (execute audited work orders). It specifies a concrete verb and resource, and from the sibling list, it is distinct from submission, audit, and list operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing audited workflows but does not provide explicit guidance on when to use vs. alternatives, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool lists resources but does not mention pagination, error behavior, or permissions required. The description is truthful but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and uses a docstring-like structure with clear sections (purpose, parameter list). It front-loads the main purpose. Minor redundancy (repeating parameter names) is acceptable but prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's complexity (listing hierarchical resources), the description lacks details on output format (e.g., list of names vs objects) and pagination. It is functional but not fully complete for an AI agent to anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds value by explaining parameter dependencies (db_name required for table/column, tb_name for column). However, it does not specify valid values for resource_type (e.g., enum) or provide format hints, limiting completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists resources (databases/tables/columns) within an instance, using the specific verb '获取' (get). It distinguishes from sibling tools like sqlquery_instances (list instances) and sqlquery_describe_table (describe table schema), making its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes parameter dependencies (e.g., db_name required for table/column, tb_name required for column), providing implicit usage conditions. However, it does not explicitly mention when to prefer this tool over siblings like instance_table_lookup or sqlquery_execute, preventing it from scoring 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?
No annotations are provided, so the description must cover behavioral traits. It states the tool does not execute SQL, which is critical, but lacks details on permissions, side effects, or rate limits. For a simple check tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences for the overall purpose and a simple list of parameters. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks information about the return format or potential errors. With no output schema, more detail on the review results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description lists each parameter with a brief Chinese explanation (e.g., 'instance_id: 目标实例 ID'), adding meaningful context beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs SQL syntax review without execution, using goInception, which distinguishes it from sibling tools like sqlquery_execute that execute queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes '不执行' (not executed), guiding the agent to use this for checking rather than executing. However, it does not explicitly mention when not to use it or provide alternative tools.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/ckall/archery-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server