Skip to main content
Glama
liliangshan

MCP Project Standards Server

by liliangshan
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

MCP Project Standards Server

A MCP (Model Context Protocol) server for project standards management, designed for AI-assisted development to help teams maintain unified development standards and specifications across multiple machines.

📋 Version Updates

v5.1.0 (2025-12-22)

  • New Tool: Added download_file tool to download files from URL to project path.

  • Version Sync: Updated server and package versions to 5.1.0.

v5.0.0 (2025-12-19) - Major Release

  • Project Path Support: Added PROJECT_PATH environment variable for resolving relative paths.

  • Cursor Detection: Automatic identification of Cursor IDE for enhanced features.

  • New Tools: Added list_directory, generate_cursorrules, and generate_rules.

  • AI Guidance: Integrated AI Enforcement Rules into rule generation templates.

  • Security: Added path validation for directory listing.

v3.0.0 (2025-10-31) - Major Release

🚀 Breaking Changes

  • Config directory resolution now depends on both CONFIG_DIR and TOOL_PREFIX:

    • If CONFIG_DIR is set, it is used as-is

    • If CONFIG_DIR is not set and TOOL_PREFIX is set, use ./.setting.<TOOL_PREFIX>

    • Otherwise default to ./.setting

  • tools/call now strips the TOOL_PREFIX from tool names before method dispatch. If you call xxx_api_debug (with TOOL_PREFIX=xxx), the server routes the call to api_debug internally.

✨ New/Improved

  • Unified getConfigDir() used by both server-final.js and api_common.js

  • tools/list shows environment with resolved CONFIG_DIR

  • Prefixed tool names and project-branded descriptions when both TOOL_PREFIX and PROJECT_NAME are provided

🧹 Cleanup

  • Removed duplicate legacy api_debug method definition

💡 Benefits

  • Multi-project isolation: simple per-project segregation via TOOL_PREFIX without code changes

  • Zero-friction switching: swap project context by environment only

  • Smoother tool calling: clients can call prefixed names, server auto-routes

v2.0.0 (2024-12-19) - Major Release

🚀 New Tools & Features

  • API Login Tool (api_login): Direct login authentication using environment variables

  • API Debug Tool (api_debug): Simplified API request execution

  • API Config Tool (api_config): Comprehensive configuration management

  • Code Refactoring: Eliminated duplicate code with shared utilities

  • Enhanced Environment Variable Support: Flexible login body formats (JSON/string)

🔧 Technical Improvements

  • Reduced Code Duplication: ~70% reduction in duplicate code

  • Better Error Handling: Unified error management across tools

  • Improved Performance: Faster module loading and execution

  • Enhanced Maintainability: Centralized configuration management

v1.1.0 (2024-12-19)

🆕 New Features

  • API Debug Tool Environment Variable Support:

    • API_DEBUG_ALLOWED_METHODS - Control allowed request methods (default: GET)

    • API_DEBUG_LOGIN_URL - Set login API URL (default: /api/login)

    • API_DEBUG_LOGIN_METHOD - Set login request method (default: POST)

    • API_DEBUG_LOGIN_BODY - Set login request body (default: {"username":"","password":""})

    • API_DEBUG_LOGIN_DESCRIPTION - Set login API description (default: Save returned token to common headers in debug tool, field name Authorization, field value Bearer token)

🔧 Feature Improvements

  • Smart Login API Recognition:

    • Support for full URL and relative path matching

    • Automatic login API recognition using environment variable configuration

    • Non-login APIs strictly follow allowed method restrictions

  • Error Handling Optimization:

    • Only request-related errors are saved to api.json

    • Method validation errors don't pollute execution records

    • More precise error classification and handling

  • Dynamic Tool Description:

    • Display login authentication information based on environment variable configuration

    • Real-time display of allowed request methods and usage instructions

🛡️ Security Enhancements

  • Request Method Restrictions: Default only allows GET requests to prevent accidental operations

  • Login API Exception: Login APIs can use methods configured in environment variables

  • Flexible Configuration: Can open more request methods as needed

📚 Documentation Updates

  • Added environment variable configuration instructions

  • Updated API debug tool usage guide

  • Improved login authentication flow documentation

Related MCP server: RulesetMCP

🚀 Core Advantages

💰 Token Cost Optimization

  • Efficient Context Caching: By using MCP tools to retrieve short, structured standard data instead of reading long documents, it triggers model Context Caching more effectively (e.g., Gemini 3 Flash), significantly reducing input costs (down to $0.05/1M).

  • Incremental Output: Enforces minimal code diffs and precise tool responses, minimizing high-cost output token consumption.

🎯 Solving Multi-Machine Development Chaos

  • Unified Standards: AI assistants on multiple machines use the same project standards, avoiding inconsistent development styles

  • Team Collaboration: Eliminates code style differences caused by different developers using different AI configurations

🛡️ Enterprise-Grade Development Standards Management

  • Project Information Management: Unified management of basic project information, tech stack, versions, etc.

  • API Standards Specification: Define unified interface design standards to ensure API consistency

  • Development Standards: Code style, naming conventions, architecture standards, etc.

  • Database Standards: Table structure, naming conventions, indexing strategies, etc.

🔧 Simple Configuration Management

  • JSON Configuration: Simple configuration storage based on JSON files

  • Environment Variables: Support for specifying configuration file paths through environment variables

  • Auto-Creation: Automatically creates default configuration files on first run

✨ Main Features

  • ✅ Project Information Management - Unified management of project basic information and configuration

  • ✅ Project Structure Analysis - Intelligent analysis of project directory structure and dependencies

  • ✅ API Interface Standards - Define unified API design specifications and best practices

  • ✅ Development Standards - Code style, naming conventions, architecture standards management

  • ✅ Database Standards - Table structure design, naming conventions, indexing strategies standardization

  • ✅ API Debugging Tool - Complete API interface testing and debugging functionality

  • ✅ Configuration Management - JSON-based configuration storage and management

  • ✅ Auto-Restart - Intelligent process management and fault recovery

  • ✅ Health Checks - Real-time service status and performance monitoring

  • ✅ File Downloader - Download files from URLs directly to the project directory

🎯 Application Scenarios

Team Collaborative Development

  • Multi-Developer Environment: Ensure each developer's AI assistant follows the same project standards

  • Code Review: Unified code style and standards, reducing review time

  • New Team Member Training: Quickly help new team members understand project standards and best practices

Enterprise Projects

  • Large Projects: Manage complex project structures and multi-module development

  • Microservices Architecture: Unify API design and database standards across services

  • Multi-Environment Deployment: Standard consistency across development, testing, and production environments

AI-Assisted Development

  • Intelligent Code Generation: AI generates code that conforms to project standards

  • Automatic Refactoring: Automatically optimize and refactor code based on standards

  • Standards Checking: Real-time checking of code compliance with project standards

Installation

Global Installation (Recommended)

npm install -g @liangshanli/mcp-server-project-standards

Local Installation

npm install @liangshanli/mcp-server-project-standards

From Source

git clone https://github.com/liliangshan/mcp-server-project-standards.git
cd mcp-server-project-standards
npm install

⚙️ Configuration Management

The server uses the ./.setting/ directory to store configuration files by default. You can specify a different directory using environment variables.

Environment Variables

Variable

Default

Description

Example

PROJECT_PATH

.

Root path of the project. Supports both absolute (e.g., / or C:\) and relative paths. Used to resolve all relative paths.

export PROJECT_PATH="/path/to/project"

CONFIG_DIR

./.setting or ./.setting.

Configuration directory. Resolved relative to PROJECT_PATH.

export CONFIG_DIR="./config"

TOOL_PREFIX

Optional tool prefix for tool names and config isolation

export TOOL_PREFIX="projA"

PROJECT_NAME

Optional project branding for tool descriptions

export PROJECT_NAME="MyProject"

API_DEBUG_ALLOWED_METHODS

GET

Control allowed request methods (supports: GET,POST,PUT,DELETE,PATCH, etc.)

export API_DEBUG_ALLOWED_METHODS="GET,POST"

API_DEBUG_LOGIN_URL

/api/login

Set login API URL

export API_DEBUG_LOGIN_URL="/api/auth/login"

API_DEBUG_LOGIN_METHOD

POST

Set login request method

export API_DEBUG_LOGIN_METHOD="POST"

API_DEBUG_LOGIN_BODY

{"username":"","password":""}

Set login request body

export API_DEBUG_LOGIN_BODY='{"mobile":"","password":""}'

API_DEBUG_LOGIN_DESCRIPTION

Save returned token to common headers in debug tool, field name Authorization, field value Bearer token

Set login API description

export API_DEBUG_LOGIN_DESCRIPTION="User Login API"

Configuration Files

The server uses two configuration files:

  • config.json - Project standards configuration

  • api.json - API debugging configuration

config.json default values:

{
  "project_info": {},
  "project_structure": [],
  "api_standards": {},
  "development_standards": [],
  "database_standards": []
}

api.json default values:

{
  "baseUrl": "",
  "headers": {
    "Content-Type": "application/json",
    "Accept": "application/json"
  },
  "list": []
}

Configuration Field Description

config.json fields:

  • project_info - Project basic information (project name, development language, description, etc.)

  • project_structure - Project structure definition (directory and file descriptions)

  • api_standards - API interface standards (interface type, response structure, request headers, etc.)

  • development_standards - Development standards (code style, naming conventions, etc.)

  • database_standards - Database standards (table naming, field naming, etc.)

api.json fields:

  • baseUrl - API base URL

  • headers - Common request headers (authentication, Content-Type, etc.)

  • list - API interface list (includes request parameters, response data, execution history, etc.)

🚀 Quick Start

1. Direct Run (Global Installation)

mcp-server-project-standards

2. Using npx (Recommended)

npx @liangshanli/mcp-server-project-standards

3. Direct Start (Source Installation)

npm start

4. Managed Start (Recommended for Production)

npm run start-managed

Managed start provides:

  • Auto-restart (up to 10 times)

  • Error recovery

  • Process management

  • Logging

5. Development Mode

npm run dev

Editor Integration

Cursor Editor Configuration

  1. Single-project example (no prefix isolation):

{
  "mcpServers": {
    "project-standards": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "CONFIG_DIR": "./.setting",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"\",\"password\":\"\"}",
        "API_DEBUG_LOGIN_DESCRIPTION": "Save returned token to common headers in debug tool, field name Authorization, field value Bearer token"
      }
    }
  }
}

  1. Multi-project example (with TOOL_PREFIX + PROJECT_NAME):

{
  "mcpServers": {
    "project-standards-A": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "TOOL_PREFIX": "projA",
        "PROJECT_NAME": "Project A",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"\",\"password\":\"\"}"
      }
    },
    "project-standards-B": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "TOOL_PREFIX": "projB",
        "PROJECT_NAME": "Project B",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/auth/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"mobile\":\"\",\"password\":\"\"}"
      }
    }
  }
}

VS Code Configuration

  1. Single-project example (no prefix isolation):

{
  "mcp.servers": {
    "project-standards": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "CONFIG_DIR": "./.setting",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"\",\"password\":\"\"}"
      }
    }
  }
}

  1. Multi-project example (with TOOL_PREFIX + PROJECT_NAME):

{
  "mcp.servers": {
    "project-standards-A": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "TOOL_PREFIX": "projA",
        "PROJECT_NAME": "Project A",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"username\":\"\",\"password\":\"\"}"
      }
    },
    "project-standards-B": {
      "command": "npx",
      "args": ["@liangshanli/mcp-server-project-standards"],
      "env": {
        "PROJECT_PATH": ".",
        "TOOL_PREFIX": "projB",
        "PROJECT_NAME": "Project B",
        "API_DEBUG_ALLOWED_METHODS": "GET,POST,PUT,DELETE",
        "API_DEBUG_LOGIN_URL": "/api/auth/login",
        "API_DEBUG_LOGIN_METHOD": "POST",
        "API_DEBUG_LOGIN_BODY": "{\"mobile\":\"\",\"password\":\"\"}"
      }
    }
  }
}

🛠️ Available Tools

1. Project Information Management (project_info)

Get and manage project basic information, including project name, development language, description, etc.

Parameters:

  • action (required): Operation type - "get" to retrieve info, "set" to set info

  • key (optional): Field to set - "projectName", "developmentLanguage", "basicInfo"

  • value (optional): Value to set

Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "project_info",
    "arguments": {
      "action": "set",
      "key": "projectName",
      "value": "My Project"
    }
  }
}

2. Project Structure Management (project_structure)

Get and manage project directory structure with depth control and hidden file inclusion.

Parameters:

  • action (required): Operation type - "get" to retrieve structure, "set" to set structure, "delete" to delete structure item

  • structure (optional): Structure item array (required for set action)

  • path (optional): Path to delete (required for delete action)

Example:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "project_structure",
    "arguments": {
      "action": "set",
      "structure": [
        {
          "path": "/src",
          "description": "Source code directory"
        }
      ]
    }
  }
}

3. API Standards Management (api_standards)

Get and manage API interface standards and best practices.

Parameters:

  • action (required): Operation type - "get" to retrieve standards, "set" to set standards, "delete" to delete standards

  • key (optional): Field to set - "interfaceType", "successStructure", "errorStructure", "basicHeaders", "requirements"

  • value (optional): Value to set

  • forceOverwrite (optional): Whether to force overwrite array values (default: false)

Example:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "api_standards",
    "arguments": {
      "action": "set",
      "key": "requirements",
      "value": ["Unified response format", "Error code standards", "Parameter validation"],
      "forceOverwrite": true
    }
  }
}

4. Development Standards Management (development_standards)

Get and manage development standards, including code style, Git workflow, testing, and documentation.

Parameters:

  • action (required): Operation type - "get" to retrieve standards, "set" to set standards, "delete" to delete standards

  • standards (optional): Standards array (required for set action)

  • forceOverwrite (optional): Whether to force overwrite array values (default: false)

Example:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "tools/call",
  "params": {
    "name": "development_standards",
    "arguments": {
      "action": "set",
      "standards": ["Use 2 spaces for indentation", "Use single quotes", "Use camelCase naming"],
      "forceOverwrite": false
    }
  }
}

5. Database Standards Management (database_standards)

Get and manage database standards, including table structure design, naming conventions, indexing strategies, etc.

Parameters:

  • action (required): Operation type - "get" to retrieve standards, "set" to set standards, "delete" to delete standards

  • standards (optional): Standards array (required for set action)

  • forceOverwrite (optional): Whether to force overwrite array values (default: false)

Example:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/call",
  "params": {
    "name": "database_standards",
    "arguments": {
      "action": "set",
      "standards": [
        "Use test_ prefix for all table names",
        "Use snake_case for table and field names",
        "Use singular form for table names"
      ],
      "forceOverwrite": true
    }
  }
}

6. API Debugging Tool (api_debug)

Complete API interface testing and debugging functionality, supporting multiple HTTP methods, authentication, parameter passing, etc.

Parameters:

  • action (required): Operation type - "get" to retrieve config, "set" to update config, "delete" to delete API, "execute" to execute API, "updateBaseUrl" to update base URL, "updateHeaders" to update headers, "deleteHeader" to delete specific header, "search" to search APIs

  • config (optional): API debug configuration (required for set action)

  • index (optional): API index (required for execute/delete actions)

  • baseUrl (optional): New base URL (required for updateBaseUrl action)

  • headers (optional): New headers (required for updateHeaders action)

  • headerName (optional): Header name to delete (required for deleteHeader action)

  • keyword (optional): Search keyword (required for search action)

Features:

  • Smart Content-Type Detection: Automatically detect request body type (JSON, XML, HTML, URL-encoded, etc.)

  • Authentication Management: Support Bearer Token and other authentication methods

  • URL Deduplication: Same URL only saves one copy of data, avoiding duplicates

  • Execution Recording: Record execution history regardless of success or failure

  • Search Function: Support searching APIs by URL or description

  • Parameter Management: Support query parameters, request body, custom headers, etc.

🔐 Special Note - Login Authentication Flow:

The API debugging tool supports a complete login authentication flow, making it easy to manage API access permissions:

  1. Login API Configuration:

    • First configure the login API (e.g., /api/login)

    • Set login request parameters (username, password, etc.)

    • Execute login request to obtain authentication information

  2. Automatic Token Management:

    • After successful login, the tool automatically extracts returned token or cookie

    • Automatically writes authentication information to common request headers (e.g., Authorization: Bearer token)

    • All subsequent API requests automatically carry authentication information

  3. Authentication Expiration Handling:

    • When API returns authentication expired error

    • Re-execute the original login API to get new token

    • Use updateHeaders operation to update common request headers

    • Continue debugging other APIs that require authentication

  4. Usage Flow Example:

    # 1. Configure login API
api_debug set config={login_api_config}

# 2. Execute login to get token
api_debug execute index=0

# 3. Update common request headers (automatic)
api_debug updateHeaders headers={Authorization: Bearer token}

# 4. Debug other APIs that require authentication
api_debug execute index=1

# 5. If token expires, re-login
api_debug execute index=0  # Re-execute login

This design eliminates the need for manual authentication state management, as the tool automatically handles login and token updates, greatly simplifying the API debugging process!

7. Directory Listing (list_directory)

Recursively explores the directory structure relative to the project root.

Parameters:

  • path (optional): Subdirectory path to list.

  • depth (optional): Max recursion depth (default: 2).

Example:

{
  "jsonrpc": "2.0",
  "id": 10,
  "method": "tools/call",
  "params": {
    "name": "list_directory",
    "arguments": {
      "depth": 3
    }
  }
}

8. Rule Generation (generate_cursorrules / generate_rules)

Generates AI project guidance files (.cursorrules for Cursor, PROJECT_RULES.md for others) based on your standards.

Parameters:

  • save (optional): Whether to save content to disk (default: false).

Example:

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "tools/call",
  "params": {
    "name": "generate_cursorrules",
    "arguments": {
      "save": true
    }
  }
}

9. File Download Tool (download_file)

Download a file from a URL and save it to a specified path within the project.

Parameters:

  • url (required): The URL of the file to download.

  • savePath (required): The path where the file should be saved (relative to project path or absolute).

Example:

{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "download_file",
    "arguments": {
      "url": "https://example.com/logo.png",
      "savePath": "assets/logo.png"
    }
  }
}

🔗 Related Tools for Collaborative Use

To provide a more complete development experience, we recommend using the following MCP tools in collaboration:

🗄️ Database Management Tools

MySQL Database Support

  • NPM Package: @liangshanli/mcp-server-mysql

  • GitHub Repository: mcp-server-mysql

  • Features: DDL operations, permission control, operation logs, connection pool management

  • Highlights: Supports DDL SQL logging for easy database structure synchronization

SQL Server Database Support

🎨 Icon Management Tools

Icon Resource Management

  • NPM Package: @liangshanli/mcp-server-icon

  • GitHub Repository: mcp-server-icon

  • Features: Icon resource management, icon search, icon library integration

  • Highlights: Supports multiple icon libraries for convenient UI development

🚀 Collaborative Development Benefits

Complete Development Stack:

  • Project Standards + Database Management + API Debugging + Icon Resources = Full-stack development solution

  • Unified MCP protocol for seamless integration of all tools

  • Consistent configuration management and error handling mechanisms

Team Collaboration:

  • All tools support unified standards across multi-machine environments

  • Shared configuration files and logging systems

  • Easy onboarding and collaboration for team members

Development Efficiency:

  • One-stop solution from project standards to database operations to API debugging

  • Reduced tool switching costs and improved development efficiency

  • Unified error handling and logging

Usage Example:

# 1. Install project standards management tool
npm install -g @liangshanli/mcp-server-project-standards

# 2. Install database management tools (choose as needed)
npm install -g @liangshanli/mcp-server-mysql
# or
npm install -g @liangshanli/mcp-server-mssqlserver

# 3. Install icon management tool
npm install -g @liangshanli/mcp-server-icon

# 4. Configure multiple MCP servers in your editor

Example:

Set API Configuration:

{
  "jsonrpc": "2.0",
  "id": 6,
  "method": "tools/call",
  "params": {
    "name": "api_debug",
    "arguments": {
      "action": "set",
      "config": {
        "baseUrl": "https://api.example.com",
        "headers": {
          "Content-Type": "application/json",
          "Authorization": "Bearer your-token"
        },
        "list": [
          {
            "description": "User Login",
            "url": "/api/login",
            "method": "POST",
            "body": {
              "username": "user",
              "password": "pass"
            }
          }
        ]
      }
    }
  }
}

Execute API Request:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "api_debug",
    "arguments": {
      "action": "execute",
      "index": 0
    }
  }
}

Search API:

{
  "jsonrpc": "2.0",
  "id": 8,
  "method": "tools/call",
  "params": {
    "name": "api_debug",
    "arguments": {
      "action": "search",
      "keyword": "login"
    }
  }
}

Update Authentication Headers:

{
  "jsonrpc": "2.0",
  "id": 9,
  "method": "tools/call",
  "params": {
    "name": "api_debug",
    "arguments": {
      "action": "updateHeaders",
      "headers": {
        "Authorization": "Bearer new-token"
      }
    }
  }
}

🛡️ Error Handling

  • Individual request errors don't affect the entire server

  • Configuration errors are automatically recovered

  • Process exceptions are automatically restarted (managed mode)

📁 Project Structure

mcp-server-project-standards/
├── src/
│   ├── server-final.js           # Main server file
│   └── utils/                    # Utility functions directory
│       ├── get_project_info.js   # Project information management
│       ├── get_project_structure.js # Project structure management
│       ├── get_api_standards.js  # API standards management
│       ├── get_development_standards.js # Development standards management
│       ├── database_standards.js # Database standards management
│       ├── api_debug.js          # API debugging tool
│       └── ...                   # Other tools
├── bin/
│   └── cli.js                    # CLI startup script
├── start-server.js               # Managed startup script
├── package.json
└── README.md

🧪 Testing

npm test

📄 License

MIT

🤝 Contributing

Welcome to submit Issues and Pull Requests to improve this project!

📞 Support

If you encounter problems during use, please:

  1. Check the Issues page

  2. Create a new Issue describing your problem

  3. Provide detailed error information and reproduction steps

Make AI-assisted development more standardized and efficient! 🚀

Available Tools

13 tools
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

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve config, "set" to update config, "updateBaseUrl" to update base URL, "updateHeaders" to update headers, "deleteHeader" to delete header, "addApi" to add API endpoint, "search" to search APIs, "list" to list all APIs
configNoAPI configuration (required for "set" action)
baseUrlNoNew base URL (required for "updateBaseUrl" action)
headersNoNew headers to add or update (required for "updateHeaders" action)
headerNameNoName of header to delete (required for "deleteHeader" action)
apiNoAPI configuration (required for "addApi" action)
keywordNoSearch keyword (required for "search" action)

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as side effects of mutations (e.g., 'set', 'updateHeaders', 'deleteHeader'), required permissions, or whether changes are reversible. It relies on the action names to imply behavior.

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 sentence followed by examples, which is concise and efficient. However, the examples could be better integrated into a structured format like bullet points, but the current form is acceptable.

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?

The description does not explain what is returned by actions like 'get' or 'list', nor does it describe the overall config structure. Given the tool's complexity (7 parameters, nested objects), this is a notable gap.

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 the description adds little beyond what the schema already provides. The examples mirror the action enum but do not add new semantic meaning.

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 is an 'API configuration management tool' and lists specific example actions like 'get config', 'set baseUrl', 'updateHeaders', 'search APIs', 'list all configured APIs', which distinguish it from sibling tools like api_execute or api_debug.

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 examples but does not explicitly state when to use this tool versus siblings like api_execute. It implies configuration management usage, but lacks clear exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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"

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoAPI URL to execute (required)
methodNoHTTP method (optional, defaults to GET)
headersNoAdditional headers for the request (optional)
queryNoQuery parameters (optional)
bodyNoRequest body (optional) - Supports multiple formats: JSON object, form data, or plain text
contentTypeNoContent-Type for request body (optional, will auto-detect if not specified)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior but only mentions automatic content-type detection and flexible body formats. It omits critical details such as error handling, authentication requirements, rate limits, or the potential impact of executing arbitrary requests, leaving significant ambiguity.

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 (two sentences plus inline examples) and front-loaded with the core purpose. However, the inline examples make it slightly longer than necessary; still, it efficiently communicates key 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?

Given the tool's complexity (6 parameters, no annotations, no output schema), the description covers the basic purpose and provides examples but lacks safety warnings, usage guidelines, and behavioral details. It is adequate but not comprehensive.

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 schema already provides 100% coverage with descriptions and examples. The description adds value by emphasizing automatic content-type detection and flexible body format support, and by listing explicit examples that illustrate usage patterns 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 explicitly states 'API debugging tool for directly executing API requests' with specific features like automatic content-type detection. It clearly identifies the tool's purpose and distinguishes it from siblings through the mention of flexible body format support and automatic detection, even without explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/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 (e.g., api_execute). It does not specify prerequisites, limitations, or when not to use it, leaving the agent without clear decision criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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"}}

ParametersJSON Schema
NameRequiredDescriptionDefault
indexYesIndex of the API to execute from the configured list (required)
overridesNoOptional parameters to override the configured API settings

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully convey behavioral traits. The description only states it executes API requests, implying network calls and potential state changes, but omits details on idempotency, side effects, authentication, rate limits, or error handling. Given the high burden, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with two sentences: one for purpose and one for examples. It is front-loaded and contains no redundant information. However, the structure could be improved by separating usage guidelines, but overall it's efficient.

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 no output schema, the description should mention what the tool returns (e.g., API response). It does not. The tool has nested overrides objects, but no explanation of defaults or merging behavior. The description is incomplete for a tool that performs external requests and has sibling tools with different purposes.

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 descriptions for both parameters. The description adds an example of overrides (method, body), which provides practical context beyond schema. However, it doesn't clarify behavior when overrides are omitted or how they merge with configured settings. This meets baseline but doesn't significantly exceed it.

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 it executes API requests by index from a configured list, and provides examples. The verb 'Execute' and resource 'API requests' are specific. While it doesn't explicitly differentiate from sibling tools like api_config, api_debug, etc., the action is distinct enough for an agent to infer purpose.

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 gives examples of usage (execute at index, with overrides) but lacks guidance on when to use this tool versus alternatives like api_debug or api_config. No when-not-to-use or prerequisite conditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema
NameRequiredDescriptionDefault
toolNoSpecific tool name to get help for (optional: api_debug, api_login, api_config)

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states that it provides documentation and examples, omitting details like whether it performs any actions, authentication requirements, or rate limits. This is insufficient for a tool with no annotations.

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, no wasted words, front-loaded with the tool's purpose. Efficiently communicates the core function.

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?

No output schema exists, so the description should explain what the tool returns. It says 'detailed documentation and examples' but does not specify the format (e.g., text, file) or structure. Adequate but could be more complete given the lack of output schema.

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 the 'tool' parameter having a description and examples. The description does not add additional meaning beyond the schema; it simply restates that the tool provides help. Baseline score 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 the tool's purpose: 'provides detailed documentation and examples for all API debugging tools.' It names the specific sibling tools it supports, distinguishing it from other tools in the list.

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 the tool: 'Use this to understand how to use api_debug, api_login, and api_config tools effectively.' It does not mention when not to use it or provide alternatives, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

ParametersJSON Schema
NameRequiredDescriptionDefault
baseUrlNoBase URL for login request (optional, will override config baseUrl)

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behavioral traits: uses env vars, extracts token from response, updates Authorization headers. Lacks detail on side effects like header persistence, but adequate given no annotations.

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 with no wasted words, front-loaded with core purpose.

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?

Despite no output schema, the description covers the essential authentication flow sufficiently for a simple tool with one optional parameter.

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 covers the single parameter fully (100% coverage). Description adds that baseUrl is optional and overrides config, which adds marginal value.

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?

Clearly identifies the tool as an API login authentication tool that uses environment variables and extracts tokens, distinguishing it from sibling tools like api_execute or api_debug.

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?

States optional baseUrl parameter for overriding default, but does not explicitly specify when to use versus alternatives or provide exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

api_standardsA

Get, set or delete API interface standards and best practices

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve standards, "set" to update standards, "delete" to delete header
keyNoKey to update when action is "set" (interfaceType|successStructure|errorStructure|basicHeaders|requirements)
valueNoValue to set when action is "set" (must be string or array)
forceOverwriteNoForce overwrite array values when action is "set" and value is array (default: false)
headerNameNoHeader name to delete when action is "delete"
requirementNoRequirement content to delete when action is "delete"

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It states the three possible actions (get, set, delete), but does not disclose potential side effects, such as the destructive nature of delete, or any permissions required.

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 a single sentence with 10 words, efficiently conveying the core actions. It is front-loaded and contains no extraneous information.

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?

The tool has a complex schema with conditional logic (anyOf) and 6 parameters, but the description does not capture this complexity. It omits important context like the fact that 'set' requires key and value, and 'delete' requires headerName or requirement, leaving the agent to fully rely on the schema.

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 for all parameters. The description adds no new meaning beyond what the schema already provides, so it meets the baseline expectation without exceeding it.

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: getting, setting, or deleting API interface standards and best practices. It uses a specific verb and resource, and the name distinguishes it from sibling tools like api_config and development_standards.

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 lacks guidance on when to use this tool versus alternatives like api_config or database_standards. It does not specify prerequisites or exclusions, leaving the agent to infer usage from the name and schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

database_standardsC

Get, set or delete database standards

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve standards, "set" to update standards, "delete" to delete standard
standardsNoArray of database standards (required for "set" action)
forceOverwriteNoForce overwrite array values when action is "set" and value is array (default: false)
standardNoStandard content to delete when action is "delete"

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It fails to disclose side effects (e.g., overwriting), required permissions, or error handling. The forceOverwrite parameter hints at behavior but is not explained in the description.

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 a single sentence, concise but excessively brief for a tool with multiple conditional parameters. It lacks structure and important details.

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?

No output schema is provided, so the description should explain return values, but it does not. The tool has complex conditional logic (anyOf) that is not addressed. The relationship to sibling standards tools is unclear.

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 the baseline is 3. The description adds no extra meaning beyond what the schema already provides, but the schema sufficiently documents the parameters.

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 performs get, set, or delete operations on database standards. However, it does not differentiate from sibling tools like api_standards or development_standards, reducing clarity in context.

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 only lists the possible actions without providing guidance on when to use each action or when to prefer this tool over alternatives. No prerequisites or context are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

development_standardsC

Get, set or delete development standards

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve standards, "set" to update standards, "delete" to delete standard
standardsNoArray of development standards (required for "set" action)
forceOverwriteNoForce overwrite array values when action is "set" and value is array (default: false)
standardNoStandard content to delete when action is "delete"

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states actions without disclosing behavioral traits such as overwrite behavior on set, side effects of delete, or permission requirements. The description is too minimal to inform the agent of implications.

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 sentence, very concise. However, it may be too terse, lacking necessary details. Still, it is front-loaded and avoids redundancy.

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?

No output schema is present, and there are no annotations. The description does not explain return values for get, nor the effects of set/delete operations. Given the tool's complexity (multiple actions with dependencies), the description is incomplete.

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 the input schema already documents parameters clearly. The description adds no additional semantic value beyond what the schema provides. Baseline of 3 is appropriate.

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 performs get, set, or delete operations on development standards. It uses specific verbs and resource. However, it does not differentiate from sibling tools like api_standards or database_standards, which also deal with standards in different contexts.

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 guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions. The description simply lists actions without helping the agent decide when to invoke this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

download_fileB

Download a file from a URL and save it to a specified path. Supported schemes: http, https.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL of the file to download (required)
savePathYesThe path where the file should be saved (relative to project path or absolute, required)

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose all behavioral traits. It mentions supported schemes (http, https) but omits behaviors like overwrite handling, size limits, or authentication needs, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, directly stating the action and supported schemes. No redundant words; front-loaded with essential 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?

For a simple download tool with no output schema, the description is fairly complete but lacks behavior details (e.g., overwrite, error handling) that an agent might need. It is adequate but not comprehensive.

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 the schema already defines both parameters. The description adds minor value by noting supported URL schemes, but this information is somewhat implicit from 'URL'. 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 'download' and the resource 'file from a URL', specifying it saves to a path. It is distinct from sibling tools like api_execute or list_directory.

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, nor any exclusion conditions. The purpose is implied, but lacks when-not-to-use or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_rulesB

Generate project rules content based on standards. Returns content and suggested save path for user confirmation.

ParametersJSON Schema
NameRequiredDescriptionDefault
saveNoWhether to save to rules file (default: false)

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the return of content and suggested save path, and implies default no-save behavior. However, it does not discuss authentication requirements or potential side effects beyond saving.

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 efficient sentence that conveys the tool's action and output. It is front-loaded and free of 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?

For a simple tool with one optional parameter, the description covers the main purpose, output, and save behavior. It omits details about standards sources but is largely complete for its complexity.

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 covers 100% of the single parameter (save) with a description, so baseline is 3. The description adds context about returning content for confirmation, but does not significantly augment schema info.

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 generates project rules content based on standards, distinguishing it from siblings like api_standards and development_standards. The verb 'generate' and resource 'project rules content' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as api_standards or database_standards. It lacks explicit context for appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_directoryB

List directory structure relative to the project path. Returns a tree of files and directories.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoSubdirectory path to list (relative to project path, optional)
depthNoMax depth to traverse (default: 2, optional)

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full responsibility. It only states the output type but does not disclose behavioral traits like handling of hidden files, traversal limits beyond depth, or potential performance impact for large directories.

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 convey the tool's purpose and output without extraneous information. Every word is meaningful.

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 simple tool with two optional parameters and no output schema, the description provides sufficient clarity for basic use. However, it could be enhanced with details like default behavior for hidden files or recommendations for large directories.

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 the description adds minimal new meaning beyond the schema descriptions. The phrase 'relative to the project path' clarifies the context for the 'path' parameter, but it largely reiterates schema content.

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 verb 'list' and the resource 'directory structure', and clarifies the output as 'a tree of files and directories'. It distinguishes from sibling tools like 'project_structure' by specifying it lists a directory relative to the project path.

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 guidance is provided on when to use this tool versus alternatives such as 'project_structure'. There are no exclusions or context about scenarios where this tool is appropriate or not.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_infoC

Get or set project information in configuration file

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve info, "set" to update info
keyNoKey to update when action is "set" (projectName|developmentLanguage|basicInfo)
valueNoValue to set when action is "set"

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only mentions 'get or set', indicating both read and write behavior, but with no annotations, it lacks details on side effects, permissions, or error states. The behavioral disclosure is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, front-loaded with the key action and resource. It is concise with no fluff, though it could benefit from slight expansion for clarity.

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 absence of annotations and output schema, the description is insufficiently detailed. It does not explain the scope of 'project information', value format, or error handling, making it incomplete for a tool with 3 parameters.

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?

Input schema has 100% coverage, and the description adds no significant meaning beyond the schema. The baseline is 3 as the schema already explains the parameters.

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 can get or set project information in a configuration file, specifying the verb and resource. However, it could be more specific about the nature of the 'project information' and the configuration file context.

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 alternative tools. Sibling tools suggest various other operations but no comparison is made. The usage scenario is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

project_structureB

Get, set or delete project structure in configuration

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: "get" to retrieve structure, "set" to update structure, "delete" to delete structure item
structureNoArray of structure items with path and description (required for "set" action)
pathNoPath to delete when action is "delete"

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose side effects, authentication needs, or that 'delete' is destructive. It only lists actions without 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no filler, front-loaded with verb and resource. Every word earns its place.

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 can modify configuration, missing details: return value of 'get', effect of 'set', and behavior of 'delete'. Incomplete for a 3-parameter tool with no output schema or annotations.

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 the schema already explains parameters. The description adds no extra meaning beyond summarizing actions, which is already in the enum.

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 (Get, set, delete) and resource (project structure in configuration), and the actions differentiate it from sibling tools like api_config or database_standards.

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 usage for managing project configuration but does not explicitly state when to use this tool versus alternative configuration tools, nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 13 tool updatesv5.1.0
    • First observedapi_config
    • First observedapi_debug
    • First observedapi_execute
    • First observedapi_help
    • First observedapi_login
    • First observedapi_standards
    • First observeddatabase_standards
    • First observeddevelopment_standards
    • First observeddownload_file
    • First observedgenerate_rules
    • First observedlist_directory
    • First observedproject_info
    • First observedproject_structure
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • EX MCP Server

    Zazzles2908
    A
    license
    Not graded
    quality
    Not graded
    maintenance
    Provides unified development tools including code analysis, debugging, refactoring, documentation, testing, and project automation through multiple LLM providers (KIMI, GLM, OpenRouter). Features agentic audit capabilities with multi-model consensus for finding issues and generating direct fixes.
    -

  • RulesetMCP

    n8daniels
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides AI agents with queryable, version-controlled project rules and coding standards. Enables validation, rule-based guidance, and task summaries to keep AI work aligned with your project's conventions without repeating context.
    2
    MIT

  • Antigravity Agent Config

    greatpola
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Provides tools to manage, initialize, and synchronize standardized agent configurations and specialized workflows across various projects. It enables AI agents to access global rules and role-specific guidelines for development, design, and planning via the Model Context Protocol.
    7
    -

Latest Blog Posts

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/liliangshan/mcp-server-project-standards'

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