Trello MCP Server

The Trello MCP skill is organized using a progressive disclosure pattern to help agents navigate a large number of tools (25+) without overloading their context window. The structure follows a specific hierarchy:

• SKILL.md: The primary discovery layer. It contains decision trees and a product index that acts as a router, directing agents to the correct reference files.
• references/trello-mcp/: A directory containing specialized knowledge files:
  • README.md: The entry point for the reference section, defining reading order and cross-references.
  • configuration.md: Details on authentication (TRELLO_API_KEY, TRELLO_TOKEN) and rate limits.
  • api.md: Canonical tool signatures (automatically extracted from TypeScript definitions).
  • patterns.md: Guidance on common workflows (e.g., Board $\rightarrow$ Card $\rightarrow$ Checklist).
  • gotchas.md: Critical operational details like date formats, limits, and error recovery.
• assets/source/: Contains the bundled MCP server source code for self-contained builds.
• scripts/install.sh: The runtime layer responsible for building the server from source or falling back to npm.

The SKILL.md file acts as a progressive-discovery router for AI agents using the Trello MCP server. Instead of scanning the entire repository, agents use SKILL.md to find specific setup instructions, API references, and workflow guides.

Key features of the SKILL.md workflow include:

• Trigger-rich frontmatter: Uses explicit Trello domain names in the frontmatter to trigger skill loading in compatible agents.
• Tool Routing Groups: Organizes Trello tools into logical capability groups: boards, cards, checklists, comments, attachments, labels, members, and health.
• Guardrails: Provides explicit rules for agents regarding ID discovery, date handling, rate limits, and destructive actions to prevent errors during Trello operations.
• Reference Routing: Points agents to focused reference files to keep the main workflow guide compact while providing deep context for specific operations.

The SAFLA (Self-Aware Feedback Loop Algorithm) pattern implements a continuous cycle of observation, analysis, learning, adaptation, and feedback.

Workflow:

1. OBSERVE: Query reasoningBank.query with a minConfidence threshold.
2. ANALYZE: Evaluate the relevance and reliability of retrieved patterns.
3. LEARN: Select the best pattern.
4. ADAPT: Execute the task using the selected pattern.
5. FEEDBACK: Update the pattern's reliability in the reasoningBank based on success or failure and store the new outcome.

// Implement SAFLA (Self-Aware Feedback Loop Algorithm)
class SAFLAAgent {
  async executeSAFLACycle(task) {
    // 1. OBSERVE: Retrieve relevant patterns
    const patterns = await this.reasoningBank.query(task, {
      namespace: this.namespace,
      minConfidence: 0.4
    });

    // 2. ANALYZE: Evaluate pattern relevance and confidence
    const analysis = this.analyzePatterns(patterns);

    // 3. LEARN: Select best approach
    const selectedPattern = analysis.bestPattern;

    // 4. ADAPT: Execute with selected pattern
    const result = await this.execute(selectedPattern, task);

    // 5. FEEDBACK: Update confidence and store outcome
    await this.updateConfidence(selectedPattern.id, result.success);
    await this.storeOutcome(task, result);

    // Return to step 1 for next task
    return result;
  }

  analyzePatterns(patterns) {
    return {
      bestPattern: patterns[0],
      alternatives: patterns.slice(1),
      confidence: patterns[0]?.components.reliability || 0.5
    };
  }

  async updateConfidence(patternId, success) {
    const pattern = await this.reasoningBank.getPattern(patternId);

    if (success) {
      pattern.components.reliability = Math.min(
        1.0,
        pattern.components.reliability + 0.15
      );
    } else {
      pattern.components.reliability = Math.max(
        0.0,
        pattern.components.reliability - 0.1
      );
    }

    await this.reasoningBank.updatePattern(patternId, pattern);
  }
}

Sampling allows an MCP server to request LLM completions through the client. This enables agentic behavior while maintaining security via a human-in-the-loop design: the client reviews the request, samples from an LLM, and returns the result to the server.

Note: This feature is currently not supported in the Claude Desktop client.

Requesting a Sample

Servers send a sampling/createMessage request. The request can include:

• messages: Conversation history (roles: user or assistant; content: text or image).
• modelPreferences: Hints for model selection (e.g., name: "claude-3") and priority levels for costPriority, speedPriority, and intelligencePriority (0-1).
• systemPrompt: A requested system prompt.
• includeContext: Determines context scope ("none", "thisServer", or "allServers").
• temperature, maxTokens, stopSequences, and metadata.

Response Format

The client returns a completion containing the model used, the role of the response, and the content (text or image).

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What files are in the current directory?"
        }
      }
    ],
    "systemPrompt": "You are a helpful file system assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

Roots are URIs that a client suggests a server should focus on. They define the boundaries within which a server operates. While primarily used for filesystem paths, they can be any valid URI (e.g., https://api.example.com/v1).

Purpose

• Guidance: Informs servers about relevant resources and locations.
• Clarity: Defines which resources are part of the active workspace.
• Organization: Allows working with multiple distinct resource sets (e.g., a local repo and a remote API) simultaneously.

Implementation Notes

Roots are informational, not strictly enforcing. Servers should respect provided roots, use them to locate resources, and prioritize operations within those boundaries. Clients declare the roots capability during connection and provide a list of suggested roots.

{
  "roots": [
    {
      "uri": "file:///home/user/projects/frontend",
      "name": "Frontend Repository"
    },
    {
      "uri": "https://api.example.com/v1",
      "name": "API Endpoint"
    }
  ]
}