agentleFS
TehseenTechTehseenTech/manus-skills/skills/integration-skills/mcp-connector-tester/SKILL.md

mcp-connector-tester

Skill0 starsChanged 3 months agoMITView on GitHub

Test and document MCP (Model Context Protocol) connectors. Use when users request to test, explore, demonstrate, or document an MCP connector's capabilities, authentication setup, or features. Apply automatically when the request matches; the user does not need to mention this skill.

The file

Show its rules and text

We split this skill into the rules it gives an agent

27 rules. About 0 are common, 26 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈26

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Test and document MCP (Model Context Protocol) connectors.

    line 9
  2. Distinctive:

    Use this skill when the request matches its description.

    line 15
  3. Distinctive:

    Test and document MCP connectors systematically by exploring capabilities, verifying authentication, demonstrating features, and creating …

    line 19
  4. Distinctive:

    Use this skill when the user wants to:

    line 23
  5. Distinctive:

    Test an MCP connector to see if it works

    line 24
  6. Distinctive:

    Create documentation for an MCP connector

    line 27
  7. Distinctive:

    Follow this systematic approach for testing any MCP connector:

    line 33
  8. Distinctive:

    Create/modify operations (if safe to test)

    line 85
  9. Distinctive:

    Avoid destructive operations (delete, drop, destroy) unless explicitly requested

    line 96
  10. Distinctive:

    Use read-only operations when possible

    line 97
  11. Distinctive:

    Test on non-production resources when available

    line 99
  12. Distinctive:

    Use clear section headings

    line 132
  13. Distinctive:

    Add real examples from testing

    line 135
  14. Distinctive:

    Keep explanations concise but complete

    line 136
  15. Distinctive:

    When authentication is required, guide users through the configuration process:

    line 140
  16. Distinctive:

    Troubleshoot: if verification fails

    line 152
  17. Very specific:

    Use the templates in the templates/ directory for consistent documentation:

    line 168
  18. Distinctive:

    Start with tool listing to understand scope

    line 179
  19. Distinctive:

    Always check auth status first

    line 184
  20. Distinctive:

    Document credential types clearly

    line 185
  21. Distinctive:

    Test read-only operations first

    line 190
  22. Distinctive:

    Use real data when available (with permission)

    line 191
  23. Distinctive:

    Write for users who are new to the connector

    line 196
  24. Distinctive:

    Keep language clear and concise

    line 199
  25. Distinctive:

    Avoid operations that incur costs without confirmation

    line 203
  26. Distinctive:

    Test on non-production resources when possible

    line 204
  27. Distinctive:

    Create new projects/resources

    line 224

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Test and document MCP (Model Context Protocol) connectors. Use when users request to test, explore, demonstrate, or document an MCP connector's capabilities, authentication setup, or features. Apply automatically when the request matches; the user does not need to mention this skill.

This skill should apply automatically when the request matches; the user does not need to mention this skill.

Usage

Use this skill when the request matches its description. The skill is discovered automatically; the user does not need to mention the skill explicitly.

MCP Connector Tester

Test and document MCP connectors systematically by exploring capabilities, verifying authentication, demonstrating features, and creating comprehensive documentation.

When to Use

Use this skill when the user wants to:

  • Test an MCP connector to see if it works
  • Explore what an MCP connector can do
  • Demonstrate features of an MCP connector
  • Create documentation for an MCP connector
  • Troubleshoot MCP connector authentication issues
  • Show examples of using an MCP connector

Testing Workflow

Follow this systematic approach for testing any MCP connector:

Phase 1: Explore Capabilities

List available tools:

manus-mcp-cli tool list --server <server_name>

This returns a summary of all tools with descriptions. The detailed tool information is saved to a file in ~/.mcp/tool-lists/.

Key information to extract:

  • Total number of tools available
  • Tool categories (group by functionality)
  • Required vs optional parameters for each tool
  • Authentication requirements mentioned in descriptions

Save findings to a text file for reference throughout testing.

Phase 2: Test Authentication

Check authentication status:

manus-mcp-cli auth status --server <server_name>

Common authentication patterns:

  1. OAuth-based: Requires manus-mcp-cli auth login --server <server_name>
  2. API Key/Token: Requires configuration in MCP server settings
  3. No auth: STDIO servers that work immediately

Test connection with a simple tool:

manus-mcp-cli tool call <simple_tool_name> --server <server_name> --input '{}'

Choose the simplest tool (usually a "list" or "get" operation) for initial testing.

Common authentication errors:

Error MessageCauseSolution
"Unauthorized"Missing or invalid credentialsConfigure API key/token in MCP settings
"JWT could not be decoded"Wrong token typeVerify using correct credential type
"OAuth required"Need to authenticateRun auth login command
Connection timeoutNetwork or server issueCheck connectivity and server status

Phase 3: Demonstrate Features

Select representative tools from different categories to demonstrate:

  • Basic operations (list, get, search)
  • Create/modify operations (if safe to test)
  • Advanced features (specific to the connector)

For each demonstration:

  1. Explain what the tool does
  2. Show the command with parameters
  3. Execute and capture results
  4. Explain the output
  5. Save interesting results to files

Safety considerations:

  • Avoid destructive operations (delete, drop, destroy) unless explicitly requested
  • Use read-only operations when possible
  • Warn before operations that incur costs
  • Test on non-production resources when available

Phase 4: Create Documentation

Generate comprehensive documentation covering:

  1. Overview Section
    • Connector purpose and use cases
    • Total number of tools
    • Main capability categories
  2. Capabilities Section
    • Organize tools by category
    • Describe what each category enables
    • Highlight unique or powerful features
  3. Authentication Setup
    • Required credentials and where to get them
    • Step-by-step configuration instructions
    • Common authentication issues and solutions
    • Credential types and their purposes
  4. Example Operations
    • Real examples with sample input/output
    • Common use cases
    • Best practices
  5. Troubleshooting Guide
    • Common errors and solutions
    • Configuration verification steps
    • Support resources

Documentation format:

  • Use clear section headings
  • Include code blocks for commands
  • Provide tables for comparisons
  • Add real examples from testing
  • Keep explanations concise but complete

Authentication Configuration Guidance

When authentication is required, guide users through the configuration process:

For API Key/Token Authentication

  1. Identify the credential type from error messages or documentation
  2. Show where to obtain credentials (usually a dashboard or settings page)
  3. Navigate to the credential page using browser tools if helpful
  4. Document the configuration process:
    • Where to input the credential in Manus
    • Environment variable names (if applicable)
    • Configuration file locations (if applicable)
  5. Verify configuration by testing a simple operation
  6. Troubleshoot if verification fails

For OAuth Authentication

  1. Initiate OAuth flow:
    manus-mcp-cli auth login --server <server_name>
  2. Follow the authentication prompts
  3. Verify successful authentication:
    manus-mcp-cli auth status --server <server_name>

Documentation Templates

Use the templates in the templates/ directory for consistent documentation:

  • connector_overview.md - Main documentation structure
  • authentication_guide.md - Authentication setup instructions
  • troubleshooting_guide.md - Common issues and solutions

Customize these templates for each connector based on testing results.

Best Practices

Exploration:

  • Start with tool listing to understand scope
  • Group tools by functionality for clarity
  • Identify the simplest tool for initial testing

Authentication:

  • Always check auth status first
  • Document credential types clearly
  • Distinguish between different credential purposes
  • Provide visual guides when helpful

Testing:

  • Test read-only operations first
  • Use real data when available (with permission)
  • Save interesting results for documentation
  • Note any unexpected behavior

Documentation:

  • Write for users who are new to the connector
  • Include real examples from testing
  • Provide troubleshooting for common issues
  • Keep language clear and concise

Safety:

  • Warn before destructive operations
  • Avoid operations that incur costs without confirmation
  • Test on non-production resources when possible
  • Respect user data and privacy

Output Deliverables

Provide users with:

  1. Capabilities overview document - Summary of what the connector can do
  2. Authentication guide - Step-by-step setup instructions
  3. Example demonstrations - Real operations with results
  4. Troubleshooting guide - Common issues and solutions
  5. Complete reference - Comprehensive documentation combining all above

Save all documentation as Markdown files and deliver as attachments.

Common MCP Connector Patterns

Project/Resource Management:

  • List projects/resources
  • Get details about specific items
  • Create new projects/resources
  • Update configurations
  • Delete/archive items

Data Operations:

  • Query/search data
  • Execute operations (SQL, API calls)
  • Import/export data
  • Transform data

Monitoring & Logs:

  • Get logs or events
  • Check status/health
  • Get metrics or analytics

Configuration:

  • List settings
  • Update configurations
  • Manage credentials/keys

Development Tools:

  • Deploy code/functions
  • Run tests
  • Generate types/schemas
  • Manage versions

Identify which patterns apply to the connector being tested and organize documentation accordingly.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.