@cubis/foundry 0.3.34 → 0.3.36

package/mcp/powers/postman/oneup-design/steering/spacing.md

@@ -1,84 +0,0 @@
-# OneSpacing Tokens
-
-| Token | Value | Usage |
-|-------|-------|-------|
-| xs4 | 1 | `SizedBox(height: OneSpacing.xs4)` |
-| xs3 | 2 | `SizedBox(height: OneSpacing.xs3)` |
-| xs2 | 4 | `SizedBox(height: OneSpacing.xs2)` |
-| n5 | 5 | `SizedBox(height: OneSpacing.n5)` |
-| xs | 6 | `SizedBox(height: OneSpacing.xs)` |
-| sm | 8 | `SizedBox(height: OneSpacing.sm)` |
-| n10 | 10 | `SizedBox(height: OneSpacing.n10)` |
-| md | 12 | `SizedBox(height: OneSpacing.md)` |
-| lg | 16 | `SizedBox(height: OneSpacing.lg)` |
-| xl | 20 | `SizedBox(height: OneSpacing.xl)` |
-| xl2 | 24 | `SizedBox(height: OneSpacing.xl2)` |
-| n28 | 28 | `SizedBox(height: OneSpacing.n28)` |
-| xl3 | 32 | `SizedBox(height: OneSpacing.xl3)` |
-| xl4 | 40 | `SizedBox(height: OneSpacing.xl4)` |
-| xl5 | 48 | `SizedBox(height: OneSpacing.xl5)` |
-| xl6 | 64 | `SizedBox(height: OneSpacing.xl6)` |
-
-# OnePadding Presets
-
-| Preset | Value | Use Case |
-|--------|-------|----------|
-| screenHorizontal | h: 20 | Screen body padding |
-| screenVertical | v: 20 | Screen vertical |
-| screenAll | all: 20 | Full screen padding |
-| cardAll | all: 16 | Card internal padding |
-| cardHorizontal | h: 16 | Card horizontal |
-| cardVertical | v: 12 | Card vertical |
-| listItem | h: 16, v: 12 | List item padding |
-| button | h: 24, v: 12 | Button internal |
-| formField | bottom: 16 | Form field gap |
-| section | bottom: 24 | Section gap |
-| xs | all: 4 | Extra small |
-| sm | all: 8 | Small |
-| md | all: 12 | Medium |
-| lg | all: 16 | Large |
-| xl | all: 20 | Extra large |
-| xl2 | all: 24 | 2X large |
-| horizontalXs-Xl | h: 4-20 | Horizontal only |
-| verticalXs-Xl | v: 4-20 | Vertical only |
-
-## Custom Padding
-```dart
-OnePadding.custom(left: OneSpacing.sm, bottom: OneSpacing.lg)
-OnePadding.symmetric(horizontal: OneSpacing.lg, vertical: OneSpacing.md)
-OnePadding.only(top: OneSpacing.xl)
-```
-
-# OneRadius Tokens
-
-| Token | Value | Usage |
-|-------|-------|-------|
-| xs4 | 1 | `BorderRadius.circular(OneRadius.xs4)` |
-| xs | 4 | `BorderRadius.circular(OneRadius.xs)` |
-| sm | 6 | `BorderRadius.circular(OneRadius.sm)` |
-| md | 8 | `BorderRadius.circular(OneRadius.md)` |
-| lg | 12 | `BorderRadius.circular(OneRadius.lg)` |
-| xl | 16 | `BorderRadius.circular(OneRadius.xl)` |
-| xl2 | 20 | `BorderRadius.circular(OneRadius.xl2)` |
-| xl3 | 24 | `BorderRadius.circular(OneRadius.xl3)` |
-| full | 9999 | Pill shape |
-
-## Pre-built BorderRadius
-```dart
-OneRadius.radiusXs   // BorderRadius.circular(4)
-OneRadius.radiusSm   // BorderRadius.circular(6)
-OneRadius.radiusMd   // BorderRadius.circular(8)
-OneRadius.radiusLg   // BorderRadius.circular(12)
-OneRadius.radiusXl   // BorderRadius.circular(16)
-OneRadius.radiusFull // BorderRadius.circular(9999)
-```
-
-# Forbidden Patterns
-
-```dart
-// ❌ NEVER USE RAW VALUES
-SizedBox(height: 16)                    // Use OneSpacing.lg
-EdgeInsets.all(12)                      // Use OnePadding.md
-EdgeInsets.symmetric(horizontal: 20)    // Use OnePadding.screenHorizontal
-BorderRadius.circular(8)                // Use OneRadius.md
-```

package/mcp/powers/postman/openapi-docs/POWER.md

@@ -1,78 +0,0 @@
----
-name: openapi-docs
-displayName: OpenAPI Docs & Stoplight UI
-description:
-  Use when writing or updating OpenAPI specifications, defining request/response
-  schemas, or configuring Stoplight Elements (Swagger-style) documentation UI.
-keywords:
-  - openapi
-  - api docs
-  - swagger ui
-  - stoplight
-  - elements
-  - documentation
-author: OneUp
----
-
-# OpenAPI Docs & Stoplight UI
-
-## Overview
-
-API documentation specialist who produces clean, consistent OpenAPI 3.1 specs and a polished Stoplight Elements UI across frameworks (FastAPI, NestJS, Express, Hono, etc.).
-
-## Role Definition
-
-You are a technical writer and API designer. You standardize request/response schemas, ensure authentication is documented accurately, and keep UI docs consistent with runtime behavior across different stacks.
-
-## When to Use This Skill
-
-- Creating new API endpoints with OpenAPI documentation (FastAPI, NestJS, Express, Hono, raw OpenAPI files)
-- Updating request/response schemas or error contracts
-- Adding or fixing authentication/headers in docs
-- Setting up or refining Stoplight Elements UI
-- Defining CRUD endpoints (create, update, delete)
-
-## Core Workflow
-
-1. **Inventory** - Identify endpoints, auth headers, and response types
-2. **Schemas** - Define reusable schemas and examples
-3. **Operations** - Document create/update/delete with standard responses
-4. **Errors** - Add consistent error responses for all routes
-5. **UI** - Wire Stoplight Elements to the OpenAPI spec
-
-## Available Steering Files
-
-| Topic             | Reference                         | Load When                          |
-| ----------------- | --------------------------------- | ---------------------------------- |
-| OpenAPI Checklist | steering/openapi-checklist.md     | Before writing or updating specs   |
-| CRUD Templates    | steering/crud-templates.md        | Adding create/update/delete routes |
-| Stoplight UI      | steering/stoplight-ui.md          | Configuring or styling docs UI     |
-| FastAPI           | steering/framework-fastapi.md     | FastAPI-specific documentation     |
-| NestJS            | steering/framework-nestjs.md      | NestJS Swagger integration         |
-| Express           | steering/framework-express.md     | Express spec-first or code-first   |
-| Raw OpenAPI       | steering/framework-raw-openapi.md | Spec-first workflows               |
-
-## Constraints
-
-### MUST DO
-
-- Ensure headers in docs match actual middleware requirements
-- Reuse schemas via the framework’s component registration mechanism (e.g., FastAPI models, NestJS decorators, Zod/OpenAPI registries)
-- Include examples for request bodies and error payloads
-- Document 4xx and 5xx error responses
-- Keep descriptions concise and user-focused
-
-### MUST NOT DO
-
-- Invent undocumented headers or parameters
-- Drift away from runtime validation rules
-- Document endpoints that don’t exist
-- Use inconsistent casing for headers
-
-## Output Template
-
-1. Summary of changes
-2. Updated schemas and examples
-3. Updated endpoints (create/update/delete)
-4. Stoplight UI status and URL
-5. Verification notes

package/mcp/powers/postman/openapi-docs/SKILL.md

@@ -1,68 +0,0 @@
----
-name: "openapi-docs"
-description: "Use when writing or updating OpenAPI specifications, defining request/response schemas, or configuring Stoplight Elements (Swagger-style) documentation UI."
----
-
-
-# OpenAPI Docs & Stoplight UI
-
-## Overview
-
-API documentation specialist who produces clean, consistent OpenAPI 3.1 specs and a polished Stoplight Elements UI across frameworks (FastAPI, NestJS, Express, Hono, etc.).
-
-## Role Definition
-
-You are a technical writer and API designer. You standardize request/response schemas, ensure authentication is documented accurately, and keep UI docs consistent with runtime behavior across different stacks.
-
-## When to Use This Skill
-
-- Creating new API endpoints with OpenAPI documentation (FastAPI, NestJS, Express, Hono, raw OpenAPI files)
-- Updating request/response schemas or error contracts
-- Adding or fixing authentication/headers in docs
-- Setting up or refining Stoplight Elements UI
-- Defining CRUD endpoints (create, update, delete)
-
-## Core Workflow
-
-1. **Inventory** - Identify endpoints, auth headers, and response types
-2. **Schemas** - Define reusable schemas and examples
-3. **Operations** - Document create/update/delete with standard responses
-4. **Errors** - Add consistent error responses for all routes
-5. **UI** - Wire Stoplight Elements to the OpenAPI spec
-
-## Available Steering Files
-
-| Topic             | Reference                         | Load When                          |
-| ----------------- | --------------------------------- | ---------------------------------- |
-| OpenAPI Checklist | steering/openapi-checklist.md     | Before writing or updating specs   |
-| CRUD Templates    | steering/crud-templates.md        | Adding create/update/delete routes |
-| Stoplight UI      | steering/stoplight-ui.md          | Configuring or styling docs UI     |
-| FastAPI           | steering/framework-fastapi.md     | FastAPI-specific documentation     |
-| NestJS            | steering/framework-nestjs.md      | NestJS Swagger integration         |
-| Express           | steering/framework-express.md     | Express spec-first or code-first   |
-| Raw OpenAPI       | steering/framework-raw-openapi.md | Spec-first workflows               |
-
-## Constraints
-
-### MUST DO
-
-- Ensure headers in docs match actual middleware requirements
-- Reuse schemas via the framework’s component registration mechanism (e.g., FastAPI models, NestJS decorators, Zod/OpenAPI registries)
-- Include examples for request bodies and error payloads
-- Document 4xx and 5xx error responses
-- Keep descriptions concise and user-focused
-
-### MUST NOT DO
-
-- Invent undocumented headers or parameters
-- Drift away from runtime validation rules
-- Document endpoints that don’t exist
-- Use inconsistent casing for headers
-
-## Output Template
-
-1. Summary of changes
-2. Updated schemas and examples
-3. Updated endpoints (create/update/delete)
-4. Stoplight UI status and URL
-5. Verification notes

package/mcp/powers/postman/openapi-docs/steering/crud-templates.md

@@ -1,43 +0,0 @@
-# CRUD Templates (Create / Update / Delete)
-
-## Create (POST)
-
-- `summary`: Create <resource>
-- `request.body`:
-  - `application/json` schema with required fields
-  - example payload
-- Responses:
-  - `201` with created resource schema
-  - `400` validation error
-  - `401` missing auth
-  - `403` forbidden
-  - `500` server error
-
-## Update (PUT/PATCH)
-
-- `summary`: Update <resource>
-- `request.params`: `{ id }`
-- `request.body`: optional fields for update
-- Responses:
-  - `200` with updated resource schema
-  - `400` validation error
-  - `401` missing auth
-  - `403` forbidden
-  - `404` not found
-  - `500` server error
-
-## Delete (DELETE)
-
-- `summary`: Delete <resource>
-- `request.params`: `{ id }`
-- Responses:
-  - `204` no content (or `200` with confirmation schema)
-  - `401` missing auth
-  - `403` forbidden
-  - `404` not found
-  - `500` server error
-
-## Notes
-
-- Ensure `request.headers` includes all required auth headers
-- Use shared `ErrorResponse` schema for errors

package/mcp/powers/postman/openapi-docs/steering/framework-express.md

@@ -1,19 +0,0 @@
-# Express OpenAPI Guidance
-
-## Core Patterns
-
-- Maintain a source OpenAPI file (YAML/JSON) or generate via schema tools
-- Validate requests with a middleware (zod, joi, ajv)
-- Ensure validation and docs stay in sync
-
-## Options
-
-- Code-first: Zod/OpenAPI registry or tsoa
-- Spec-first: Handwritten OpenAPI with request validation middleware
-
-## Example Checklist
-
-- Centralize schemas for reuse
-- Add standard error responses across routes
-- Document auth headers explicitly
-- Serve `/openapi.json` and Stoplight UI at `/docs`

package/mcp/powers/postman/openapi-docs/steering/framework-fastapi.md

@@ -1,20 +0,0 @@
-# FastAPI OpenAPI Guidance
-
-## Core Patterns
-
-- Use Pydantic models for request/response schemas
-- Use `response_model` for output typing and docs
-- Use `status_code` on route decorators
-- Use dependency injection for auth headers
-
-## Example Checklist
-
-- Define `BaseModel` for request/response
-- Add examples via `Field(..., example=...)`
-- Document security scheme with `HTTPBearer` or `APIKeyHeader`
-- Add tags on routes for grouping
-
-## Notes
-
-- FastAPI auto-generates OpenAPI 3.1 in recent versions; verify version
-- Use `openapi_url` and `docs_url` to expose spec and UI routes

package/mcp/powers/postman/openapi-docs/steering/framework-nestjs.md

@@ -1,20 +0,0 @@
-# NestJS OpenAPI Guidance
-
-## Core Patterns
-
-- Use `@nestjs/swagger` decorators for schemas and routes
-- Use DTO classes with `@ApiProperty()`
-- Set `@ApiTags()` per controller
-- Use `@ApiBearerAuth()` or `@ApiSecurity()` for API keys
-
-## Example Checklist
-
-- Create DTOs for create/update responses
-- Add `@ApiResponse()` for 200/201/400/401/403/404/500
-- Use `@ApiHeader()` for required headers
-- Generate spec via `SwaggerModule.createDocument()`
-
-## Notes
-
-- Keep DTO validation (class-validator) aligned with docs
-- Export `/openapi.json` and mount UI (Stoplight or Swagger)

package/mcp/powers/postman/openapi-docs/steering/framework-raw-openapi.md

@@ -1,14 +0,0 @@
-# Raw OpenAPI (Spec-First) Guidance
-
-## Core Patterns
-
-- Keep a single `openapi.yaml` or `openapi.json`
-- Reuse components for schemas and security
-- Validate requests using an OpenAPI-aware validator
-
-## Example Checklist
-
-- Define tags and operationIds for all endpoints
-- Use consistent error schema across operations
-- Add examples for request/response bodies
-- Expose spec and Stoplight UI endpoints

package/mcp/powers/postman/openapi-docs/steering/openapi-checklist.md

@@ -1,33 +0,0 @@
-# OpenAPI Checklist (3.1)
-
-## Spec Metadata
-
-- `openapi: 3.1.0`
-- `info`: title, version, description, contact
-- `servers`: local + staging/prod when available
-- `tags`: used by all documented routes
-
-## Security & Headers
-
-- Add `components.securitySchemes` for auth headers
-- Use `security` at global or route level
-- All required headers appear in `request.headers`
-- Header keys are lowercase
-
-## Schemas
-
-- Use the framework’s component registration mechanism (FastAPI Pydantic models, NestJS `@ApiProperty`, Express+zod/openapi registry, etc.)
-- Provide examples for request/response schemas
-- Prefer shared schemas for errors
-
-## Operations
-
-- `summary` and `description` on every operation
-- Responses: `200/201`, plus `400/401/403/404/500` as appropriate
-- `request.body.required: true` if Content-Type is mandatory
-
-## Consistency
-
-- Types and descriptions match actual validation
-- IDs and formats align with persistence (UUID vs ObjectId)
-- No unused tags or components

package/mcp/powers/postman/openapi-docs/steering/stoplight-ui.md

@@ -1,21 +0,0 @@
-# Stoplight Elements UI
-
-## Standard Setup (Web Component)
-
-- Include:
-  - `https://unpkg.com/@stoplight/elements/styles.min.css`
-  - `https://unpkg.com/@stoplight/elements/web-components.min.js`
-- Embed:
-  - `<elements-api apiDescriptionUrl="/openapi.json" router="hash" layout="sidebar" />`
-
-## Recommended Options
-
-- `router="hash"` for static hosting
-- `layout="sidebar"` for readable nav
-- `tryItCredentialsPolicy="include"` when auth cookies or credentials are needed
-
-## Verification
-
-- UI loads and shows all tags
-- Try-it panel works for secured endpoints
-- Schemas and examples render correctly

package/mcp/powers/postman/steering/steering.md

@@ -1,26 +0,0 @@
----
-inclusion: always
----
-
-# Generate APIs from a Collection
-- A Collection ID is required
-- Also get the workspace ID and the local environment ID. Save all the IDs in a .postman.json file. Create it if it doesn't exist.
-- Generate sample data for the APIs
-- Do not generate additional pages or documentation
-- Do not attempt to run the server after generations
-
-# Create a workspace and collection from the API
-- Read the code of the API
-- Create a workspace
-- Create a collection. Add tests as post-request scripts to all request items in the collection
-- Create a local environment
-- Save all the IDs in a .postman.json file. Create it if it doesn't exist.
-
-# Test/Run Collections
-- You are not allowed to use curl or any other API clients except Postman.
-- A Collection ID is required
-- Read the .postman.json file if it exists.
-- Use the environment for local testing if it exists. An Environment ID is required
-- The server must be running first
-- After running, display a summary of the results and a breakdown by endpoint
-- If any endpoint is failing, offer to investigate and fix the error

package/mcp/powers/sentry-automation/POWER.md

@@ -1,235 +0,0 @@
-````markdown
----
-inclusion: manual
-name: sentry-automation
-description: "Automate Sentry tasks via Rube MCP (Composio): manage issues/events, configure alerts, track releases, monitor projects and teams. Always search tools first for current schemas."
-requires:
-  mcp: [rube]
----
-
-# Sentry Automation via Rube MCP
-
-Automate Sentry error tracking and monitoring operations through Composio's Sentry toolkit via Rube MCP.
-
-## Prerequisites
-
-- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
-- Active Sentry connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `sentry`
-- 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 `sentry`
-3. If connection is not ACTIVE, follow the returned auth link to complete Sentry OAuth
-4. Confirm connection status shows ACTIVE before running any workflows
-
-## Core Workflows
-
-### 1. Investigate Issues
-
-**When to use**: User wants to find, inspect, or triage error issues
-
-**Tool sequence**:
-1. `SENTRY_LIST_AN_ORGANIZATIONS_ISSUES` - List issues across the organization [Required]
-2. `SENTRY_GET_ORGANIZATION_ISSUE_DETAILS` - Get detailed info on a specific issue [Optional]
-3. `SENTRY_LIST_AN_ISSUES_EVENTS` - View individual error events for an issue [Optional]
-4. `SENTRY_RETRIEVE_AN_ISSUE_EVENT` - Get full event details with stack trace [Optional]
-5. `SENTRY_RETRIEVE_ISSUE_TAG_DETAILS` - Inspect tag distribution for an issue [Optional]
-
-**Key parameters**:
-- `organization_id_or_slug`: Organization identifier
-- `issue_id`: Numeric issue ID
-- `query`: Search query (e.g., `is:unresolved`, `assigned:me`, `browser:Chrome`)
-- `sort`: Sort order (`date`, `new`, `freq`, `priority`)
-- `statsPeriod`: Time window for stats (`24h`, `14d`, etc.)
-
-**Pitfalls**:
-- `organization_id_or_slug` is the org slug (e.g., 'my-org'), not the display name
-- Issue IDs are numeric; do not confuse with event IDs which are UUIDs
-- Query syntax uses Sentry's search format: `is:unresolved`, `assigned:me`, `!has:release`
-- Events within an issue can have different stack traces; inspect individual events for details
-
-### 2. Manage Project Issues
-
-**When to use**: User wants to view issues scoped to a specific project
-
-**Tool sequence**:
-1. `SENTRY_RETRIEVE_ORGANIZATION_PROJECTS` - List projects to find project slug [Prerequisite]
-2. `SENTRY_RETRIEVE_PROJECT_ISSUES_LIST` - List issues for a specific project [Required]
-3. `SENTRY_RETRIEVE_ISSUE_EVENTS_BY_ID` - Get events for a specific issue [Optional]
-
-**Key parameters**:
-- `organization_id_or_slug`: Organization identifier
-- `project_id_or_slug`: Project identifier
-- `query`: Search filter string
-- `statsPeriod`: Stats time window
-
-**Pitfalls**:
-- Project slugs are different from project display names
-- Always resolve project names to slugs via RETRIEVE_ORGANIZATION_PROJECTS first
-- Project-scoped issue lists may have different pagination than org-scoped lists
-
-### 3. Configure Alert Rules
-
-**When to use**: User wants to create or manage alert rules for a project
-
-**Tool sequence**:
-1. `SENTRY_RETRIEVE_ORGANIZATION_PROJECTS` - Find project for the alert [Prerequisite]
-2. `SENTRY_RETRIEVE_PROJECT_RULES_BY_ORG_AND_PROJECT_ID` - List existing rules [Optional]
-3. `SENTRY_CREATE_PROJECT_RULE_FOR_ALERTS` - Create a new alert rule [Required]
-4. `SENTRY_CREATE_ORGANIZATION_ALERT_RULE` - Create org-level metric alert [Alternative]
-5. `SENTRY_UPDATE_ORGANIZATION_ALERT_RULES` - Update existing alert rules [Optional]
-6. `SENTRY_RETRIEVE_ALERT_RULE_DETAILS` - Inspect specific alert rule [Optional]
-7. `SENTRY_GET_PROJECT_RULE_DETAILS` - Get project-level rule details [Optional]
-
-**Key parameters**:
-- `name`: Alert rule name
-- `conditions`: Array of trigger conditions
-- `actions`: Array of actions to perform when triggered
-- `filters`: Array of event filters
-- `frequency`: How often to trigger (in minutes)
-- `actionMatch`: 'all', 'any', or 'none' for condition matching
-
-**Pitfalls**:
-- Project-level rules (CREATE_PROJECT_RULE) and org-level metric alerts (CREATE_ORGANIZATION_ALERT_RULE) are different
-- Conditions, actions, and filters use specific JSON schemas; check Sentry docs for valid types
-- `frequency` is in minutes; setting too low causes alert fatigue
-- `actionMatch` defaults may vary; explicitly set to avoid unexpected behavior
-
-### 4. Manage Releases
-
-**When to use**: User wants to create, track, or manage release versions
-
-**Tool sequence**:
-1. `SENTRY_LIST_ORGANIZATION_RELEASES` - List existing releases [Optional]
-2. `SENTRY_CREATE_RELEASE_FOR_ORGANIZATION` - Create a new release [Required]
-3. `SENTRY_UPDATE_RELEASE_DETAILS_FOR_ORGANIZATION` - Update release metadata [Optional]
-4. `SENTRY_CREATE_RELEASE_DEPLOY_FOR_ORG` - Record a deployment for a release [Optional]
-5. `SENTRY_UPLOAD_RELEASE_FILE_TO_ORGANIZATION` - Upload source maps or files [Optional]
-
-**Key parameters**:
-- `version`: Release version string (e.g., '1.0.0', commit SHA)
-- `projects`: Array of project slugs this release belongs to
-- `dateReleased`: Release timestamp (ISO 8601)
-- `environment`: Deployment environment name (e.g., 'production', 'staging')
-
-**Pitfalls**:
-- Release versions must be unique within an organization
-- Releases can span multiple projects; use the `projects` array
-- Deploying a release is separate from creating it; use CREATE_RELEASE_DEPLOY
-- Source map uploads require the release to exist first
-
-### 5. Monitor Organization and Teams
-
-**When to use**: User wants to view org structure, teams, or member lists
-
-**Tool sequence**:
-1. `SENTRY_GET_ORGANIZATION_DETAILS` or `SENTRY_GET_ORGANIZATION_BY_ID_OR_SLUG` - Get org info [Required]
-2. `SENTRY_LIST_TEAMS_IN_ORGANIZATION` - List all teams [Optional]
-3. `SENTRY_LIST_ORGANIZATION_MEMBERS` - List org members [Optional]
-4. `SENTRY_GET_PROJECT_LIST` - List all accessible projects [Optional]
-
-**Key parameters**:
-- `organization_id_or_slug`: Organization identifier
-- `cursor`: Pagination cursor for large result sets
-
-**Pitfalls**:
-- Organization slugs are URL-safe identifiers, not display names
-- Member lists may be paginated; follow cursor pagination
-- Team and member visibility depends on the authenticated user's permissions
-
-### 6. Manage Monitors (Cron Monitoring)
-
-**When to use**: User wants to update cron job monitoring configuration
-
-**Tool sequence**:
-1. `SENTRY_UPDATE_A_MONITOR` - Update monitor configuration [Required]
-
-**Key parameters**:
-- `organization_id_or_slug`: Organization identifier
-- `monitor_id_or_slug`: Monitor identifier
-- `name`: Monitor display name
-- `schedule`: Cron schedule expression or interval
-- `checkin_margin`: Grace period in minutes for late check-ins
-- `max_runtime`: Maximum expected runtime in minutes
-
-**Pitfalls**:
-- Monitor slugs are auto-generated from the name; use slug for API calls
-- Schedule changes take effect immediately
-- Missing check-ins trigger alerts after the margin period
-
-## Common Patterns
-
-### ID Resolution
-
-**Organization name -> Slug**:
-```
-1. Call SENTRY_GET_ORGANIZATION_DETAILS
-2. Extract slug field from response
-```
-
-**Project name -> Slug**:
-```
-1. Call SENTRY_RETRIEVE_ORGANIZATION_PROJECTS
-2. Find project by name, extract slug
-```
-
-### Pagination
-
-- Sentry uses cursor-based pagination with `Link` headers
-- Check response for cursor values
-- Pass cursor in next request until no more pages
-
-### Search Query Syntax
-
-- `is:unresolved` - Unresolved issues
-- `is:resolved` - Resolved issues
-- `assigned:me` - Assigned to current user
-- `assigned:team-slug` - Assigned to a team
-- `!has:release` - Issues without a release
-- `first-release:1.0.0` - Issues first seen in release
-- `times-seen:>100` - Seen more than 100 times
-- `browser:Chrome` - Filter by browser tag
-
-## Known Pitfalls
-
-**ID Formats**:
-- Organization: use slug (e.g., 'my-org'), not display name
-- Project: use slug (e.g., 'my-project'), not display name
-- Issue IDs: numeric integers
-- Event IDs: UUIDs (32-char hex strings)
-
-**Permissions**:
-- API token scopes must match the operations being performed
-- Organization-level operations require org-level permissions
-- Project-level operations require project access
-
-**Rate Limits**:
-- Sentry enforces per-organization rate limits
-- Implement backoff on 429 responses
-- Bulk operations should be staggered
-
-## Quick Reference
-
-| Task | Tool Slug | Key Params |
-|------|-----------|------------|
-| List org issues | SENTRY_LIST_AN_ORGANIZATIONS_ISSUES | organization_id_or_slug, query |
-| Get issue details | SENTRY_GET_ORGANIZATION_ISSUE_DETAILS | organization_id_or_slug, issue_id |
-| List issue events | SENTRY_LIST_AN_ISSUES_EVENTS | issue_id |
-| Get event details | SENTRY_RETRIEVE_AN_ISSUE_EVENT | organization_id_or_slug, event_id |
-| List project issues | SENTRY_RETRIEVE_PROJECT_ISSUES_LIST | organization_id_or_slug, project_id_or_slug |
-| List projects | SENTRY_RETRIEVE_ORGANIZATION_PROJECTS | organization_id_or_slug |
-| Get org details | SENTRY_GET_ORGANIZATION_DETAILS | organization_id_or_slug |
-| List teams | SENTRY_LIST_TEAMS_IN_ORGANIZATION | organization_id_or_slug |
-| List members | SENTRY_LIST_ORGANIZATION_MEMBERS | organization_id_or_slug |
-| Create alert rule | SENTRY_CREATE_PROJECT_RULE_FOR_ALERTS | organization_id_or_slug, project_id_or_slug |
-| Create metric alert | SENTRY_CREATE_ORGANIZATION_ALERT_RULE | organization_id_or_slug |
-| Create release | SENTRY_CREATE_RELEASE_FOR_ORGANIZATION | organization_id_or_slug, version |
-| Deploy release | SENTRY_CREATE_RELEASE_DEPLOY_FOR_ORG | organization_id_or_slug, version |
-| List releases | SENTRY_LIST_ORGANIZATION_RELEASES | organization_id_or_slug |
-| Update monitor | SENTRY_UPDATE_A_MONITOR | organization_id_or_slug, monitor_id_or_slug |
-````