andon-sop-mcp

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 targets a distinct operation: project CRUD, task CRUD, and supporting queries (customers, users, duty list). No two tools have overlapping purposes; descriptions clearly differentiate them.
Naming Consistency4/5
Tools follow a verb+noun pattern with camelCase (e.g., queryProjProjectList, saveProjTask). Minor inconsistency: 'queryDutyList' lacks the 'Proj' prefix present in others, but overall pattern is predictable.
Tool Count4/5
11 tools cover the core operations of a project and task management system: 4 for projects (create, read list, update, delete), 4 for tasks (create, read tree, update, delete), and 3 supporting queries. This is well-scoped, though slightly on the higher side.
Completeness4/5
CRUD operations are covered for both projects and tasks, along with necessary supporting queries (customers, users, duty list). However, there is no explicit tool to update project status or get a single entity by ID, leaving minor gaps.
Average 4.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: reads form configuration, builds query, uses data dictionary translations, returns context with IDs. It does not explicitly state read-only nature or potential side effects, but 'query' implies safe. Missing details on rate limits or permissions, but covers core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences in Chinese, efficiently stating the purpose, process, and return context. No redundant phrases, front-loaded key action 'dynamically paginate query user list'. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (dynamic filtering, configuration-based, data dictionary translation) and no output schema, the description adequately explains the process and return context (includes id). Lacks details on error handling or permission requirements, but sufficient for an agent to understand usage.
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 description coverage is 100%, so baseline is 3. Description adds context on overall flow (reading config, building query) but does not add new per-parameter meaning beyond what the schema already provides for each parameter. The filters parameter is elaborated in the schema description, matching description text.
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 user list with dynamic pagination and configuration-based filtering. It specifies the verb 'query', resource 'user list', and distinct behavior like using MES form configuration. This differentiates it from sibling tools that operate on projects or tasks.
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?
Description implies use for user queries but does not explicitly state when to choose this tool over alternatives like queryProjCustomer or queryProjProjectList. It lacks 'when to use' and 'when not to use' guidance. However, the context of sibling tools and the specific 'user list' resource provides implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses key behaviors: reading form config, building dynamic query parameters, querying an endpoint, translating values with data dictionary, and including IDs in return. This provides solid insight into internal workings, though it does not mention permissions 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 concise (3 sentences) and well-structured: first sentence states core function, second explains the process, third describes return value. Every sentence adds unique value with no wasted words.
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 partially explains return: it mentions IDs in context for follow-up operations. However, it does not describe full response structure (e.g., pagination metadata, total count). For a paginated query, this omission reduces completeness.
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%, so baseline is 3. The description adds general context (dynamic queries, dictionary translation) but does not enhance individual parameter semantics beyond the schema's own descriptions. The filters parameter gets some extra context about dynamic conditions, but not enough to raise the score.
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: dynamically paginated query of project customer list according to MES form configuration. It specifies the action (query), resource (project customer list), and method (dynamic pagination). This distinguishes it from sibling tools like queryProjProjectList which query a different resource.
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 querying project customers and mentions that returned IDs enable subsequent operations, but it does not explicitly state when to use this vs. alternatives, nor does it provide when-not-to-use guidance. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and reveals internal steps: reading form config, building params, querying endpoint, translating values. It does not explicitly state the tool is read-only but implies it via 'query', though more explicit would be better.
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 sentences: first states purpose, second explains process. Both are relevant and concise, with no wasted words.
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 query process and translation but does not describe the return format (e.g., pagination structure). Given no output schema, this information would be helpful for an agent to parse results correctly.
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 parameter descriptions. The description adds context about dynamic query building and how filters use ProjProject form fields (fuzzy for text, range for time), enriching the schema's basic 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 that the tool queries a project management list with dynamic pagination based on MES form configuration. It specifies the endpoint and data dictionary translation, distinguishing it from sibling tools like queryProjectTask.
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 does not provide explicit guidance on when to use this tool versus alternatives like queryProjectTask. It only describes what the tool does, 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.
Behavior3/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 underlying API call and parameter dependencies, but lacks details on error behavior, response format, or whether the operation is reversible. Moderate transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each essential and well-structured. Front-loaded with purpose and prerequisite. No redundant information, highly efficient.
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 13 parameters and no output schema, the description adequately covers update operation and special parameter rules. However, it lacks information on return value, error handling, and whether updates are partial or full. Could be more complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 13 parameters with descriptions. The tool description adds significant value beyond schema by explaining usage rules: only pass modified fields, id must come from queryProjectTask, duty fields must come together from queryDutyList. This enhances parameter 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 modifies project task information and refers to the specific API endpoint. It distinguishes itself from siblings like saveProjTask (create) and deleteProjTask by focusing on update, and mentions prerequisites that differentiate usage from query 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?
Explicitly states prerequisite of calling queryProjectTask first, and instructs to only pass modified fields. Provides specific constraints for dutyUserId/dutyUserName. Does not explicitly mention when not to use (e.g., for creation), but this is implicit given sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that progress and delayDays are fixed to 0, and mentions the underlying API call. However, it does not discuss side effects, authorization requirements, or error conditions, but the detailed prerequisites provide sufficient behavioral context for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the action and then lists prerequisites sequentially. It is concise for the amount of information provided, though slightly run-on. Every sentence adds value.
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 10 parameters, 5 required, and no output schema, the description covers prerequisite steps and fixed fields. However, it does not explain the return value or error handling, leaving some gaps for the agent regarding what happens after invocation.
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%, so each parameter has a description. The tool description adds overall context about the origin of certain parameters (e.g., from prior queries) but does not add meaning beyond what is already in the schema. Baseline 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 explicitly states the tool is for adding new project tasks or subtasks, using the verb '新增' (add) and resource '项目任务或子任务' (project task or subtask). It distinguishes itself from sibling tools like updateProjTask and deleteProjTask by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites: must call queryProjProjectList first for projectId, queryDutyList for dutyUserId and dutyUserName, and queryProjectTask for parentId when adding subtasks. It also states that progress and delayDays are fixed to 0, giving clear when-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 carries full burden. It discloses that the tool validates each project's status before deletion, which adds transparency. However, it does not explicitly state that deletion is irreversible or what happens to related data. Still, the description provides key behavioral context beyond just the action.
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?
Four sentences, all essential. No filler. Front-loaded with the core action and endpoint. Every sentence adds value: batch delete, prerequisite, status condition, and validation behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the prerequisite, validation, and batch nature adequately. It lacks details on return value or error handling, but for a delete tool with clear constraints, it is sufficiently complete for an agent to use correctly.
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 per-parameter descriptions already covering origin from queryProjProjectList and status constraint. The description reinforces these points but does not add substantially new information beyond the schema. Baseline 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 the verb '删除' (delete) and the resource '项目' (projects), specifying it is for batch deletion. It distinguishes from sibling tools like queryProjProjectList (query) and save/update tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite: must call queryProjProjectList first and let user select projects. Also provides a clear condition: only projects with projectStatus 0 (未开始) can be deleted, and other statuses are not allowed. This gives strong guidance on when and when not to use the tool.
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 call, assembly into tree structure, and data dictionary translation. Without annotations, this provides good insight, though read-only nature is implied rather than explicit.
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 sentences, each adding value: purpose and usage guideline. No unnecessary words.
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?
Explains internal steps and transformation, sufficient for a simple query tool. Lacks explicit output format description but mentions 'tree structure'.
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 description already covers projectId with prerequisite info. Description adds no new semantic information beyond reinforcing the same guidance.
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 the verb (query) and resource (task tree of a project). It distinguishes from sibling tools like queryProjProjectList (list projects) and CRUD tools.
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 queryProjProjectList first and let user select project ID. Provides clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the underlying endpoint call, the mutation nature, dependencies on prior queries, and field consistency requirements. It lacks details on error handling or partial success, but for an update tool, the behavioral context added beyond the schema is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with dense, essential information. It is front-loaded with the action, then prerequisites, then detailed rules. Every sentence contributes value, though a bullet-point structure could improve readability. No excess wording is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema), the description covers the main usage flow: prerequisites, valid id sources, and field constraints. It does not specify the return value or error handling, but for an update tool, the usage context is well-addressed. The schema descriptions further support 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 coverage is 100%, and the description adds higher-level rules: relationships between parameters (e.g., customerName, customerCode, customerId must be from the same record; pmName and userId together). It also reiterates that id must come from a prior query. This adds meaning beyond the individual parameter 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 '修改项目信息' (modify project information), specifying the verb and resource. It distinguishes the tool from siblings like updateProjTask, deleteProjProject, and saveProjProject by outlining specific prerequisites and constraints, ensuring the agent understands the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call queryProjProjectList first, mandates that the id must come from that query, and advises to only pass fields that need modification. It provides specific rules for modifying customer or project manager fields, including which other tools to query (queryProjCustomer, queryProjUser) and how to pass related parameters together. This gives 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 exist, so the description carries full burden. It discloses the batch deletion behavior and the ID concatenation. However, it does not explicitly mention the destructive nature (e.g., irreversible deletion) or potential side effects, though it is implied.
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 in Chinese, concise and front-loaded with the core purpose. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention expected return values or error handling. However, it adequately covers the tool's input constraints and prerequisite workflow. The overall context is sufficient 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%, yet the description adds value by explaining how the tool processes the tasks array (concatenating IDs) and that parentId and taskName are optional for display. This goes beyond the schema's minimal 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 the tool is for batch deleting project tasks and provides the API endpoint. It distinguishes from sibling tools like saveProjTask and updateProjTask, which are for save/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call queryProjectTask first and let the user select tasks. It also clarifies that task IDs must come from that query and that the tool concatenates multiple IDs into a comma-separated string.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully shoulders the burden. It reveals internal behavior: reads AndonSysUser config, queries /user/queryPageMap, always includes accountType=0, and describes the mapping of returned fields for saveProjTask. This transparently informs the agent of side-effects and prerequisites.
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, starting with the core purpose in the first sentence, followed by necessary behavioral details. No redundant sentences; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is fairly complete: it explains input, internal processing, and output usage. However, it does not explicitly mention pagination details (though schema has page/limit). Slight gap but sufficient for the primary use case.
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 already has 100% parameter descriptions, so baseline is 3. The description adds value by explaining the filters parameter semantics (keys must be AndonSysUser fields) and the fixed accountType=0 behavior, which is not in the schema. This enhances schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it queries the project task responsible person list, with a clear purpose: to select the responsible person before calling saveProjTask. This distinguishes it from sibling tools like queryProjUser or queryProjProjectList, which serve different querying needs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use this tool (before saveProjTask) and explains how to use the returned data (dutyUserId and dutyUserName). However, it does not explicitly mention when not to use it or compare with alternatives like queryProjUser, which could also query users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses direct API invocation and fixed fields, adding context beyond creation. However, it omits details like error handling, permissions, or idempotency, but for a creation tool the disclosed preconditions and fixed values are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then succinctly lists prerequisites and fixed fields. Every sentence adds necessary information without redundancy, making it efficient yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, 3 required, and no output schema, the description covers prerequisites, fixed fields, and parameter sources. It lacks return value details, but given no output schema, this is acceptable. Overall, it provides most needed 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%, so baseline is 3. The description adds value by explaining the dependency on queryProjCustomer and queryProjUser results for customer and user parameters, and revealing fixed values for id and projectStatus (not in schema). This context beyond schema justifies a 4.
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: '新增项目' (add new project) and specifies the direct API call /projProject/saveEntityMap. It distinguishes from sibling tools like queryProjProjectList (list), updateProjProject (update), and deleteProjProject (delete) by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists prerequisites: must call queryProjCustomer first and have user select customer for customerName, customerCode, customerId; and if filling manager, must call queryProjUser for userId and pmName. It also notes fixed parameters (projectStatus=0, id=''). This provides clear when-to-use and how-to-use 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:

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

Score Badge

Copy to your README.md:

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

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