Andon SOP MCP Server

by guansuian

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting different entities or actions. Query tools are differentiated by entity type (production task, SOP, workstation, etc.) and action tools are uniquely named (audit, dispatch, upload). There is no ambiguity or overlap.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern in camelCase (e.g., queryProductionTaskList, auditProductionTask). Some names like 'likeSelectMaterielList' and 'dispatchToStation' deviate slightly but remain understandable. Overall predictable.
Tool Count5/5
With 12 tools covering production task management, SOP file operations, workstation dispatch, material queries, and category management, the count is well-scoped for the server's purpose. Each tool earns its place without redundancy.
Completeness3/5
Core workflows are covered: querying, creating (category, SOP), approving tasks, and dispatching. However, missing update and delete operations for several entities (e.g., no update for production tasks or categories) leave notable gaps that may require agents to work around.
Average 4/5 across 12 of 12 tools scored. Lowest: 3.1/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the upload action but does not mention whether it overwrites existing files, success/failure behavior, required permissions, or any side effects. This is insufficient for a file upload 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?
Two concise sentences without unnecessary words. The first sentence states the purpose, the second adds a usage condition. However, it is very brief and could include more useful information without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters, no output schema, and no annotations, the description is too minimal. It does not explain return values, error conditions, or file processing details. For an upload tool, this leaves the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a description. The tool description adds no additional meaning beyond the schema, such as format constraints or dependencies between parameters. Baseline of 3 is appropriate.
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 '上传 SOP 文件到 MES 系统' (upload SOP file to MES system), using a specific verb and resource. It effectively distinguishes from sibling tools like previewSopFile or querySopList which are read-only or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is '只有在所有参数齐全后才能调用' (only call when all parameters are complete), which is a trivial condition. No context is provided on when to use this tool versus alternatives, nor any prerequisites like needing IDs from likeSelectMaterielList or selectCategoryTreeList (though schema mentions sources).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tree is flattened but does not disclose any additional behavioral traits such as access permissions, rate limits, or how the tree is constructed. For a query tool, more detail on the nature of the returned data would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the main purpose and then provide a brief usage note. Every sentence adds value without waste.
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 simplicity (no parameters, no output schema), the description covers the basic purpose and output usage. However, it does not specify the exact shape of the output (e.g., fields like id, level, name) which would be useful for the agent to integrate the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to clarify. With 100% schema coverage (trivially), the description adds no further meaning, but this is acceptable.
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 query) and resource ('SOP 分类树' meaning SOP category tree) and specifies that the output is flattened. It is specific enough to distinguish from siblings like saveCategory or querySopList, though no explicit differentiation is given.
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 guidance: when displaying to users, only show level and category name, and that Work Buddy can use the id from results as esopCategoryId. However, it does not discuss when to use this tool versus alternatives or any 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?
With no annotations provided, the description carries full burden. It only states the action and prerequisites but fails to disclose side effects, success/error behavior, or whether it is destructive. The mismatch between description (comma-separated ids) and schema (array) adds opacity.
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. The first sentence states purpose, the second provides usage guidance. No redundant information, though the mention of 'ids' could be aligned with the schema to avoid confusion.
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?
While the description covers purpose, prerequisites, and batch support, it lacks information about return values (no output schema) and has a discrepancy between described concatenation and actual array input. This leaves some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions on all parameters. The description adds value by emphasizing data source consistency (ids from querySopList, stationId/stationName from same workstation record) and batch dispatching behavior. This goes beyond the schema's own descriptions.
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 'Dispatch one or more SOPs to workstation' with a specific verb and resource. It distinguishes from sibling tools like querySopList and uploadSop by focusing on dispatching. However, the mention of 'ids concatenated with commas' contradicts the actual schema which expects an array of objects, causing minor confusion.
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 explicitly states prerequisites: must call querySopList and queryWorkstationList first, and ensures stationId and stationName come from the same record. It also mentions batch support. It doesn't explicitly state when not to use, but the context is clear given prerequisites.
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?
Discloses internal API calls, fixed parameters (className, fileType), and that returned context includes record IDs. No annotations provided, so description carries burden; it offers good insight beyond basic functionality, though omits error handling and auth requirements.
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?
Concise and well-structured: front-loads main purpose, then explains internal steps. Could be slightly shorter, but remains efficient.
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?
Covers key aspects: pagination, internal process, fixed parameters, and returned context (ids). Lacks output schema, but description compensates with details. Sufficient for typical use.
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?
Adds meaning beyond schema: explains filters parameter semantics (field names, fuzzy/range matching), and that fileType is fixed. With 100% schema coverage, baseline is 3, but description enhances understanding.
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: paginated query of SOP abnormal drawing list. It details the internal process (two API calls) and fixed parameters, distinguishing it from sibling tools like auditProductionTask and querySopList.
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 explicit guidance on when to use this tool versus alternatives. While it describes what it does, it lacks conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the internal API calls, data dictionary translation, and that returned context includes record IDs. However, it does not mention rate limits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with three sentences. Each sentence provides value: purpose, internal workflow, and output context. It is front-loaded but slightly long.
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 no output schema, the description does not specify the full return format or pagination metadata. It mentions record IDs but lacks details on total count, page indicators, or example output. Adequate for a paginated query but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds context that filters use ESOPAttachment form fields, with text fuzzy search and time range syntax, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries SOP list with pagination, detailing internal calls and data processing. It is distinct from sibling tools like auditProductionTask or dispatchToStation, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and mentions returned context for further operations, but does not provide explicit guidance on when to use it versus alternatives or any prerequisites.
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?
Describes reading form config, querying an endpoint, and using data dictionary. No annotations exist, so description carries full burden. It implies read-only but doesn't explicitly state safety, auth requirements, or rate limits. Adequate but missing some 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with main action and process details. Every sentence adds value without redundancy. 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?
Lacks output schema and annotations. Description explains internal logic but does not detail the return format (e.g., fields in material records). For a query tool, the agent may need to know what properties are available. Gaps in safety and output details reduce 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?
Schema covers 100% of parameters. Description adds value by explaining the process (reading form config) which gives context to contain/exclude parameters, and the filters parameter is well-described. The description enhances understanding beyond 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?
Description clearly states it queries material lists with dynamic pagination according to MES form configuration. It specifies the endpoint, data dictionary translation, and a specific use case (before uploadSop). This distinguishes it from siblings which query SOPs, tasks, workstations, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use before uploadSop to retrieve materielId. While it doesn't explicitly list when not to use, the context implies it's for material queries, and siblings handle other entities. Clear usage context is provided.
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?
Given no annotations, the description discloses the internal flow (two API calls, data dictionary translation) and notes that the returned context includes record IDs. It does not explicitly state read-only behavior, but as a query tool it is implicitly safe. The description adds value beyond the annotations gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main purpose, and every sentence adds necessary detail. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the internal flow and mentions that returned records include IDs, but lacks details on pagination metadata (e.g., total pages) or complete response structure. Since no output schema exists, more detail on the return format would be beneficial.
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 100%, baseline 3. The description adds value by explaining the filters parameter format (fuzzy text, range for time fields) and the purpose of contain/exclude for field initialization, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '分页查询生产任务列表' (paged query for production task list), specific verb+resource. It distinguishes from sibling tools like auditProductionTask (audit) and dispatchToStation (dispatch) by being a query-only tool, which is evident from the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing production tasks with pagination, but does not explicitly state when to use this tool compared to siblings like querySopList or queryWorkstationList. No exclusions or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses reading a form config, using a specific endpoint, and always adding accountType=1. It is read-only but does not mention auth needs, rate limits, or side effects.
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 two sentences, front-loaded with the main action, and every sentence adds value. No redundant or vague information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions that the returned context includes id for each workstation, which is useful for selection. However, no output schema is provided, and the description lacks details on pagination metadata or other fields returned. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that filters key must be AndonSysUser form fields, and that text fields use fuzzy match while time fields use range. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询工位机列表' (query workstation list) and provides specific details about the underlying endpoint, fixed parameter, and returned context. It distinguishes from siblings like auditProductionTask or dispatchToStation, which are clearly different tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing workstations and mentions returning context for selection, but does not explicitly state when not to use or name alternatives. However, sibling tools are all distinct, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description covers validation behavior (checking checkStatus before release) and preconditions. However, it does not disclose error handling (e.g., partial failures, atomicity) or side effects beyond validation.
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?
Concise and well-structured: purpose first, then prerequisites, then constraints. Each sentence adds value without repetition.
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?
Lacks details about the return value or output, especially since there is no output schema. The description covers preconditions and validation but does not explain what the tool returns (e.g., success/failure details).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed field descriptions. The description reinforces that tasks must come from queryProductionTaskList and checkStatus must be 0, but these are already implicit in the schema. No new semantic constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '批量下达生产任务' (batch release production tasks) and specifies the API endpoint. It also distinguishes itself from siblings like reverseAuditProductionTask, which likely reverts releases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that queryProductionTaskList must be called first, tasks must be selected by the user, and only tasks with checkStatus=0 are allowed. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals the internal API call to /attachment/getMapById and explains URL construction. Although it doesn't mention safety (read-only) or auth, the description offers sufficient transparency for a preview 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 extremely concise with just two sentences. It front-loads the purpose and proceeds with usage instructions. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with 100% schema coverage and no output schema, the description provides complete context: it explains the prerequisite step, the internal call, and the result (a frontend-accessible URL). For a simple preview tool, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the id parameter. However, the description adds meaning beyond schema by tying the id to a specific source (queryAbnormalDrawingList results) and explaining its role, which helps the agent use the parameter correctly.
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: to preview abnormal marked points in SOP files. It uses a specific verb ('preview') and resource ('SOP file abnormal marking points'), and distinguishes it from sibling tools by explicitly mentioning a prerequisite call to queryAbnormalDrawingList.
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 explicitly states when to use this tool: after calling queryAbnormalDrawingList and after user selects a record id. It provides clear context but does not mention when not to use it or list alternatives, which is acceptable given the straightforward workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses validation behavior (checks checkStatus before reversal), but does not detail side effects, reversibility, or success/failure responses.
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?
Concise, no fluff. Purpose and prerequisite are front-loaded. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites and validation adequately for a simple batch tool. No output schema, but missing error handling or return format details are acceptable given tool's scope.
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 has 100% description coverage. Description adds meaningful value by requiring data to come from queryProductionTaskList and explaining the checkStatus constraint, going beyond schema basics.
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: '批量反下达生产任务' (batch reverse-audit production tasks) and specifies the API endpoint. It distinguishes itself from sibling tools like 'auditProductionTask' by focusing on reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite: must call queryProductionTaskList first. Specifies that only tasks with checkStatus=1 are allowed, providing clear when-to-use guidance and preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the creation action, the dependency on selectCategoryTreeList, and the default ROOT parent. While it doesn't mention permissions or side effects, the tool is simple (non-destructive create) and the description is sufficient.
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?
Two concise sentences in Chinese, front-loaded with purpose. No redundant words; every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, no output schema, and no annotations, the description covers purpose, prerequisite call, parameter usage, and default behavior thoroughly. An agent can 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by specifying that parentId comes from selectCategoryTreeList and that omitting it defaults to ROOT. This complements the schema well.
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 '新增 SOP 分类' (create a new SOP category), with a specific verb (add/create) and resource (SOP category). This distinguishes it from sibling tools like selectCategoryTreeList (query categories) and uploadSop (upload files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to first call selectCategoryTreeList to let the user select a parent category and use its id as parentId. Also explains default behavior when parentId is omitted. This provides clear when-to-use and step-by-step guidance.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/guansuian/sop-mcp'

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