@cubis/foundry 0.3.32 → 0.3.33

package/mcp/skills/datadog-automation/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: datadog-automation
+description: "Automate Datadog tasks via Rube MCP (Composio): query metrics, search logs, manage monitors/dashboards, create events and downtimes. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# Datadog Automation via Rube MCP
+
+Automate Datadog monitoring and observability operations through Composio's Datadog toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Datadog connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `datadog`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `datadog`
+3. If connection is not ACTIVE, follow the returned auth link to complete Datadog authentication
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Query and Explore Metrics
+
+**When to use**: User wants to query metric data or list available metrics
+
+**Tool sequence**:
+1. `DATADOG_LIST_METRICS` - List available metric names [Optional]
+2. `DATADOG_QUERY_METRICS` - Query metric time series data [Required]
+
+**Key parameters**:
+- `query`: Datadog metric query string (e.g., `avg:system.cpu.user{host:web01}`)
+- `from`: Start timestamp (Unix epoch seconds)
+- `to`: End timestamp (Unix epoch seconds)
+- `q`: Search string for listing metrics
+
+**Pitfalls**:
+- Query syntax follows Datadog's metric query format: `aggregation:metric_name{tag_filters}`
+- `from` and `to` are Unix epoch timestamps in seconds, not milliseconds
+- Valid aggregations: `avg`, `sum`, `min`, `max`, `count`
+- Tag filters use curly braces: `{host:web01,env:prod}`
+- Time range should not exceed Datadog's retention limits for the metric type
+
+### 2. Search and Analyze Logs
+
+**When to use**: User wants to search log entries or list log indexes
+
+**Tool sequence**:
+1. `DATADOG_LIST_LOG_INDEXES` - List available log indexes [Optional]
+2. `DATADOG_SEARCH_LOGS` - Search logs with query and filters [Required]
+
+**Key parameters**:
+- `query`: Log search query using Datadog log query syntax
+- `from`: Start time (ISO 8601 or Unix timestamp)
+- `to`: End time (ISO 8601 or Unix timestamp)
+- `sort`: Sort order ('asc' or 'desc')
+- `limit`: Number of log entries to return
+
+**Pitfalls**:
+- Log queries use Datadog's log search syntax: `service:web status:error`
+- Search is limited to retained logs within the configured retention period
+- Large result sets require pagination; check for cursor/page tokens
+- Log indexes control routing and retention; filter by index if known
+
+### 3. Manage Monitors
+
+**When to use**: User wants to create, update, mute, or inspect monitors
+
+**Tool sequence**:
+1. `DATADOG_LIST_MONITORS` - List all monitors with filters [Required]
+2. `DATADOG_GET_MONITOR` - Get specific monitor details [Optional]
+3. `DATADOG_CREATE_MONITOR` - Create a new monitor [Optional]
+4. `DATADOG_UPDATE_MONITOR` - Update monitor configuration [Optional]
+5. `DATADOG_MUTE_MONITOR` - Silence a monitor temporarily [Optional]
+6. `DATADOG_UNMUTE_MONITOR` - Re-enable a muted monitor [Optional]
+
+**Key parameters**:
+- `monitor_id`: Numeric monitor ID
+- `name`: Monitor display name
+- `type`: Monitor type ('metric alert', 'service check', 'log alert', 'query alert', etc.)
+- `query`: Monitor query defining the alert condition
+- `message`: Notification message with @mentions
+- `tags`: Array of tag strings
+- `thresholds`: Alert threshold values (`critical`, `warning`, `ok`)
+
+**Pitfalls**:
+- Monitor `type` must match the query type; mismatches cause creation failures
+- `message` supports @mentions for notifications (e.g., `@slack-channel`, `@pagerduty`)
+- Thresholds vary by monitor type; metric monitors need `critical` at minimum
+- Muting a monitor suppresses notifications but the monitor still evaluates
+- Monitor IDs are numeric integers
+
+### 4. Manage Dashboards
+
+**When to use**: User wants to list, view, update, or delete dashboards
+
+**Tool sequence**:
+1. `DATADOG_LIST_DASHBOARDS` - List all dashboards [Required]
+2. `DATADOG_GET_DASHBOARD` - Get full dashboard definition [Optional]
+3. `DATADOG_UPDATE_DASHBOARD` - Update dashboard layout or widgets [Optional]
+4. `DATADOG_DELETE_DASHBOARD` - Remove a dashboard (irreversible) [Optional]
+
+**Key parameters**:
+- `dashboard_id`: Dashboard identifier string
+- `title`: Dashboard title
+- `layout_type`: 'ordered' (grid) or 'free' (freeform positioning)
+- `widgets`: Array of widget definition objects
+- `description`: Dashboard description
+
+**Pitfalls**:
+- Dashboard IDs are alphanumeric strings (e.g., 'abc-def-ghi'), not numeric
+- `layout_type` cannot be changed after creation; must recreate the dashboard
+- Widget definitions are complex nested objects; get existing dashboard first to understand structure
+- DELETE is permanent; there is no undo
+
+### 5. Create Events and Manage Downtimes
+
+**When to use**: User wants to post events or schedule maintenance downtimes
+
+**Tool sequence**:
+1. `DATADOG_LIST_EVENTS` - List existing events [Optional]
+2. `DATADOG_CREATE_EVENT` - Post a new event [Required]
+3. `DATADOG_CREATE_DOWNTIME` - Schedule a maintenance downtime [Optional]
+
+**Key parameters for events**:
+- `title`: Event title
+- `text`: Event body text (supports markdown)
+- `alert_type`: Event severity ('error', 'warning', 'info', 'success')
+- `tags`: Array of tag strings
+
+**Key parameters for downtimes**:
+- `scope`: Tag scope for the downtime (e.g., `host:web01`)
+- `start`: Start time (Unix epoch)
+- `end`: End time (Unix epoch; omit for indefinite)
+- `message`: Downtime description
+- `monitor_id`: Specific monitor to downtime (optional, omit for scope-based)
+
+**Pitfalls**:
+- Event `text` supports Datadog's markdown format including @mentions
+- Downtimes scope uses tag syntax: `host:web01`, `env:staging`
+- Omitting `end` creates an indefinite downtime; always set an end time for maintenance
+- Downtime `monitor_id` narrows to a single monitor; scope applies to all matching monitors
+
+### 6. Manage Hosts and Traces
+
+**When to use**: User wants to list infrastructure hosts or inspect distributed traces
+
+**Tool sequence**:
+1. `DATADOG_LIST_HOSTS` - List all reporting hosts [Required]
+2. `DATADOG_GET_TRACE_BY_ID` - Get a specific distributed trace [Optional]
+
+**Key parameters**:
+- `filter`: Host search filter string
+- `sort_field`: Sort hosts by field (e.g., 'name', 'apps', 'cpu')
+- `sort_dir`: Sort direction ('asc' or 'desc')
+- `trace_id`: Distributed trace ID for trace lookup
+
+**Pitfalls**:
+- Host list includes all hosts reporting to Datadog within the retention window
+- Trace IDs are long numeric strings; ensure exact match
+- Hosts that stop reporting are retained for a configured period before removal
+
+## Common Patterns
+
+### Monitor Query Syntax
+
+**Metric alerts**:
+```
+avg(last_5m):avg:system.cpu.user{env:prod} > 90
+```
+
+**Log alerts**:
+```
+logs("service:web status:error").index("main").rollup("count").last("5m") > 10
+```
+
+### Tag Filtering
+
+- Tags use `key:value` format: `host:web01`, `env:prod`, `service:api`
+- Multiple tags: `{host:web01,env:prod}` (AND logic)
+- Wildcard: `host:web*`
+
+### Pagination
+
+- Use `page` and `page_size` or offset-based pagination depending on endpoint
+- Check response for total count to determine if more pages exist
+- Continue until all results are retrieved
+
+## Known Pitfalls
+
+**Timestamps**:
+- Most endpoints use Unix epoch seconds (not milliseconds)
+- Some endpoints accept ISO 8601; check tool schema
+- Time ranges should be reasonable (not years of data)
+
+**Query Syntax**:
+- Metric queries: `aggregation:metric{tags}`
+- Log queries: `field:value` pairs
+- Monitor queries vary by type; check Datadog documentation
+
+**Rate Limits**:
+- Datadog API has per-endpoint rate limits
+- Implement backoff on 429 responses
+- Batch operations where possible
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| Query metrics | DATADOG_QUERY_METRICS | query, from, to |
+| List metrics | DATADOG_LIST_METRICS | q |
+| Search logs | DATADOG_SEARCH_LOGS | query, from, to, limit |
+| List log indexes | DATADOG_LIST_LOG_INDEXES | (none) |
+| List monitors | DATADOG_LIST_MONITORS | tags |
+| Get monitor | DATADOG_GET_MONITOR | monitor_id |
+| Create monitor | DATADOG_CREATE_MONITOR | name, type, query, message |
+| Update monitor | DATADOG_UPDATE_MONITOR | monitor_id |
+| Mute monitor | DATADOG_MUTE_MONITOR | monitor_id |
+| Unmute monitor | DATADOG_UNMUTE_MONITOR | monitor_id |
+| List dashboards | DATADOG_LIST_DASHBOARDS | (none) |
+| Get dashboard | DATADOG_GET_DASHBOARD | dashboard_id |
+| Update dashboard | DATADOG_UPDATE_DASHBOARD | dashboard_id, title, widgets |
+| Delete dashboard | DATADOG_DELETE_DASHBOARD | dashboard_id |
+| List events | DATADOG_LIST_EVENTS | start, end |
+| Create event | DATADOG_CREATE_EVENT | title, text, alert_type |
+| Create downtime | DATADOG_CREATE_DOWNTIME | scope, start, end |
+| List hosts | DATADOG_LIST_HOSTS | filter, sort_field |
+| Get trace | DATADOG_GET_TRACE_BY_ID | trace_id |

package/mcp/skills/github-automation/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: github-automation
+description: Automate GitHub repositories, issues, pull requests, branches, CI/CD, and permissions via Rube MCP (Composio). Manage code workflows, review PRs, search code, and handle deployments programmatically.
+requires:
+  mcp: [rube]
+---
+
+# GitHub Automation via Rube MCP
+
+Automate GitHub repository management, issue tracking, pull request workflows, branch operations, and CI/CD through Composio's GitHub toolkit.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active GitHub connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `github`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `github`
+3. If connection is not ACTIVE, follow the returned auth link to complete GitHub OAuth
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Create and Manage Issues
+
+**When to use**: User wants to create, list, or manage GitHub issues
+
+**Tool sequence**:
+1. `GITHUB_LIST_REPOSITORIES_FOR_THE_AUTHENTICATED_USER` - Find target repo if unknown [Prerequisite]
+2. `GITHUB_LIST_REPOSITORY_ISSUES` - List existing issues (includes PRs) [Required]
+3. `GITHUB_CREATE_AN_ISSUE` - Create a new issue [Required]
+4. `GITHUB_CREATE_AN_ISSUE_COMMENT` - Add comments to an issue [Optional]
+5. `GITHUB_SEARCH_ISSUES_AND_PULL_REQUESTS` - Search across repos by keyword [Optional]
+
+**Key parameters**:
+- `owner`: Repository owner (username or org), case-insensitive
+- `repo`: Repository name without .git extension
+- `title`: Issue title (required for creation)
+- `body`: Issue description (supports Markdown)
+- `labels`: Array of label names
+- `assignees`: Array of GitHub usernames
+- `state`: 'open', 'closed', or 'all' for filtering
+
+**Pitfalls**:
+- `GITHUB_LIST_REPOSITORY_ISSUES` returns both issues AND pull requests; check `pull_request` field to distinguish
+- Only users with push access can set assignees, labels, and milestones; they are silently dropped otherwise
+- Pagination: `per_page` max 100; iterate pages until empty
+
+### 2. Manage Pull Requests
+
+**When to use**: User wants to create, review, or merge pull requests
+
+**Tool sequence**:
+1. `GITHUB_FIND_PULL_REQUESTS` - Search and filter PRs [Required]
+2. `GITHUB_GET_A_PULL_REQUEST` - Get detailed PR info including mergeable status [Required]
+3. `GITHUB_LIST_PULL_REQUESTS_FILES` - Review changed files [Optional]
+4. `GITHUB_CREATE_A_PULL_REQUEST` - Create a new PR [Required]
+5. `GITHUB_CREATE_AN_ISSUE_COMMENT` - Post review comments [Optional]
+6. `GITHUB_LIST_CHECK_RUNS_FOR_A_REF` - Verify CI status before merge [Optional]
+7. `GITHUB_MERGE_A_PULL_REQUEST` - Merge after explicit user approval [Required]
+
+**Key parameters**:
+- `head`: Source branch with changes (must exist; for cross-repo: 'username:branch')
+- `base`: Target branch to merge into (e.g., 'main')
+- `title`: PR title (required unless `issue` number provided)
+- `merge_method`: 'merge', 'squash', or 'rebase'
+- `state`: 'open', 'closed', or 'all'
+
+**Pitfalls**:
+- `GITHUB_CREATE_A_PULL_REQUEST` fails with 422 if base/head are invalid, identical, or already merged
+- `GITHUB_MERGE_A_PULL_REQUEST` can be rejected if PR is draft, closed, or branch protection applies
+- Always verify mergeable status with `GITHUB_GET_A_PULL_REQUEST` immediately before merging
+- Require explicit user confirmation before calling MERGE
+
+### 3. Manage Repositories and Branches
+
+**When to use**: User wants to create repos, manage branches, or update repo settings
+
+**Tool sequence**:
+1. `GITHUB_LIST_REPOSITORIES_FOR_THE_AUTHENTICATED_USER` - List user's repos [Required]
+2. `GITHUB_GET_A_REPOSITORY` - Get detailed repo info [Optional]
+3. `GITHUB_CREATE_A_REPOSITORY_FOR_THE_AUTHENTICATED_USER` - Create personal repo [Required]
+4. `GITHUB_CREATE_AN_ORGANIZATION_REPOSITORY` - Create org repo [Alternative]
+5. `GITHUB_LIST_BRANCHES` - List branches [Required]
+6. `GITHUB_CREATE_A_REFERENCE` - Create new branch from SHA [Required]
+7. `GITHUB_UPDATE_A_REPOSITORY` - Update repo settings [Optional]
+
+**Key parameters**:
+- `name`: Repository name
+- `private`: Boolean for visibility
+- `ref`: Full reference path (e.g., 'refs/heads/new-branch')
+- `sha`: Commit SHA to point the new reference to
+- `default_branch`: Default branch name
+
+**Pitfalls**:
+- `GITHUB_CREATE_A_REFERENCE` only creates NEW references; use `GITHUB_UPDATE_A_REFERENCE` for existing ones
+- `ref` must start with 'refs/' and contain at least two slashes
+- `GITHUB_LIST_BRANCHES` paginates via `page`/`per_page`; iterate until empty page
+- `GITHUB_DELETE_A_REPOSITORY` is permanent and irreversible; requires admin privileges
+
+### 4. Search Code and Commits
+
+**When to use**: User wants to find code, files, or commits across repositories
+
+**Tool sequence**:
+1. `GITHUB_SEARCH_CODE` - Search file contents and paths [Required]
+2. `GITHUB_SEARCH_CODE_ALL_PAGES` - Multi-page code search [Alternative]
+3. `GITHUB_SEARCH_COMMITS_BY_AUTHOR` - Search commits by author/date/org [Required]
+4. `GITHUB_LIST_COMMITS` - List commits for a specific repo [Alternative]
+5. `GITHUB_GET_A_COMMIT` - Get detailed commit info [Optional]
+6. `GITHUB_GET_REPOSITORY_CONTENT` - Get file content [Optional]
+
+**Key parameters**:
+- `q`: Search query with qualifiers (`language:python`, `repo:owner/repo`, `extension:js`)
+- `owner`/`repo`: For repo-specific commit listing
+- `author`: Filter by commit author
+- `since`/`until`: ISO 8601 date range for commits
+
+**Pitfalls**:
+- Code search only indexes files under 384KB on default branch
+- Maximum 1000 results returned from code search
+- `GITHUB_SEARCH_COMMITS_BY_AUTHOR` requires keywords in addition to qualifiers; qualifier-only queries are not allowed
+- `GITHUB_LIST_COMMITS` returns 409 on empty repos
+
+### 5. Manage CI/CD and Deployments
+
+**When to use**: User wants to view workflows, check CI status, or manage deployments
+
+**Tool sequence**:
+1. `GITHUB_LIST_REPOSITORY_WORKFLOWS` - List GitHub Actions workflows [Required]
+2. `GITHUB_GET_A_WORKFLOW` - Get workflow details by ID or filename [Optional]
+3. `GITHUB_CREATE_A_WORKFLOW_DISPATCH_EVENT` - Manually trigger a workflow [Required]
+4. `GITHUB_LIST_CHECK_RUNS_FOR_A_REF` - Check CI status for a commit/branch [Required]
+5. `GITHUB_LIST_DEPLOYMENTS` - List deployments [Optional]
+6. `GITHUB_GET_A_DEPLOYMENT_STATUS` - Get deployment status [Optional]
+
+**Key parameters**:
+- `workflow_id`: Numeric ID or filename (e.g., 'ci.yml')
+- `ref`: Git reference (branch/tag) for workflow dispatch
+- `inputs`: JSON string of workflow inputs matching `on.workflow_dispatch.inputs`
+- `environment`: Filter deployments by environment name
+
+**Pitfalls**:
+- `GITHUB_CREATE_A_WORKFLOW_DISPATCH_EVENT` requires the workflow to have `workflow_dispatch` trigger configured
+- Full path `.github/workflows/main.yml` is auto-stripped to just `main.yml`
+- Inputs max 10 key-value pairs; must match workflow's `on.workflow_dispatch.inputs` definitions
+
+### 6. Manage Users and Permissions
+
+**When to use**: User wants to check collaborators, permissions, or branch protection
+
+**Tool sequence**:
+1. `GITHUB_LIST_REPOSITORY_COLLABORATORS` - List repo collaborators [Required]
+2. `GITHUB_GET_REPOSITORY_PERMISSIONS_FOR_A_USER` - Check specific user's access [Optional]
+3. `GITHUB_GET_BRANCH_PROTECTION` - Inspect branch protection rules [Required]
+4. `GITHUB_UPDATE_BRANCH_PROTECTION` - Update protection settings [Optional]
+5. `GITHUB_ADD_A_REPOSITORY_COLLABORATOR` - Add/update collaborator [Optional]
+
+**Key parameters**:
+- `affiliation`: 'outside', 'direct', or 'all' for collaborator filtering
+- `permission`: Filter by 'pull', 'triage', 'push', 'maintain', 'admin'
+- `branch`: Branch name for protection rules
+- `enforce_admins`: Whether protection applies to admins
+
+**Pitfalls**:
+- `GITHUB_GET_BRANCH_PROTECTION` returns 404 for unprotected branches; treat as no protection rules
+- Determine push ability from `permissions.push` or `role_name`, not display labels
+- `GITHUB_LIST_REPOSITORY_COLLABORATORS` paginates; iterate all pages
+- `GITHUB_GET_REPOSITORY_PERMISSIONS_FOR_A_USER` may be inconclusive for non-collaborators
+
+## Common Patterns
+
+### ID Resolution
+- **Repo name -> owner/repo**: `GITHUB_LIST_REPOSITORIES_FOR_THE_AUTHENTICATED_USER`
+- **PR number -> PR details**: `GITHUB_FIND_PULL_REQUESTS` then `GITHUB_GET_A_PULL_REQUEST`
+- **Branch name -> SHA**: `GITHUB_GET_A_BRANCH`
+- **Workflow name -> ID**: `GITHUB_LIST_REPOSITORY_WORKFLOWS`
+
+### Pagination
+All list endpoints use page-based pagination:
+- `page`: Page number (starts at 1)
+- `per_page`: Results per page (max 100)
+- Iterate until response returns fewer results than `per_page`
+
+### Safety
+- Always verify PR mergeable status before merge
+- Require explicit user confirmation for destructive operations (merge, delete)
+- Check CI status with `GITHUB_LIST_CHECK_RUNS_FOR_A_REF` before merging
+
+## Known Pitfalls
+
+- **Issues vs PRs**: `GITHUB_LIST_REPOSITORY_ISSUES` returns both; check `pull_request` field
+- **Pagination limits**: `per_page` max 100; always iterate pages until empty
+- **Branch creation**: `GITHUB_CREATE_A_REFERENCE` fails with 422 if reference already exists
+- **Merge guards**: Merge can fail due to branch protection, failing checks, or draft status
+- **Code search limits**: Only files <384KB on default branch; max 1000 results
+- **Commit search**: Requires search text keywords alongside qualifiers
+- **Destructive actions**: Repo deletion is irreversible; merge cannot be undone
+- **Silent permission drops**: Labels, assignees, milestones silently dropped without push access
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List repos | `GITHUB_LIST_REPOSITORIES_FOR_THE_AUTHENTICATED_USER` | `type`, `sort`, `per_page` |
+| Get repo | `GITHUB_GET_A_REPOSITORY` | `owner`, `repo` |
+| Create issue | `GITHUB_CREATE_AN_ISSUE` | `owner`, `repo`, `title`, `body` |
+| List issues | `GITHUB_LIST_REPOSITORY_ISSUES` | `owner`, `repo`, `state` |
+| Find PRs | `GITHUB_FIND_PULL_REQUESTS` | `repo`, `state`, `author` |
+| Create PR | `GITHUB_CREATE_A_PULL_REQUEST` | `owner`, `repo`, `head`, `base`, `title` |
+| Merge PR | `GITHUB_MERGE_A_PULL_REQUEST` | `owner`, `repo`, `pull_number`, `merge_method` |
+| List branches | `GITHUB_LIST_BRANCHES` | `owner`, `repo` |
+| Create branch | `GITHUB_CREATE_A_REFERENCE` | `owner`, `repo`, `ref`, `sha` |
+| Search code | `GITHUB_SEARCH_CODE` | `q` |
+| List commits | `GITHUB_LIST_COMMITS` | `owner`, `repo`, `author`, `since` |
+| Search commits | `GITHUB_SEARCH_COMMITS_BY_AUTHOR` | `q` |
+| List workflows | `GITHUB_LIST_REPOSITORY_WORKFLOWS` | `owner`, `repo` |
+| Trigger workflow | `GITHUB_CREATE_A_WORKFLOW_DISPATCH_EVENT` | `owner`, `repo`, `workflow_id`, `ref` |
+| Check CI | `GITHUB_LIST_CHECK_RUNS_FOR_A_REF` | `owner`, `repo`, ref |
+| List collaborators | `GITHUB_LIST_REPOSITORY_COLLABORATORS` | `owner`, `repo` |
+| Branch protection | `GITHUB_GET_BRANCH_PROTECTION` | `owner`, `repo`, `branch` |

package/mcp/skills/mcp-builder/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: mcp-builder
+description: MCP (Model Context Protocol) server building principles. Tool design, resource patterns, best practices.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# MCP Builder
+
+> Principles for building MCP servers.
+
+---
+
+## 1. MCP Overview
+
+### What is MCP?
+
+Model Context Protocol - standard for connecting AI systems with external tools and data sources.
+
+### Core Concepts
+
+| Concept | Purpose |
+|---------|---------|
+| **Tools** | Functions AI can call |
+| **Resources** | Data AI can read |
+| **Prompts** | Pre-defined prompt templates |
+
+---
+
+## 2. Server Architecture
+
+### Project Structure
+
+```
+my-mcp-server/
+├── src/
+│   └── index.ts      # Main entry
+├── package.json
+└── tsconfig.json
+```
+
+### Transport Types
+
+| Type | Use |
+|------|-----|
+| **Stdio** | Local, CLI-based |
+| **SSE** | Web-based, streaming |
+| **WebSocket** | Real-time, bidirectional |
+
+---
+
+## 3. Tool Design Principles
+
+### Good Tool Design
+
+| Principle | Description |
+|-----------|-------------|
+| Clear name | Action-oriented (get_weather, create_user) |
+| Single purpose | One thing well |
+| Validated input | Schema with types and descriptions |
+| Structured output | Predictable response format |
+
+### Input Schema Design
+
+| Field | Required? |
+|-------|-----------|
+| Type | Yes - object |
+| Properties | Define each param |
+| Required | List mandatory params |
+| Description | Human-readable |
+
+---
+
+## 4. Resource Patterns
+
+### Resource Types
+
+| Type | Use |
+|------|-----|
+| Static | Fixed data (config, docs) |
+| Dynamic | Generated on request |
+| Template | URI with parameters |
+
+### URI Patterns
+
+| Pattern | Example |
+|---------|---------|
+| Fixed | `docs://readme` |
+| Parameterized | `users://{userId}` |
+| Collection | `files://project/*` |
+
+---
+
+## 5. Error Handling
+
+### Error Types
+
+| Situation | Response |
+|-----------|----------|
+| Invalid params | Validation error message |
+| Not found | Clear "not found" |
+| Server error | Generic error, log details |
+
+### Best Practices
+
+- Return structured errors
+- Don't expose internal details
+- Log for debugging
+- Provide actionable messages
+
+---
+
+## 6. Multimodal Handling
+
+### Supported Types
+
+| Type | Encoding |
+|------|----------|
+| Text | Plain text |
+| Images | Base64 + MIME type |
+| Files | Base64 + MIME type |
+
+---
+
+## 7. Security Principles
+
+### Input Validation
+
+- Validate all tool inputs
+- Sanitize user-provided data
+- Limit resource access
+
+### API Keys
+
+- Use environment variables
+- Don't log secrets
+- Validate permissions
+
+---
+
+## 8. Configuration
+
+### Claude Desktop Config
+
+| Field | Purpose |
+|-------|---------|
+| command | Executable to run |
+| args | Command arguments |
+| env | Environment variables |
+
+---
+
+## 9. Testing
+
+### Test Categories
+
+| Type | Focus |
+|------|-------|
+| Unit | Tool logic |
+| Integration | Full server |
+| Contract | Schema validation |
+
+---
+
+## 10. Best Practices Checklist
+
+- [ ] Clear, action-oriented tool names
+- [ ] Complete input schemas with descriptions
+- [ ] Structured JSON output
+- [ ] Error handling for all cases
+- [ ] Input validation
+- [ ] Environment-based configuration
+- [ ] Logging for debugging
+
+---
+
+> **Remember:** MCP tools should be simple, focused, and well-documented. The AI relies on descriptions to use them correctly.