MCP Project Standards Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CONFIG_DIR | No | Configuration directory. Resolved relative to PROJECT_PATH. | ./.setting or ./.setting.<TOOL_PREFIX> |
| TOOL_PREFIX | No | Optional tool prefix for tool names and config isolation | |
| PROJECT_NAME | No | Optional project branding for tool descriptions | |
| PROJECT_PATH | No | Root path of the project. Supports both absolute and relative paths. Used to resolve all relative paths. | . |
| API_DEBUG_LOGIN_URL | No | Set login API URL | /api/login |
| API_DEBUG_LOGIN_BODY | No | Set login request body | {"username":"","password":""} |
| API_DEBUG_LOGIN_METHOD | No | Set login request method | POST |
| API_DEBUG_ALLOWED_METHODS | No | Control allowed request methods (supports: GET,POST,PUT,DELETE,PATCH, etc.) | GET |
| API_DEBUG_LOGIN_DESCRIPTION | No | Set login API description | Save returned token to common headers in debug tool, field name Authorization, field value Bearer token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| project_infoC | Get or set project information in configuration file |
| project_structureB | Get, set or delete project structure in configuration |
| api_standardsA | Get, set or delete API interface standards and best practices |
| development_standardsC | Get, set or delete development standards |
| database_standardsC | Get, set or delete database standards |
| api_loginA | API login authentication tool that uses environment variables for login credentials. Automatically extracts token from response and updates Authorization headers. Example: Call with optional baseUrl parameter to override default base URL |
| api_debugB | API debugging tool for directly executing API requests with automatic content-type detection and flexible body format support. Examples: GET /api/users with query params, POST /api/login with JSON body {"username":"admin","password":"123456"}, PUT /api/users/123 with form data "name=John&email=john@example.com" |
| api_helpA | API help tool that provides detailed documentation and examples for all API debugging tools. Use this to understand how to use api_debug, api_login, and api_config tools effectively |
| api_executeC | Execute API requests by index from configured API list. Examples: execute API at index 0, execute with overrides {"method":"POST","body":{"key":"value"}} |
| download_fileB | Download a file from a URL and save it to a specified path. Supported schemes: http, https. |
| api_configB | API configuration management tool for managing API settings, endpoints, and configurations. Examples: get config, set baseUrl to "https://api.example.com", updateHeaders with {"Authorization":"Bearer token"}, search APIs by keyword, list all configured APIs |
| list_directoryB | List directory structure relative to the project path. Returns a tree of files and directories. |
| generate_rulesB | Generate project rules content based on standards. Returns content and suggested save path for user confirmation. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools have distinct purposes, but api_debug and api_execute have overlapping functionality (both execute API requests), potentially causing confusion. The rest are well-separated.
Tools use consistent underscore naming, but there is variation in verb usage (e.g., api_debug vs api_execute) and some tools like download_file or list_directory don't follow the noun_standards pattern. Overall acceptable.
With 13 tools, the count is well within the typical range for a server focused on project standards and API management, offering a balanced set without being excessive.
The tool set covers core tasks for managing project standards, API configurations, and project structure, with only minor gaps like validation or application of standards. Generally comprehensive.