JoyCode MCP Server - FOP Workflow Assistant

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tools have some distinct purposes (e.g., execute_workflow_stage vs. get_file_naming_rules), but there is notable overlap between configuration-related tools like get_workflow_config, load_config, and show_config_summary, which could cause confusion about which to use for configuration tasks. The descriptions help differentiate them, but the boundaries are not entirely clear.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (e.g., execute_workflow_stage, get_file_naming_rules) with all using snake_case, making them predictable and readable. There are minor deviations in verb choice (e.g., 'load' vs. 'get' vs. 'show'), but the overall pattern is maintained.
Tool Count4/5
With 6 tools, the count is reasonable for a workflow assistant focused on FOP (File Organization and Processing), as it covers execution, configuration, and retrieval aspects. It is slightly lean but appropriate for the apparent scope, though it might benefit from additional tools for more comprehensive workflow management.
Completeness3/5
The toolset covers core areas like workflow execution, configuration loading, and rule retrieval, but there are notable gaps in lifecycle coverage. For example, there are no tools for updating or deleting configurations, managing workflow stages beyond execution, or handling errors, which could limit agent effectiveness in dynamic scenarios.
Average 3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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 carries the full burden. It mentions loading configuration files and preserving an existing mechanism, but it doesn't disclose critical behavioral traits such as whether this is a read-only operation, what permissions are required, if it modifies state, or what happens on failure. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short phrases, but it's not optimally structured. The first part states the purpose, while the second adds context about preserving a mechanism, but it could be more front-loaded with clearer intent. It's efficient but lacks polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of configuration loading and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'FOP' is, what the loaded configuration contains, how it's used, or what the tool returns. For a tool with no structured data to rely on, this leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't add parameter details, but with no parameters, this is acceptable. Baseline is 4 for 0 parameters, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool loads FOP configuration files, which is a clear purpose, but it's vague about what 'FOP' refers to and doesn't differentiate from sibling tools like 'get_workflow_config' or 'show_config_summary'. The phrase '保留原有配置加载机制' adds some context but doesn't clarify the specific scope or resource.
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 is provided on when to use this tool versus alternatives. The description mentions preserving an existing loading mechanism, which implies a specific context, but it doesn't state when this tool is appropriate compared to sibling tools like 'get_workflow_config' or 'show_config_summary'.
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 for behavioral disclosure. While '执行' (execute) implies an action that may have side effects, the description doesn't specify whether this is a read-only operation, what permissions are required, whether it's idempotent, what happens on failure, or what the expected output format might be. For a tool that appears to execute workflow stages, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point - a single sentence that states the tool's purpose and lists the three executable stages. There's no wasted verbiage, though it could be slightly more structured by separating the general purpose from the specific stage enumeration.
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?
For a tool that executes workflow stages with 2 parameters (one being a complex nested object), no annotations, and no output schema, the description is insufficient. It doesn't explain what '完整执行' (complete execution) means, what constitutes successful execution, what errors might occur, or what the agent should expect as a result. The description should provide more context about this presumably state-changing operation.
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?
The input schema has 100% description coverage, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain the relationship between stage types and their required input_data, or provide examples of valid input_data structures for different stages.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('执行' - execute) and resource ('工作流阶段' - workflow stage), and specifies the three specific stages that can be executed. However, it doesn't differentiate this tool from its siblings (which appear to be configuration-related tools), so it doesn't fully distinguish its purpose within the toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or context for execution. It simply restates what the tool does without indicating appropriate use cases or relationships to sibling tools like get_workflow_config or load_config.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('获取文件命名规则') without mentioning any behavioral traits such as whether it's read-only, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps in understanding how the tool behaves.
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—a single sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently communicates the core functionality, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the structure of naming rules), any error conditions, or behavioral constraints. For a tool with two parameters and no structured output documentation, more context is needed to fully understand its 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?
The schema description coverage is 100%, so the input schema already documents both parameters ('requirement_name' and 'file_type') with descriptions and an enum for 'file_type'. The description adds no additional meaning beyond the schema, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取文件命名规则' (get file naming rules) and specifies it follows FOP specifications. It includes both verb ('获取') and resource ('文件命名规则'), making the intent unambiguous. However, it doesn't differentiate from sibling tools like 'get_smart_retrieval_config' or 'get_workflow_config', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or scenarios where other sibling tools (e.g., 'get_workflow_config') might be more appropriate. Usage is implied through the purpose but lacks explicit 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 carries the full burden of behavioral disclosure. It states the tool '获取工作流配置' (gets workflow configuration), implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence: '获取工作流配置 - 支持stage1/2/3阶段' (Get workflow configuration - supports stage1/2/3 phases). It is front-loaded with the core purpose and efficiently adds the stage support detail. Every word earns its place without 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?
Given the tool's low complexity (1 parameter with full schema coverage, no output schema), the description is minimally adequate. It covers the purpose and stage scope but lacks behavioral details (e.g., return format, error handling) and usage guidelines. With no annotations and no output schema, it should provide more context for 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?
The schema description coverage is 100%, with the parameter 'stage' fully documented in the schema (including enum values). The description adds minimal value by mentioning 'stage1/2/3阶段' (stage1/2/3 phases), which is already covered in the schema's enum. No additional parameter semantics are provided beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取工作流配置' (get workflow configuration) with the specific resource '工作流配置' (workflow configuration). It distinguishes from siblings by mentioning support for 'stage1/2/3阶段' (stage1/2/3 phases), which aligns with the enum values in the schema. However, it doesn't explicitly differentiate from all sibling tools like 'load_config' or 'show_config_summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions support for specific stages, but doesn't indicate when to use it over sibling tools such as 'get_file_naming_rules' or 'get_smart_retrieval_config'. There are no explicit when/when-not instructions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '显示' (display/show) implies a read-only operation, the description doesn't explicitly state this or mention any other behavioral aspects like authentication requirements, rate limits, response format, or whether the data is cached. For a tool with zero annotation coverage, this is insufficient disclosure.
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 clear phrases that communicate the core purpose. The first phrase states what the tool does, and the second clarifies the scope ('完整显示所有配置信息' - completely display all configuration information). There's no wasted language, though it could be slightly more 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?
For a zero-parameter read operation with no output schema, the description provides adequate basic information about what the tool does. However, it doesn't explain what 'configuration' refers to in this context or what format the summary will be in. Given the sibling tools suggest this is part of a configuration management system, more context about what distinguishes this summary from other configuration tools would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist. The baseline for 0 parameters with high schema coverage is 4, as there's no need for parameter explanation in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '显示配置摘要' (display configuration summary) and '完整显示所有配置信息' (completely display all configuration information). It uses specific verbs ('显示' - display/show) and identifies the resource ('配置摘要' - configuration summary). However, it doesn't differentiate from sibling tools like 'get_workflow_config' or 'load_config', which appear to be related configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several sibling configuration tools (get_workflow_config, get_smart_retrieval_config, get_file_naming_rules, load_config), but the description doesn't explain how this 'show_config_summary' differs from those more specific tools or when it's the appropriate choice.
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 for behavioral disclosure. While '获取' implies a read-only operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or has any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 - a single sentence in Chinese that directly states what the tool does. Every word earns its place: it specifies the action, the resource, and adds valuable context about content. There's no wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose information but lacks important context. It doesn't explain what format the configuration returns, whether it's a complete or partial view, or how it relates to other config tools. For a retrieval tool with no structured output documentation, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, which is correct. Baseline would be 4 for zero-parameter tools when the schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取' meaning 'get') and resource ('智能检索配置' meaning 'smart retrieval configuration'), specifying it retrieves configuration information. It adds detail about content ('包含代码分析优化策略' meaning 'includes code analysis optimization strategies'), which helps distinguish it from generic config tools. However, it doesn't explicitly differentiate from sibling tools like get_workflow_config or show_config_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like get_workflow_config, load_config, and show_config_summary that also retrieve configuration data, there's no indication of what makes this tool specific for 'smart retrieval' scenarios or when other config tools would be more appropriate.
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:

[![easy-workflow MCP server](https://glama.ai/mcp/servers/shaun888/easy-workflow/badges/card.svg)](https://glama.ai/mcp/servers/shaun888/easy-workflow)

Score Badge

Copy to your README.md:

[![easy-workflow MCP server](https://glama.ai/mcp/servers/shaun888/easy-workflow/badges/score.svg)](https://glama.ai/mcp/servers/shaun888/easy-workflow)

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/shaun888/easy-workflow'

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