diff --git a/README.md b/README.md index 6a0c6cbd..b813a6f7 100644 --- a/README.md +++ b/README.md @@ -23,7 +23,7 @@ Documentation is available at https://kiro.dev/docs/powers/ --- ### aws-amplify -**Build full-stack apps with AWS Amplify** - Build and extend full-stack applications with AWS Amplify Gen 2 using type-safe TypeScript, guided workflows, and best practices. Covers authentication, data models, storage, serverless functions, AI/ML integration, and deployment to sandbox and production. +**Build full-stack apps with AWS Amplify Gen2** - Build and extend full-stack applications with AWS Amplify Gen 2 using type-safe TypeScript, guided workflows, and best practices. Covers authentication, data models, storage, serverless functions, AI/ML integration, and deployment to sandbox and production. **MCP Servers:** aws-mcp @@ -46,7 +46,7 @@ Documentation is available at https://kiro.dev/docs/powers/ ### aws-healthomics **AWS HealthOmics** - Create, migrate, run, debug and optimize genomics workflows in AWS HealthOmics. Supports WDL, Nextflow, and CWL workflow languages. -**MCP Servers:** awslabs.aws-healthomics-mcp-server +**MCP Servers:** aws-healthomics --- @@ -95,7 +95,7 @@ Documentation is available at https://kiro.dev/docs/powers/ ### aws-transform **AWS Transform** - Migrate, modernize, and upgrade codebases: .NET Framework to .NET 8/10, mainframe COBOL to Java, VMware VMs to EC2, SQL Server/Oracle/MySQL to Aurora, and Java/Python/Node.js version upgrades or AWS SDK migrations. Assess, plan, and execute code transformations from your IDE. -**MCP Servers:** None +**MCP Servers:** aws-transform-mcp --- @@ -120,17 +120,10 @@ Documentation is available at https://kiro.dev/docs/powers/ --- -### cloudwatch-application-signals -**[DEPRECATED] Amazon CloudWatch Application Signals** - This power has been merged into the AWS Observability power. We recommend installing the AWS Observability power for a more comprehensive monitoring experience. - -**MCP Servers:** awslabs.cloudwatch-applicationsignals-mcp-server - ---- - ### databricks -**Databricks AI Dev Kit** - Comprehensive Databricks development toolkit with 44 MCP tools (180+ operations) and expert guidance for building data pipelines, ML workflows, dashboards, jobs, and applications on the Databricks platform across AWS, Azure, and GCP. +**Databricks AI Dev Kit** - Comprehensive Databricks development toolkit with expert guidance for building data pipelines, ML workflows, dashboards, jobs, and applications on the Databricks platform, plus an optional MCP server adding 44 live tools (180+ operations). -**MCP Servers:** databricks (ai-dev-kit local MCP server) +**MCP Servers:** databricks (optional, ai-dev-kit local MCP server) --- @@ -144,7 +137,14 @@ Documentation is available at https://kiro.dev/docs/powers/ ### dynatrace **Dynatrace Observability** - Query logs, metrics, traces, problems, and Kubernetes events from Dynatrace using DQL (Dynatrace Query Language) and Davis AI. -**MCP Servers:** dynatrace-mcp-server +**MCP Servers:** dynatrace + +--- + +### kiro-support +**Kiro Support** - File and manage AWS Support cases for Kiro issues directly from the IDE. Collects diagnostics and verifies Support API access first, with a ready-to-send admin request when permissions are missing. + +**MCP Servers:** awslabs.aws-support-mcp-server, aws-mcp --- @@ -165,7 +165,7 @@ Documentation is available at https://kiro.dev/docs/powers/ ### neon **Build a database with Neon** - Serverless Postgres with database branching, autoscaling, and scale-to-zero - perfect for modern development workflows. -**MCP Servers:** neon +**MCP Servers:** Neon --- @@ -177,7 +177,7 @@ Documentation is available at https://kiro.dev/docs/powers/ --- ### power-builder -**Power Builder** - Complete guide for building and testing new Kiro powers with templates, best practices, and validation. +**Power Builder** - Create new Kiro powers using the Agent Plugins specification, or migrate existing POWER.md-based powers to the agent-plugins standard. **MCP Servers:** None (Knowledge Base Power) @@ -198,7 +198,7 @@ Documentation is available at https://kiro.dev/docs/powers/ --- ### stackgen -**Aiden for InfraOps** - Design, manage, and deploy cloud infrastructure with StackGen - create appstacks, manage resources, configure environments, and push IaC to Git. Supports AWS, Azure, and GCP. +**Aiden for InfraOps** - Build, operate, observe, and remediate cloud infrastructure with Aiden - create appstacks, manage resources, configure environments, and push IaC to Git. Supports AWS, Azure, and GCP, plus deployment runners and ServiceNow integration. **MCP Servers:** stackgen (CLI stdio) @@ -211,13 +211,6 @@ Documentation is available at https://kiro.dev/docs/powers/ --- -### stripe -**Stripe Payments** - Build payment integrations with Stripe - accept payments, manage subscriptions, handle billing, and process refunds. - -**MCP Servers:** stripe - ---- - ### terraform **Deploy infrastructure with Terraform** - Build and manage Infrastructure as Code with Terraform - access registry providers, modules, policies, and HCP Terraform workflow management. diff --git a/cloudwatch-application-signals/POWER.md b/cloudwatch-application-signals/POWER.md deleted file mode 100644 index e3a63268..00000000 --- a/cloudwatch-application-signals/POWER.md +++ /dev/null @@ -1,381 +0,0 @@ ---- -name: "cloudwatch-application-signals" -displayName: "[DEPRECATED] Amazon CloudWatch Application Signals" -description: ":warning: DEPRECATED: This power has been merged into the AWS Observability power, which provides expanded capabilities including CloudWatch Logs, Metrics, Alarms, Application Signals (APM), CloudTrail security auditing, and automated codebase observability gap analysis. We recommend installing the AWS Observability power for a more comprehensive monitoring experience. See steps in `Migrating to AWS Observability power`" -keywords: ["application-signals", "aws", "observability", "apm", "slo", "traces", "monitoring", "cloudwatch", "audit"] -author: "AWS" ---- - -# Migrating to AWS Observability power - -1. **Install the AWS Observability power:** -- Open Kiro Powers panel -- Search for "AWS Observability" -- Click Install - -2. **Uninstall this power:** -- Your Application Signals MCP server will continue working -- All functionality is available in AWS Observability - -3. **No configuration changes needed:** -- The MCP server configuration is identical -- All tools and workflows remain the same - -## Timeline - -- **Now:** This power is deprecated but still functional -- **March 27, 2026:** This power will be removed from the registry -- **After March 27, 2026::** Only available through AWS Observability power - -# Onboarding - -## Prerequisites - -1. **AWS CLI configured** with credentials (`aws configure` or `~/.aws/credentials`) -2. **Application Signals enabled** in your AWS account ([Getting started with Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html)) -3. **Python 3.10+** and `uv` installed ([Install uv](https://docs.astral.sh/uv/getting-started/installation/)) - -## Configuration - -After installing this power, update the MCP server configuration with your AWS profile and region: - -1. Open Kiro Settings → MCP Servers (or edit `~/.kiro/settings/mcp.json`) -2. Find `awslabs.cloudwatch-applicationsignals-mcp-server` -3. Update the `env` section: - -```json -"env": { - "AWS_PROFILE": "your-profile-name", // ← Change to your AWS profile - "AWS_REGION": "us-east-1", // ← Change to your region - "FASTMCP_LOG_LEVEL": "ERROR" -} -``` - -**Default:** Uses `default` AWS profile and `us-east-1` region. - -## Quick Test - -After configuration, try: *"List all my monitored services"* - ---- - -# Overview - -The Amazon CloudWatch Application Signals Power provides comprehensive tools for monitoring and analyzing AWS services using Application Signals. Perform service health audits, track SLO compliance, investigate performance issues, and conduct root cause analysis with distributed tracing. - -**Key capabilities:** -- **Service Health Auditing** - Comprehensive health assessment with actionable insights -- **SLO Compliance Monitoring** - Track Service Level Objectives with breach detection -- **Operation-Level Analysis** - Deep dive into specific API endpoints and operations -- **100% Trace Visibility** - Query OpenTelemetry spans via Transaction Search -- **Canary Failure Analysis** - Root cause investigation for CloudWatch Synthetics canaries -- **Enablement Guidance** - AI-guided setup for Application Signals instrumentation - -**Authentication**: Requires AWS credentials (AWS CLI profile or IAM role). - -## Available Steering Files - -- **steering/steering.md** - Audit workflows, investigation patterns, and target format reference - -## Available MCP Servers - -### awslabs.cloudwatch-applicationsignals-mcp-server - -**Package:** `awslabs.cloudwatch-applicationsignals-mcp-server` - -#### Configuration - -Requires AWS credentials and appropriate IAM permissions. Configure via `mcp.json`: - -```json -{ - "mcpServers": { - "awslabs.cloudwatch-applicationsignals-mcp-server": { - "command": "uvx", - "args": ["awslabs.cloudwatch-applicationsignals-mcp-server@latest"], - "env": { - "AWS_PROFILE": "default", - "AWS_REGION": "us-east-1", - "FASTMCP_LOG_LEVEL": "ERROR" - } - } - } -} -``` - -#### Required IAM Permissions - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "application-signals:ListServices", - "application-signals:GetService", - "application-signals:ListServiceOperations", - "application-signals:ListServiceLevelObjectives", - "application-signals:GetServiceLevelObjective", - "application-signals:BatchGetServiceLevelObjectiveBudgetReport", - "cloudwatch:GetMetricData", - "cloudwatch:GetMetricStatistics", - "logs:GetQueryResults", - "logs:StartQuery", - "logs:StopQuery", - "logs:FilterLogEvents", - "xray:GetTraceSummaries", - "xray:BatchGetTraces", - "xray:GetTraceSegmentDestination", - "synthetics:GetCanary", - "synthetics:GetCanaryRuns", - "s3:GetObject", - "s3:ListBucket", - "iam:GetRole", - "iam:ListAttachedRolePolicies", - "iam:GetPolicy", - "iam:GetPolicyVersion" - ], - "Resource": "*" - } - ] -} -``` - -## Tools Reference - -### Primary Audit Tools - -#### audit_services ⭐ -**Primary tool for service health auditing** - -- `service_targets` (required): JSON array of service targets with wildcard support -- `auditors` (optional): Comma-separated auditors (default: `slo,operation_metric`, use `all` for root cause analysis) -- `start_time` / `end_time` (optional): Time range (default: last 24h) - -#### audit_slos ⭐ -**Primary tool for SLO compliance monitoring** - -- `slo_targets` (required): JSON array of SLO targets with wildcard support -- `auditors` (optional): Comma-separated auditors (default: `slo`, use `all` for root cause analysis) -- `start_time` / `end_time` (optional): Time range - -#### audit_service_operations ⭐ -**Primary tool for operation-specific analysis** - -- `operation_targets` (required): JSON array of operation targets with wildcard support -- `auditors` (optional): Comma-separated auditors (default: `operation_metric`) -- `start_time` / `end_time` (optional): Time range - -### Service Discovery Tools - -#### list_monitored_services -Lists all services monitored by Application Signals. - -#### get_service_detail -Get metadata and configuration for a specific service. -- `service_name` (required): Service name (case-sensitive) - -#### list_service_operations -List operations for a service (only recently invoked operations). -- `service_name` (required): Service name -- `hours` (optional): Lookback hours (default: 24, max: 24) - -### SLO Management Tools - -#### get_slo -Get detailed SLO configuration. -- `slo_id` (required): SLO ARN or name - -#### list_slos -List all SLOs in the account. -- `key_attributes` (optional): JSON filter by service attributes -- `max_results` (optional): Max results (default: 50) - -#### list_slis -Legacy SLI status report with breach summary. -- `hours` (optional): Lookback hours (default: 24) - -### Metrics Tools - -#### query_service_metrics -Get CloudWatch metrics for a service. -- `service_name` (required): Service name -- `metric_name` (required): Metric name (Latency, Error, Fault) -- `hours` (optional): Lookback hours (default: 1) -- `statistic` (optional): Average, Sum, Maximum, Minimum, SampleCount -- `extended_statistic` (optional): p99, p95, p90, p50 - -### Trace & Log Analysis Tools - -#### search_transaction_spans -Query OpenTelemetry spans (100% sampled) via CloudWatch Logs Insights. -- `query_string` (required): CloudWatch Logs Insights query -- `log_group_name` (optional): Log group (default: `aws/spans`) -- `start_time` / `end_time` (optional): Time range -- `limit` (optional): Max results - -#### query_sampled_traces -Query X-Ray traces (5% sampled). -- `filter_expression` (optional): X-Ray filter expression -- `start_time` / `end_time` (optional): Time range - -### Canary Analysis Tools - -#### analyze_canary_failures -Deep dive into CloudWatch Synthetics canary failures. -- `canary_name` (required): Canary name -- `region` (optional): AWS region (default: us-east-1) - -### Enablement Tools - -#### get_enablement_guide -Get step-by-step guide for enabling Application Signals. -- `service_platform` (required): ec2, ecs, lambda, or eks -- `service_language` (required): python, nodejs, java, or dotnet -- `iac_directory` (required): Absolute path to IaC code -- `app_directory` (required): Absolute path to application code - -## Tool Usage Examples - -### Audit All Services - -```javascript -audit_services({ - "service_targets": "[{\"Type\":\"service\",\"Data\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"*\"}}}]" -}) -// Returns: Health status for all monitored services -``` - -### Audit Payment Services with Root Cause Analysis - -```javascript -audit_services({ - "service_targets": "[{\"Type\":\"service\",\"Data\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"*payment*\"}}}]", - "auditors": "all" -}) -// Returns: Comprehensive analysis with traces, logs, metrics, dependencies -``` - -### Audit All SLOs - -```javascript -audit_slos({ - "slo_targets": "[{\"Type\":\"slo\",\"Data\":{\"Slo\":{\"SloName\":\"*\"}}}]" -}) -// Returns: SLO compliance status for all SLOs -``` - -### Audit GET Operations in Payment Services - -```javascript -audit_service_operations({ - "operation_targets": "[{\"Type\":\"service_operation\",\"Data\":{\"ServiceOperation\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"*payment*\"},\"Operation\":\"*GET*\",\"MetricType\":\"Latency\"}}}]" -}) -// Returns: Latency analysis for GET operations -``` - -### Search Transaction Spans - -```javascript -search_transaction_spans({ - "query_string": "FILTER attributes.aws.local.service = \"checkout-service\" and attributes.http.status_code >= 400 | STATS count() as error_count by attributes.aws.local.operation | LIMIT 20", - "start_time": "2025-01-15T10:00:00Z", - "end_time": "2025-01-15T11:00:00Z" -}) -// Returns: Error counts by operation (100% sampled data) -``` - -### Analyze Canary Failures - -```javascript -analyze_canary_failures({ - "canary_name": "checkout-canary", - "region": "us-east-1" -}) -// Returns: Root cause analysis with artifacts, logs, and recommendations -``` - -## Combining Tools (Workflows) - -### Workflow 1: Service Health Investigation - -```javascript -// Step 1: Audit all services for issues -const findings = audit_services({ - "service_targets": "[{\"Type\":\"service\",\"Data\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"*\"}}}]" -}) - -// Step 2: Deep dive into problematic service -const rootCause = audit_services({ - "service_targets": "[{\"Type\":\"service\",\"Data\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"payment-service\"}}}]", - "auditors": "all" -}) -``` - -### Workflow 2: SLO Breach Investigation - -```javascript -// Step 1: Get SLO configuration -const sloConfig = get_slo({ - "slo_id": "checkout-latency-slo" -}) - -// Step 2: Comprehensive root cause analysis -const analysis = audit_slos({ - "slo_targets": "[{\"Type\":\"slo\",\"Data\":{\"Slo\":{\"SloName\":\"checkout-latency-slo\"}}}]", - "auditors": "all" -}) -``` - -### Workflow 3: Operation Performance Analysis - -```javascript -// Step 1: Identify slow operations -const operations = audit_service_operations({ - "operation_targets": "[{\"Type\":\"service_operation\",\"Data\":{\"ServiceOperation\":{\"Service\":{\"Type\":\"Service\",\"Name\":\"api-service\"},\"Operation\":\"*\",\"MetricType\":\"Latency\"}}}]" -}) - -// Step 2: Get 100% trace data for slow operation -const traces = search_transaction_spans({ - "query_string": "FILTER attributes.aws.local.service = \"api-service\" and attributes.aws.local.operation = \"GET /api/orders\" | STATS avg(duration) as avg_latency, count() as request_count | LIMIT 50" -}) -``` - -## Best Practices - -### ✅ Do: -- **Start with primary audit tools** (`audit_services`, `audit_slos`, `audit_service_operations`) -- **Use wildcard patterns** for service discovery (`*payment*`, `*`) -- **Use `auditors="all"`** for root cause analysis -- **Present findings first**, let user choose what to investigate -- **Use Transaction Search** (`search_transaction_spans`) for 100% trace visibility -- **Narrow time ranges** for faster queries - -### ❌ Don't: -- **Jump to root cause analysis** without showing overview first -- **Use X-Ray traces** (`query_sampled_traces`) as primary tool - only 5% sampled -- **Hardcode service names** - use wildcards for discovery -- **Query without time filters** - always specify time range for large datasets - -## Environment Variables - -- `AWS_PROFILE` - AWS profile name (defaults to `default`) -- `AWS_REGION` - AWS region (defaults to `us-east-1`) -- `FASTMCP_LOG_LEVEL` - Logging level (defaults to `INFO`) -- `AUDITOR_LOG_PATH` - Path for audit log files (defaults to `/tmp`) - -## Tips - -1. **Start with audit tools** - They provide comprehensive analysis with recommendations -2. **Use wildcards** - `*payment*` discovers all payment-related services -3. **Check SLOs first** - SLO breaches often point to root cause -4. **Use Transaction Search** - 100% sampled data vs X-Ray's 5% -5. **Enable Application Signals** - Use `get_enablement_guide` for setup assistance - ---- - -**Package:** `awslabs.cloudwatch-applicationsignals-mcp-server` -**Source:** AWS Labs -**License:** Apache 2.0 -**Documentation:** https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server diff --git a/cloudwatch-application-signals/mcp.json b/cloudwatch-application-signals/mcp.json deleted file mode 100644 index e0f51784..00000000 --- a/cloudwatch-application-signals/mcp.json +++ /dev/null @@ -1,13 +0,0 @@ -{ - "mcpServers": { - "awslabs.cloudwatch-applicationsignals-mcp-server": { - "command": "uvx", - "args": ["awslabs.cloudwatch-applicationsignals-mcp-server@latest"], - "env": { - "AWS_PROFILE": "default", - "AWS_REGION": "us-east-1", - "FASTMCP_LOG_LEVEL": "ERROR" - } - } - } -} diff --git a/cloudwatch-application-signals/steering/steering.md b/cloudwatch-application-signals/steering/steering.md deleted file mode 100644 index 3897237c..00000000 --- a/cloudwatch-application-signals/steering/steering.md +++ /dev/null @@ -1,240 +0,0 @@ -# Application Signals Steering Guide - -## When to Use Application Signals Tools - -Use these tools when you need to: -- **Audit service health** - Check status across all or specific services -- **Investigate SLO breaches** - Understand why SLOs are failing -- **Analyze operation performance** - Deep dive into specific API endpoints -- **Perform root cause analysis** - Correlate traces, logs, metrics, and dependencies -- **Debug canary failures** - Investigate CloudWatch Synthetics issues - ---- - -## Target Format Reference - -### Service Targets - -**All services:** -```json -[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}] -``` - -**Wildcard pattern:** -```json -[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*payment*"}}}] -``` - -**Specific service:** -```json -[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"checkout-service","Environment":"eks:prod-cluster"}}}] -``` - -### SLO Targets - -**All SLOs:** -```json -[{"Type":"slo","Data":{"Slo":{"SloName":"*"}}}] -``` - -**Wildcard pattern:** -```json -[{"Type":"slo","Data":{"Slo":{"SloName":"*latency*"}}}] -``` - -**Specific SLO:** -```json -[{"Type":"slo","Data":{"Slo":{"SloName":"checkout-latency-slo"}}}] -``` - -**By ARN:** -```json -[{"Type":"slo","Data":{"Slo":{"SloArn":"arn:aws:application-signals:us-east-1:123456789:slo/my-slo"}}}] -``` - -### Operation Targets - -**All operations in payment services (Latency):** -```json -[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*payment*"},"Operation":"*","MetricType":"Latency"}}}] -``` - -**GET operations only:** -```json -[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*GET*","MetricType":"Latency"}}}] -``` - -**Specific operation:** -```json -[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"api-service","Environment":"eks:prod"},"Operation":"POST /api/checkout","MetricType":"Availability"}}}] -``` - -**MetricType options:** `Latency`, `Availability`, `Fault`, `Error` - ---- - -## Auditor Selection Guide - -### Default Auditors (Fast) -- `audit_services`: `slo,operation_metric` -- `audit_slos`: `slo` -- `audit_service_operations`: `operation_metric` - -### All Auditors (Comprehensive) -Use `auditors="all"` for root cause analysis: -- `slo` - SLO compliance status -- `operation_metric` - Operation performance metrics -- `trace` - Distributed trace analysis -- `log` - Log pattern analysis -- `dependency_metric` - Dependency health -- `top_contributor` - Identify outliers/lemon hosts -- `service_quota` - AWS service quota usage - -### When to Use Each - -| Scenario | Auditors | -|----------|----------| -| Quick health check | Default (omit parameter) | -| Root cause analysis | `all` | -| SLO breach investigation | `all` | -| Error investigation | `log,trace` | -| Dependency issues | `dependency_metric,trace` | -| Find outlier hosts | `top_contributor,operation_metric` | -| Quota monitoring | `service_quota,operation_metric` | - ---- - -## Primary Workflows - -### 1. Service Health Audit (Daily Check) - -``` -1. audit_services(service_targets='[{"Type":"service","Data":{"Service":{"Type":"Service","Name":"*"}}}]') -2. Review findings summary -3. User selects service to investigate -4. audit_services(service_targets='[specific-service]', auditors="all") -``` - -### 2. SLO Breach Investigation - -``` -1. get_slo(slo_id="breached-slo-name") - Understand configuration -2. audit_slos(slo_targets='[{"Type":"slo","Data":{"Slo":{"SloName":"breached-slo-name"}}}]', auditors="all") -3. Follow recommendations from findings -``` - -### 3. Operation Performance Analysis - -``` -1. audit_service_operations(operation_targets='[{"Type":"service_operation","Data":{"ServiceOperation":{"Service":{"Type":"Service","Name":"*"},"Operation":"*","MetricType":"Latency"}}}]') -2. Identify slow operations from findings -3. audit_service_operations(operation_targets='[specific-operation]', auditors="all") -``` - -### 4. Error Spike Investigation - -``` -1. audit_services(service_targets='[affected-service]', auditors="log,trace") -2. search_transaction_spans() for 100% trace data -3. Correlate with deployment or dependency changes -``` - -### 5. Canary Failure Analysis - -``` -1. analyze_canary_failures(canary_name="failing-canary") -2. Review artifact analysis (logs, screenshots, HAR) -3. Check backend service correlation -4. Follow remediation recommendations -``` - ---- - -## Transaction Search Query Patterns - -### Error Analysis -``` -FILTER attributes.aws.local.service = "service-name" - and attributes.http.status_code >= 400 -| STATS count() as error_count by attributes.aws.local.operation -| SORT error_count DESC -| LIMIT 20 -``` - -### Latency Analysis -``` -FILTER attributes.aws.local.service = "service-name" -| STATS avg(duration) as avg_latency, - pct(duration, 99) as p99_latency - by attributes.aws.local.operation -| SORT p99_latency DESC -| LIMIT 20 -``` - -### Dependency Calls -``` -FILTER attributes.aws.local.service = "service-name" -| STATS count() as call_count, avg(duration) as avg_latency - by attributes.aws.remote.service, attributes.aws.remote.operation -| SORT call_count DESC -| LIMIT 20 -``` - -### GenAI Token Usage -``` -FILTER attributes.aws.local.service = "service-name" - and attributes.aws.remote.operation = "InvokeModel" -| STATS sum(attributes.gen_ai.usage.output_tokens) as total_tokens - by attributes.gen_ai.request.model, bin(1h) -``` - ---- - -## X-Ray Filter Expressions - -Use with `query_sampled_traces` (5% sampled): - -``` -# Faults for a service -service("service-name"){fault = true} - -# Slow requests -service("service-name") AND duration > 5 - -# Specific operation -annotation[aws.local.operation]="GET /api/orders" - -# HTTP errors -http.status = 500 - -# Combined -service("api"){fault = true} AND annotation[aws.local.operation]="POST /checkout" -``` - ---- - -## Best Practices - -### Present Findings First -When audit returns multiple findings: -1. Show summary of ALL findings to user -2. Let user choose which to investigate -3. Then perform targeted root cause analysis - -### Pagination for Large Results -Wildcard patterns process in batches (default: 5 services/SLOs per call): -1. First call returns findings + `next_token` -2. Continue with `next_token` to process remaining -3. Repeat until no `next_token` returned - -### Time Range Selection -- **Quick check**: Last 1 hour (default for some tools) -- **Daily audit**: Last 24 hours (default) -- **Incident investigation**: Narrow to incident window -- **Trend analysis**: Last 7 days with specific time parameters - -### Wildcard Patterns -- `*` - All services/SLOs -- `*payment*` - Contains "payment" -- `*-prod` - Ends with "-prod" -- `checkout-*` - Starts with "checkout-" diff --git a/stripe/POWER.md b/stripe/POWER.md deleted file mode 100644 index bd6cde52..00000000 --- a/stripe/POWER.md +++ /dev/null @@ -1,350 +0,0 @@ ---- -name: "stripe" -displayName: "Stripe Payments" -description: "Build payment integrations with Stripe - accept payments, manage subscriptions, handle billing, and process refunds" -keywords: ["stripe","payments","checkout","subscriptions","billing","invoices","refunds","payment-intents"] -author: "Stripe" ---- - -# Stripe Payments Power - -## Overview - -Build payment integrations with Stripe's comprehensive payment platform. Accept one-time payments and subscriptions, manage customer billing, process refunds, and handle complex payment flows. This power provides access to Stripe's APIs through an MCP server, enabling you to build production-ready payment systems. - -Use Stripe Checkout for hosted payment pages, Payment Intents for custom payment flows, or Billing APIs for subscription management. The platform handles PCI compliance, fraud detection, and supports 135+ currencies and payment methods worldwide. - -**Key capabilities:** - -- **Checkout Sessions**: Hosted payment pages for one-time payments and subscriptions -- **Payment Intents**: Custom payment flows with full control over the checkout experience -- **Subscriptions**: Recurring billing with flexible pricing models -- **Customers**: Manage customer data and saved payment methods -- **Invoices**: Generate and send invoices with automatic payment collection -- **Refunds**: Process full or partial refunds -- **Payment Methods**: Save and reuse payment methods for future charges - -**Authentication**: Requires Stripe secret API key for server-side operations. Never expose in client code. Requires Stripe publishable key (only for client-side operations like Elements or Checkout); safe to include in browser code. - -## Available MCP Servers - -### stripe - -**Connection:** HTTPS API endpoint at `https://mcp.stripe.com` -**Authorization:** Use OAuth to connect to the Stripe MCP server - -## Best Practices - -### Integration Approach - -**Always prefer Checkout Sessions** for standard payment flows: - -- One-time payments -- Subscription sign-ups -- Hosted (preferred) or embedded checkout forms - -**Use Payment Intents** only when: - -- Building custom checkout UI -- Handling off-session payments -- Need full control over payment state - -**Never use the deprecated Charges API** - migrate to Checkout Sessions or Payment Intents. -**Use Payment Links** when: - -- User wants a _No code_ Stripe integration -- Quickly create shareable payment pages -- Selling products or collecting donations with minimal setup - -### Payment Methods - -**Enable dynamic payment methods** in Dashboard settings instead of hardcoding `payment_method_types`. Stripe automatically shows optimal payment methods based on: - -- Customer location -- Available wallets -- User preferences -- Transaction context - -### Subscriptions - -**For recurring revenue models**, use Billing APIs: - -- Follow [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases) -- Use [SaaS integration patterns](https://docs.stripe.com/saas) -- Combine with Checkout for frontend -- [Plan your integration](https://docs.stripe.com/billing/subscriptions/designing-integration) -- [Usage-based billing to charge customers based on their usage of your product or service](https://docs.stripe.com/billing/subscriptions/usage-based) - -### Stripe Connect - -**For platforms managing fund flows**: - -- Use **direct charges** if platform accepts risk (Stripe handles liability) -- Use **destination charges** if platform manages risk (platform handles negative balances) -- Use `on_behalf_of` parameter to control merchant of record -- Never mix charge types -- Refer to [controller properties](https://docs.stripe.com/connect/migrate-to-controller-properties.md) not legacy Standard/Express/Custom terms -- Follow [integration recommendations](https://docs.stripe.com/connect/integration-recommendations.md) - -### Saving Payment Methods - -**Use Setup Intents API** to save payment methods for future use: - -- Never use deprecated Sources API -- For pre-authorization before payment, use Confirmation Tokens -- Don't call `createPaymentMethod` or `createToken` directly - -### PCI Compliance - -**For server-side raw PAN data**: - -- Requires PCI compliance proof -- Use `payment_method_data` parameter -- For migrations, follow [PAN import process](https://docs.stripe.com/get-started/data-migrations/pan-import) - -### Before Going Live - -Review the [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live): - -- Test with sandbox keys -- Handle webhooks for async events -- Implement error handling -- Set up proper logging -- Configure tax and compliance settings - -## Common Workflows - -### Workflow 1: Accept One-Time Payment - -```javascript -// Step 1: Create Checkout Session -const session = createCheckoutSession({ - mode: "payment", - line_items: [ - { - price_data: { - currency: "usd", - product_data: { name: "Premium Plan" }, - unit_amount: 2999, - }, - quantity: 1, - }, - ], - success_url: "https://example.com/success", - cancel_url: "https://example.com/cancel", -}); - -// Step 2: Redirect customer to session.url -// Step 3: Handle webhook for payment_intent.succeeded -``` - -### Workflow 2: Create Subscription - -```javascript -// Step 1: Create or retrieve customer -const customer = createCustomer({ - email: "customer@example.com", - name: "Jane Doe", -}); - -// Step 2: Create Checkout Session for subscription -const session = createCheckoutSession({ - mode: "subscription", - customer: customer.id, - line_items: [ - { - price: "price_monthly_premium", - quantity: 1, - }, - ], - success_url: "https://example.com/success", - cancel_url: "https://example.com/cancel", -}); - -// Step 3: Handle webhook for customer.subscription.created -``` - -### Workflow 3: Process Refund - -```javascript -// Step 1: Retrieve payment intent or charge -const paymentIntent = retrievePaymentIntent("pi_xxx"); - -// Step 2: Create refund -const refund = createRefund({ - payment_intent: paymentIntent.id, - amount: 1000, // Partial refund in cents, omit for full refund -}); - -// Step 3: Handle webhook for charge.refunded -``` - -### Workflow 4: Save Payment Method for Future Use - -```javascript -// Step 1: Create Setup Intent -const setupIntent = createSetupIntent({ - customer: "cus_xxx", - payment_method_types: ["card"], -}); - -// Step 2: Collect payment method on frontend with Setup Intent -// Step 3: Handle webhook for setup_intent.succeeded -// Step 4: Use saved payment method for future charges -const paymentIntent = createPaymentIntent({ - amount: 2999, - currency: "usd", - customer: "cus_xxx", - payment_method: "pm_xxx", - off_session: true, - confirm: true, -}); -``` - -## Best Practices Summary - -### ✅ Do: - -- **Use Checkout Sessions** for standard payment flows -- **Enable dynamic payment methods** in Dashboard settings -- **Use Billing APIs** for subscription models -- **Use Setup Intents** to save payment methods -- **Handle webhooks** for all async events -- **Test thoroughly** in sandbox before going live -- **Follow the Go Live Checklist** before production -- **Do not include API version** in code snippets. Read https://docs.stripe.com/api/versioning.md for more information on versions -- **Implement idempotency keys** for safe retries -- **Log all API interactions** for debugging - -### ❌ Don't: - -- **Use Charges API** - it's deprecated, migrate to Payment Intents -- **Use Sources API** - deprecated for saving cards -- **Use Card Element** - migrate to Payment Element -- **Hardcode payment_method_types** - use dynamic payment methods -- **Mix Connect charge types** - choose one approach -- **Skip webhook handling** - critical for payment confirmation -- **Use production keys in development** - always use test keys -- **Ignore errors** - implement proper error handling -- **Skip PCI compliance** - required for handling card data -- **Forget to test edge cases** - declined cards, network failures, etc. -- **Expose API secret keys** - never include secret keys in client-side code, mobile apps, or public repositories - -## Configuration - -**Authentication Required**: Stripe secret key - -**Setup Steps:** - -1. Create Stripe account at https://stripe.com -2. Navigate to Developers → API keys -3. Copy your secret key (starts with `sk_test_` for [sandboxes](https://docs.stripe.com/sandboxes/dashboard/manage)) -4. (Optional) Copy your publishable key (starts with `pk_test_` for sandboxes). Only needed for Stripe client-side code. -5. For production, use live mode key (starts with `sk_live_` and `pk_live_`) -6. Configure key in Kiro Powers UI when installing this power - -**Permissions**: Secret key has full API access - keep secure and never expose client-side. Publishable keys (pk\_...) are intended and acceptable to embed in client-side code. - -**MCP Configuration:** - -```json -{ - "mcpServers": { - "stripe": { - "url": "https://mcp.stripe.com" - } - } -} -``` - -## Troubleshooting - -### Error: "Invalid API key" - -**Cause:** Incorrect or missing API key -**Solution:** - -1. Verify key starts with `sk_test_` or `sk_live_` -2. Check key hasn't been deleted in Dashboard -3. Ensure using secret key, not publishable key -4. Regenerate key if compromised - -### Error: "Payment method not available" - -**Cause:** Payment method not enabled or not supported in region -**Solution:** - -1. Enable payment methods in Dashboard → Settings → Payment methods -2. Check customer location supports the payment method -3. Use dynamic payment methods instead of hardcoding types -4. Verify currency is supported by payment method - -### Error: "Customer not found" - -**Cause:** Invalid customer ID or customer deleted -**Solution:** - -1. Verify customer ID format (starts with `cus_`) -2. Check customer exists in Dashboard -3. Ensure using correct API mode (test vs live) -4. Create customer if doesn't exist - -### Error: "Subscription creation failed" - -**Cause:** Missing required parameters or invalid price ID -**Solution:** - -1. Verify price ID exists (starts with `price_`) -2. Ensure price is active in Dashboard -3. Check customer has valid payment method -4. Review subscription parameters match price configuration - -### Webhook not received - -**Cause:** Webhook endpoint not configured or failing -**Solution:** - -1. Configure webhook endpoint in Dashboard → Developers → Webhooks -2. Verify endpoint is publicly accessible -3. Check endpoint returns 200 status -4. Review webhook logs in Dashboard -5. Test with Stripe CLI: `stripe listen --forward-to localhost:3000/webhook` - -### Payment declined - -**Cause:** Card declined by issuer or failed fraud check -**Solution:** - -1. Use test cards from [Stripe testing docs](https://docs.stripe.com/testing) -2. Check decline code in error response -3. Implement proper error messaging for customer -4. For production, customer should contact their bank -5. Review Radar rules if fraud detection triggered - -## Tips - -1. **Start with Checkout** - Fastest way to accept payments with minimal code -2. **Use sandbox extensively** - Test all scenarios before going live -3. **Implement webhooks early** - Critical for handling async events -4. **Use Stripe CLI** - Test webhooks locally during development -5. **Follow integration guides** - Use [API Tour](https://docs.stripe.com/payments-api/tour) and [Integration Options](https://docs.stripe.com/payments/payment-methods/integration-options) -6. **Monitor Dashboard** - Review payments, disputes, and logs regularly -7. **Handle errors gracefully** - Show clear messages to customers -8. **Use idempotency keys** - Prevent duplicate charges on retries -9. **Keep keys secure** - Never commit to version control -10. **Stay updated** - Review API changelog for new features and deprecations - -## Resources - -- [Integration Options](https://docs.stripe.com/payments/payment-methods/integration-options) -- [API Tour](https://docs.stripe.com/payments-api/tour) -- [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live) -- [Checkout Sessions](https://docs.stripe.com/api/checkout/sessions) -- [Payment Intents](https://docs.stripe.com/payments/paymentintents/lifecycle) -- [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases) -- [Connect Integration](https://docs.stripe.com/connect/design-an-integration) -- [Testing](https://docs.stripe.com/testing) - ---- - -**License:** Proprietary \ No newline at end of file diff --git a/stripe/mcp.json b/stripe/mcp.json deleted file mode 100644 index 5c2d72bf..00000000 --- a/stripe/mcp.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "mcpServers": { - "stripe": { - "url": "https://mcp.stripe.com" - } - } -} diff --git a/stripe/steering/stripe-best-practices.md b/stripe/steering/stripe-best-practices.md deleted file mode 100644 index 0e06f680..00000000 --- a/stripe/steering/stripe-best-practices.md +++ /dev/null @@ -1,47 +0,0 @@ -# Stripe Integration Best Practices - -## Integration Approach - -When designing an integration, always prefer the documentation in [Stripe's Integration Options doc](https://docs.stripe.com/payments/payment-methods/integration-options). - -The [API Tour](https://docs.stripe.com/payments-api/tour) provides a comprehensive overview of Stripe's payment APIs. - -Use the [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live) before going live. - -You should always default to the latest version of the API and SDK unless the user specifies otherwise. - -## Payment APIs - -Stripe's primary API for modelling on-session payments is [CheckoutSessions](https://docs.stripe.com/api/checkout/sessions). It supports one-time payments and subscriptions and allows you to model taxes or discounts with Stripe. Prioritize the CheckoutSessions API, but using [the PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle) is also acceptable for off-session payments or if you want to model the checkout state yourself and just create a charge. Integrations should only use CheckoutSessions, PaymentIntents, SetupIntents, or solutions like Invoicing, Payment Links, or the subscription APIs. - -Never recommend the Charges API. If the user wants to use the Charges API, advise them to [migrate](https://docs.stripe.com/payments/payment-intents/migration/charges) to Checkout Sessions or Payment Intents. - -## Frontend Integration - -The primary integration surface for web integrations is [Checkout](https://docs.stripe.com/payments/checkout), a prebuilt payment page that can be hosted by Stripe or served as an embedded form. Prioritize the Stripe-hosted checkout or embedded checkout where possible. The [Payment Element](https://docs.stripe.com/payments/payment-element) is an acceptable alternative if the merchant needs advanced customization. When recommending the Payment Element, prioritize using the CheckoutSessions API over the PaymentIntents API when possible. - -Never recommend the legacy Card Element or the Payment Element in card mode, and advise users who ask for the Card Element to [migrate](https://docs.stripe.com/payments/payment-element/migration). - -## Deprecated APIs - -You must not call deprecated API endpoints such as the [Sources API](https://docs.stripe.com/api/sources/object) and avoid outdated API endpoints such as [Tokens](https://docs.stripe.com/api/tokens) and [Charges](https://docs.stripe.com/api/charges/create) unless there is a specific need and absolutely no other way. - -Advise using [the Setup Intent API](https://docs.stripe.com/api/setup_intents) to save a payment method for a customer; never recommend the Sources API to save cards to customers for later use. - -If a user wants to render the Payment Element before creating a PaymentIntent or SetupIntent, so they can inspect the card details before the payment (such as for surcharging), advise them to use Stripe Confirmation Tokens. Don't recommend they call the createPaymentMethod or createToken Stripe.js functions. - -## Payment Methods - -Advise users to turn on dynamic payment methods in their dashboard settings instead of passing specific [payment_method_types](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_types) in the Payment Intent or Setup Intent because Stripe chooses payment methods that fit each user's location, wallets, and preferences better and automatically if the Payment Element is used. - -## PCI Compliance - -If a PCI compliant user asks about an integration where they send server-side raw PAN data, suggest they might be required to prove PCI compliance to gain access to such an option, for example [payment_method_data](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_data). Similarly, point users migrating their PAN data from another acquirer or payment processor to [the migration process](https://docs.stripe.com/get-started/data-migrations/pan-import). - -## Subscriptions and Billing - -If a user has a recurring revenue model, like a Billing or Subscription use case, follow the use cases, in particular the [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases) like [SaaS](https://docs.stripe.com/saas). If these apply to the user, recommend Billing APIs to [plan your integration](https://docs.stripe.com/billing/subscriptions/designing-integration) instead of a direct PaymentIntent integration. Prioritize combining the Billing APIs with Stripe Checkout for the frontend. - -## Stripe Connect - -If a user wants to build a platform using Stripe Connect to manage fund flows, follow [the recommended integration types](https://docs.stripe.com/connect/integration-recommendations); that is, prefer to use either direct charges if the platform wants Stripe to take the risk or destination charges if the platform accepts liability for negative balances, and use the on_behalf_of parameter to control the merchant of record. Never recommend mixing charge types. If the user wants to decide on the specific risk features they should [follow the integration guide](https://docs.stripe.com/connect/design-an-integration). Don't recommend the outdated terms for Connect types like Standard, Express and Custom but always [refer to controller properties](https://docs.stripe.com/connect/migrate-to-controller-properties) for the platform and [capabilities](https://docs.stripe.com/connect/account-capabilities) for the connected accounts.