"AWS Fargate" matching MCP tools:

• awsinspect_batchA

  InsideOut (Riley)A

  BATCH INSPECTION: run up to 32 AWS inspect probes in one call. ⚠️ **PREREQUISITE**: Same as awsinspect — deploy attempt required. Check convostatus for hasDeployAttempt=true before calling. Use this when you need to check more than ~3 resources. The backend fetches Oracle credentials ONCE per batch and fans out probes against a single AWS config — for a 12-resource health check this is ~5–8× faster and 12× fewer Oracle round-trips than calling awsinspect 12 times. BUDGETS: - Up to 32 sub-probes per call (subs array length). - 30s per-sub timeout; 60s total batch wall-clock. - Concurrency cap 8 — sub-probes run in parallel but never saturate AWS. - 512 KB response cap: subs past the cap keep their envelope (index/service/action/ok) but have result replaced with truncated=true. PARTIAL FAILURE IS EXPECTED. The response is an ordered results array; each entry has {index, service, action, ok, result, error}. Inspect each result — do NOT abort on the first error. A credential fetch failure leaves cred-less probes (list-actions, list-metrics) succeeding anyway. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: account, acm, alb, apigateway, apprunner, backup, bedrock, cloudfront, cloudwatchlogs, cognito, cost-explorer, dynamodb, ebs, ec2, ecs, eks, elasticache, kms, lambda, msk, opensearch, rds, route53, s3, sagemaker, secretsmanager, sqs, vpc, waf For a specific service's actions, use awsinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular awsinspect when you need full metadata or raw API output for one resource. EXAMPLES: - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"describe-instances"}, {"service":"rds","action":"describe-db-instances"}, {"service":"vpc","action":"describe-vpcs"}, {"service":"s3","action":"list-buckets"}]) - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"get-metrics","filters":"{\"hours\":6}"}, {"service":"rds","action":"get-metrics","filters":"{\"hours\":6}"}])

  ConnectorNo auth

• aws___search_documentationA

  AWS KnowledgeA

  AWS docs search. Each result's `context` is verbatim page text -- a real chunk of the actual page, not a short snippet -- and usually already contains the answer, so answer directly from it. Use `read_documentation` only when the chunks genuinely lack the needed detail. Pick ONE topic. Add a 2nd ONLY if query genuinely spans domains. Extra topics dilute ranking. - reference_documentation -- API/SDK/CLI specs, config params - current_awareness -- new/released/announced - troubleshooting -- errors, "how to fix" (NOT for conceptual/feature questions) - amplify_docs -- Amplify (+ language) - cdk_docs -- CDK concepts/guides - cdk_constructs -- CDK code samples, L3 - cloudformation -- CFN/SAM templates - strands_docs -- Strands Agents SDK (its Skills/agents concepts go here, NOT agent_skills) - agent_skills -- this tool's guided skills (load via `retrieve_skill`) - general (default) -- architecture, best practices, tutorials, feature behavior Results: rank_order (lower=better), url, title, context (verbatim page chunk -- answer directly from it).

  ConnectorNo auth

• awsinspect_batchA

  InsideOut (Riley)A

  BATCH INSPECTION: run up to 32 AWS inspect probes in one call. ⚠️ **PREREQUISITE**: Same as awsinspect — deploy attempt required. Check convostatus for hasDeployAttempt=true before calling. Use this when you need to check more than ~3 resources. The backend fetches Oracle credentials ONCE per batch and fans out probes against a single AWS config — for a 12-resource health check this is ~5–8× faster and 12× fewer Oracle round-trips than calling awsinspect 12 times. BUDGETS: - Up to 32 sub-probes per call (subs array length). - 30s per-sub timeout; 60s total batch wall-clock. - Concurrency cap 8 — sub-probes run in parallel but never saturate AWS. - 512 KB response cap: subs past the cap keep their envelope (index/service/action/ok) but have result replaced with truncated=true. PARTIAL FAILURE IS EXPECTED. The response is an ordered results array; each entry has {index, service, action, ok, result, error}. Inspect each result — do NOT abort on the first error. A credential fetch failure leaves cred-less probes (list-actions, list-metrics) succeeding anyway. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: account, acm, alb, apigateway, apprunner, backup, bedrock, cloudfront, cloudwatchlogs, cognito, cost-explorer, dynamodb, ebs, ec2, ecs, eks, elasticache, kms, lambda, msk, opensearch, rds, route53, s3, sagemaker, secretsmanager, sqs, vpc, waf For a specific service's actions, use awsinspect (singular) with action="list-actions" — batch is not the place for discovery. Batch responses are always summarized (no detail/raw per-sub); use singular awsinspect when you need full metadata or raw API output for one resource. EXAMPLES: - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"describe-instances"}, {"service":"rds","action":"describe-db-instances"}, {"service":"vpc","action":"describe-vpcs"}, {"service":"s3","action":"list-buckets"}]) - awsinspect_batch(session_id=..., subs=[ {"service":"ec2","action":"get-metrics","filters":"{\"hours\":6}"}, {"service":"rds","action":"get-metrics","filters":"{\"hours\":6}"}])

  ConnectorNo auth

• run_cost_scanA

  Tomorrow Central: Cloud Cost SentinelA

  Start a cloud cost / FinOps scan of a linked account and return a job_id. Use this when the user wants to find idle, unused or underutilized cloud resources, review cloud spend, or estimate savings. The provider comes from the connection, and **AWS is the only provider supported today** (see `list_connections`). Other clouds will appear on this same tool as connections for them become linkable; nothing else about the call changes. READ-ONLY against your cloud: it reads resource metadata and monitoring metrics and reports; it never changes, stops or deletes anything. (It does create a scan job here and consume that account's scan quota, which is why this tool is not marked read-only.) On AWS it covers EC2 instances, EBS volumes and snapshots, RDS instances, Elastic IPs, NAT Gateways, load balancers, VPCs and VPC endpoints, site-to-site VPN and Transit Gateway attachments, Client VPN endpoints, Secrets Manager secrets, CloudFront distributions and WAF web ACLs. Resource kinds outside that list are not inspected, so a clean scan is not a claim that the whole bill is optimized. `connection_id` picks which linked AWS account to scan (see `list_connections`). Omit it to run against sample data — useful for showing the user what the output looks like before any account is linked. The scan runs asynchronously: poll `get_job(job_id)` roughly every 10 seconds until status is COMPLETED (typically 1-3 minutes), then call `list_cost_findings(job_id)`. Do NOT start another scan while one is running — each scan consumes the account's monthly quota. Pass `idempotency_key` (any unique string you choose) if you may retry on a network error: a retry with the same key returns the original job instead of starting a second scan.

  ConnectorNo auth

• find_cost_change_factorsA

  Costory: Your Finops MCPA

  Find which dimension values drove a cost change between two periods. This is a before/after analysis — compare is required (`{}` auto-derives the previous window, same as query). Prefer suggest_groupby / search / get_context first, then pass 2–4 columns (max 8). Do not invent columns. filterCel omitted or "" is unfiltered (not AWS-only). nestingEdges: a child's spend sits inside the parent — do not sum a contributor with its ancestors or descendants; independent contributors may be summed. Prefer omitting aggregationMethod (SUM). EXAMPLES: • "Why did last month's EC2 cost change?" → { datePreset: "LAST_MONTH", compare: {}, filterCel: "cos_service_name in [\"AmazonEC2\"]", columns: ["cos_region", "cos_usage_type"] } • "What drove the RDS jump in May?" → { from: "2026-05-01", to: "2026-05-31", compare: { from: "2026-04-01", to: "2026-04-30" }, filterCel: "cos_provider in [\"AWS\"] && cos_service_name in [\"AmazonRDS\"]", columns: ["cos_sub_account_id", { column: "cos_charge_description", contains: "IOPS" }] }

  ConnectorOAuth

• aws___get_regional_availabilityA

  AWS KnowledgeA

  AWS resource availability per region. - Max 10 regions; multi-region needs `filters`; single-region supports `next_token`. - Status: isAvailableIn | isNotAvailableIn | isPlannedIn | Not Found. - Response key: products | service_apis | cfn_resources. Not for region counts/docs/vague queries -- use `search_documentation` / `list_regions`. Filter values must EXACTLY match AWS's catalog names; guessed, partial, or pluralized names are rejected ("values in filter parameter do not exist"). If unsure of the exact name, first call once for a single region with resource_type set and NO filters to list all valid names, then re-call filtering on the exact match.

  ConnectorNo auth

• secret_scanA

  IA-QA — 130+ QA & Dev Tools for AI AgentsB

  Scan text or code for leaked secrets: API keys (AWS, GCP, Azure, OpenAI, Anthropic, Stripe, GitHub, GitLab, Slack, Twilio, SendGrid, HuggingFace), private keys (RSA/EC/PGP), JWTs, database connection strings, Bearer tokens, and Basic auth headers. Returns a list of findings with type, severity, line number, and a redacted preview. Use before committing code, sharing logs, or sending text to an LLM. 100% regex-based, zero network calls.

  ConnectorNo auth

• ml_dsa_signA

  CipherHUB Cryptography ToolkitA

  [pqc_signature] 使用 ML-DSA 私钥对消息签名（FIPS 204）。 【双模式】sign_mode 支持 RAW（默认）和 EXTERNAL_MU 两种模式。 - RAW 模式：直接签名原始消息（liboqs，最大 256 字节） - EXTERNAL_MU 模式：先计算 mu = SHAKE-256(tr||M', 64)，再通过 OpenSSL 3.5+ mu 模式签名（最大 2048 字节），与 AWS KMS ML-DSA EXTERNAL_MU 语义等价 【消息长度策略】 - RAW：最大 256 字节，空消息合法 - EXTERNAL_MU：最大 2048 字节，空消息合法 - > 256 且 <= 2048 字节：使用 EXTERNAL_MU - > 2048 字节：拒绝 【算法】algorithm 支持 ML-DSA-44 / ML-DSA-65（默认）/ ML-DSA-87。 【参数】 - private_key_in_hex：ml_dsa_keygen 返回的私钥 hex - public_key_spki_in_hex：EXTERNAL_MU 模式必填，ml_dsa_keygen 返回的公钥 hex（SPKI DER） - message_in_hex：待签消息 hex - context_in_hex：可选上下文 hex（最大 255 字节） - sign_mode：RAW 或 EXTERNAL_MU（默认 RAW） 【输出】signature_in_hex、signature_in_base64、algorithm、message_bytes、signature_bytes。

  ConnectorNo auth

• suggest_groupbyA

  Costory: Your Finops MCPA

  Suggest the best dimensions to group costs by, based on an optional filterCel (CEL). Call this when the user asks "what should I look at?" or when you need columns for query or find_cost_change_factors. Prefer datePreset over from/to. Omit compare for current-window ranking. Pass compare (`{}` auto-derives, or `{ from, to }`) when the user asks what changed — then pass 2–4 of the returned column names (max 8; { column, contains } for token columns, dropping metrics) into find_cost_change_factors. Returns { column } or { column, contains } plus metrics; do not invent columns. filterCel omitted or "" is unfiltered (not AWS-only). filterCel supports == null for unlabelled dimension values (e.g. cos_environment == null). EXAMPLES: • "What should I split last month's EC2 cost by?" → { datePreset: "LAST_MONTH", filterCel: "cos_service_name in [\"AmazonEC2\"]" } • "Costs of EC2 spiked last month, what should I investigate?" → { datePreset: "LAST_MONTH", compare: {}, filterCel: "cos_service_name in [\"AmazonEC2\"]" }

  ConnectorOAuth

• estimate_costA

  Tomorrow Central: Cloud Cost SentinelA

  Price a list of cloud components at real list prices. No account or signup. Use this when the user can name the pieces: "two m5.large servers, a Postgres database and a load balancer in Mumbai". If they cannot name the pieces, use `describe_workload` instead, which asks in units a person actually has. `items` is a list of `{"component": "<id>", "params": {...}}`. Get the ids and each component's parameters from `list_cost_building_blocks` and use them verbatim: a name you invent will be rejected, which is deliberate. `region` is an AWS region id such as `ap-south-1`. The reply is a RANGE, not a number: `monthly_total` has low, expected and high, because several inputs are genuinely uncertain and a single figure would hide that. `swing_factor` names the one input that most widens the range, which is the most useful sentence in the reply: it tells the user what to go and measure. `concentration` ranks the lines by share of the bill. `assumptions` lists every value that was defaulted rather than given, and `traps` lists costs this architecture usually incurs that the caller did not ask for, such as public IPv4 addresses or database storage billed apart from the database. `gaps` lists anything that could not be priced. It is never silently treated as zero. If a line is missing, the total is missing that line, and the gap says so. These are AWS on-demand list prices before any discount, credit or committed-use agreement, and they exclude tax. Treat the result as an upper bound on a real bill and never as a quote.

  ConnectorNo auth

• get_referenceA

  Cloud FinOps Skill & MCPA

  Fetch the guidance on one FinOps topic - the billing mechanics, decision rules and worked examples behind a defensible answer - either whole or one section at a time. Use this when you need the actual content of one known reference, after ``list_references`` or ``find_references`` told you which one serves the question. Advisory questions (commitment sizing, chargeback design, allocation methodology) are served by the reference's decision rules and worked examples, which a summary does not carry. Pass ``section`` when the question is narrower than the file. The ``approx_tokens`` hint in the listing tells you when this matters: the AWS pattern catalogue runs past 25,000 tokens and the pattern catalogues are enumerated lists, so a question about S3 lifecycle wants one section of ``finops-aws-patterns``, not all of it. Omit ``section`` for the whole file when you need the cross-cutting reasoning. Args: name: Reference name as returned by ``list_references`` (e.g. ``"finops-aws"``, ``"finops-genai-capacity"``, ``"optimnow-methodology"``). section: Optional H2 or H3 heading to return on its own. Matched case-insensitively and partially against the headings, so a natural phrase works - ``"storage"``, ``"commitment decision tree"``. A heading's trailing count is ignored, so ``"storage optimization patterns"`` matches ``"Storage Optimization Patterns (28)"``. If it matches nothing you get the list of available headings back, not the whole file. Without ``section``, returns ``{"name": ..., "content": "...", "lines": N}`` where ``content`` is the file verbatim. With ``section``, returns ``{"name", "title", "section", "section_level", "partial": true, "content", "lines", "full_lines"}`` where ``content`` is that section prefixed by the reference's title, plus ``other_matching_sections`` when the phrase matched more than one heading. On a miss, returns ``{"error": ..., "suggestions": [...]}``. An unknown name gives up to three string-distance matches; an unmatched ``section`` gives ``available_sections`` - every heading in the file - so the retry is exact.

  ConnectorNo auth

• get_playbookA

  Cloud FinOps Skill & MCPA

  Fetch the step-by-step runbook for one specific waste pattern: symptoms, the detection queries to run, the fix, and the anti-pattern to avoid. Use this when the user asks how to detect, confirm, or fix one specific named waste pattern (zombie NAT gateway, snapshot sprawl, idle SageMaker endpoint, ...). It also serves questions about the user's own resources ("which of my X..."): the runbook's detection query is written to be run in the user's account, so the answer does not depend on access to that account. Args: name: Playbook slug as returned by ``list_playbooks`` (e.g. ``"aws-zombie-nat-gateway"``, ``"azure-orphan-disks"``, ``"cross-cloud-untagged-spend-drift"``). Returns ``{"name": ..., "title": ..., "content": "...", "lines": N}``. On miss, returns ``{"error": ..., "suggestions": [...]}`` with up to three string-distance matches so the caller can self-correct. A host with MCP Apps (SEP-1865) support may render this result via the linked ``ui://cloud-finops/playbook-viewer`` resource instead of showing the raw markdown.

  ConnectorNo auth

• find_startup_perksA

  StartupPerksA

  Rank the startup credits, perks and deals one specific company can claim, from a catalog of 1,000+ programs (AWS Activate, Google for Startups, Microsoft for Startups, NVIDIA Inception, Anthropic, Stripe Atlas, Mercury, HubSpot and more). Use it when the user describes their own startup and asks what they can get or qualify for; use search_startup_perks to look up a provider or topic without a company profile, and get_startup_perk for one program's full terms. It checks each program's stated eligibility (stage, funding gate, raised-amount cap, company age, region) against the profile, ranks the categories the user needs first and takes each need in turn, and leaves out programs whose applications are paused or closed. Returns up to 25 programs, each with the value as the provider states it, whether the company qualifies and why, how to claim it, and links to the StartupPerks page, the provider's application and the provider's terms, plus a realistic claimable total (one program per provider, cloud counted once). Read-only; values are headline maximums, not guarantees.

  ConnectorNo auth

• create_clusterA

  OwnkubeA

  Provision a new Starter cluster (the self-hosted shape) into a verified AWS account (`cloudAccountId` from list_aws_accounts). Returns immediately with a `clusterId` and `creating` status; poll get_cluster_status until it reports `active` or `failed`. Confirm with the user before calling. Production (`clusterType: eks`) is not self-serve — tell the user to contact us to enable a Production cluster.

  ConnectorOAuth

• preview_alertA

  Costory: Your Finops MCPA

  Backtest a cost-alert condition BEFORE creating it: replays the `condition` against the last `lookbackDays` (default 45) of data and reports how many times it would have fired. Takes the same queries + condition + dedup as create_alert (no notification channel needed). The dedup window is per groupBy value; delivery stays one message listing newly eligible groups. Returns the evaluation window, `firingDays` (distinct days the condition held), `firingRows` (per-group fires), `notificationsCount` (days on which at least one newly eligible group would notify) and a sample of firing dates with per-group `state`. Use this to sanity-check a condition/threshold (and tune dedup) before calling create_alert. EXAMPLE: "Would 'alert if 7-day AWS spend tops $50k' have fired this month?" → { queries: [{ type: "cost", name: "a", metricId: "cost", currency: "USD", filterCel: "cos_provider in [\"AWS\"]" }], condition: "rollingSum(a, 7, DAY) > 50000", dedup: { kind: "CALENDAR", calendarUnit: "WEEK" }, lookbackDays: 30 }

  ConnectorOAuth

• simulation.createA

  Cloud World ModelA

  Create a temporary anonymous demo cloud simulation from a list of resources and connections (max 2 active simulations per client, up to 10 resources; the returned simulationId is a short-lived unguessable capability that survives MCP transport teardown, but it is cleaned up when the demo lifetime expires or the simulation is deleted). No API key required for this temporary anonymous demo operation. Built-in scenario workflow: call `scenario.list` and pass a returned card's `id` as `scenarioId` to `simulation.create` for server-side graph expansion. For full control, call `scenario.get` and pass its hydrated `resources` and `connections` arrays instead. These are two alternatives — do not send `scenarioId` with `resources` or `connections`. When copying a scenario graph that returns `autoscalingConfig`, pass that config to `simulation.create` too so its thresholds and cooldown are preserved. For AWS Multi-Region Failover, scenarioOverrides.awsMultiRegionFailover accepts includeRecoveryRamp (defaults true when the override is supplied), recoveryRampStartStep (absolute integer 40–100000, default 60), and dnsTtlSeconds (positive, at most 86400, default 60). Without an override the recovery ramp is inactive. Select overrides before the first simulation.step. scenario.get exposes characteristics.route53Failover: west fails at evaluation currentTime 5 after creation warm-up through 59, returns at 60; 10 simulated seconds per step, 10-second probes and three consecutive failures/recoveries. The ramp reaches 2600 RPS at step 40 and holds until recovery. For SQS Queue Backlog Saturation, set `scenarioOverrides: { sqsQueueBacklogSaturation: { includeEventBurst: true, eventBurstStartStep: 10 } }` to enable the optional 5,000 RPS burst and choose its absolute start step (integer 6–100000, after the five-step creation warm-up). Within this override, includeEventBurst defaults to true, so eventBurstStartStep alone enables the burst; without the override the burst stays inactive. Omit eventBurstStartStep to use catalog default step 6; select this scenario-only override before the first simulation.step so replay identity is unchanged. For the catalog EKS Spot Interruption Migration scenario, you may set `scenarioOverrides: { eksSpotInterruption: { startupSeconds } }` with an integer startupSeconds from 0 through 3600 to test a different readiness deadline without copying the graph; this override requires scenarioId and is mutually exclusive with resources and connections. For the Web App Autoscaling scenario, create with `scenarioId: "web-autoscaling"` and `scenarioOverrides: { webAutoscaling: { includeTrafficRecovery: true } }` to activate the optional Traffic Recovery ramp and observe scale-in. `includeTrafficRecovery` is optional and defaults to false, leaving the phase inactive. Opt in before the first simulation.step because replay identity is finalized when stepping starts. This override also requires scenarioId and is mutually exclusive with resources and connections. For Database Failover, create with `scenarioId: "db-failover"` and `scenarioOverrides: { dbFailover: { includeTrafficRecovery: true } }` to activate its optional Traffic Recovery ramp; it defaults to false. The scheduled primary-overload phase and ramp are shifted by the five-step creation warm-up. Select the override before the first simulation.step because replay identity is finalized when stepping starts. This override requires scenarioId and is mutually exclusive with resources and connections. For the Redis Cache Crash & Recovery scenario, create with `scenarioId: "redis-cache-crash-recovery"` and `scenarioOverrides: { redisCacheCrashRecovery: { cacheableRequestShare: 0.8, cacheHitRate: 0.8 } }` to set the request share sent to Redis and the configured hit rate among those requests (both fractions from 0 to 1; defaults are 0.8). The selected values are per-simulation and appear in normalizedConfig and per-step requestFlow metrics; they do not change the catalog scenario. Redis Cache Crash & Recovery starts at 5,000 RPS by default; an explicit simulation.create traffic value becomes the starting load, and the scenario has no active traffic pattern. Use simulation.inject_traffic to change load after stepping; this remains valid after replay identity finalizes. `scenario.list` returns graph-free cards with bounded active/optional traffic-phase and retry-workload summaries; it is not a source of resource, connection, traffic-pattern, or failure-injection graphs. Scenario traffic and failure presets are not applied automatically. Custom cache path: use a resource with type 'cache', characteristics.serviceFamily 'elasticache', cacheHitRate as a fraction (0.8, not 80) and optional cacheableRequestShare; connect the load balancer to each app server, each app server to the cache and to the database, and the cache to the database; use responseMode 'full' to see metrics.requestFlow. Use resilienceConfig.externalMetrics for deterministic sampled recommendations: no_ready_endpoints is successful zero only when its trigger sets noReadyEndpointsAsZero:true; discovery_error and fetch_error always remain errors. This is not a KEDA/provider actuator and does not change resource counts. Use it to start any simulation workflow — either with hydrated resources and connections from scenario.get or your own architecture. Do not use it to modify an existing simulation (use simulation.inject_traffic to change load). For the exact owned typical fit, set appWeight:'typical', location.regionKey:'us-east-2' on all four AWS nodes, one ALB with serviceFamily:'alb' and loadBalancerScheme:'internal', two m5.large compute apps with workload:'crud-typical', appRuntime:'node', appWorkerCount:2, appDbPoolSize:250, one db.r5.large MySQL with workloadDatabaseEngine:'mysql', workloadDatabaseVersion:'8.0', maxConnections:500, ALB→each app→DB connections, minInstances=maxInstances=2, autoscaling:false, traffic 20–300 RPS. Only typical-fit-20, typical-fit-100 and typical-fit-200 tuned the typical-v1-20260927c/6aa574d7ff9d3080b88b221bcd59f7d218ae37f0 fit; 300 is an independent holdout and 500 is diagnostic only. Other typical workloads are modeled, not owned. P99 has distinct per-percentile provenance: latencyP99Basis identifies the owned in-VPC internal-ALB fit, a scaled-from-fit estimate (not directly measured), or an uncalibrated generic model. On the exact healthy lean owned graph at 10–1,000 offered target RPS, P99=max(final P95, 7.021919127633514 + 0.00027013891327780484*T) ms; only 10/100/500 RPS were fit, 1,000 RPS was held out. Lean M5 scaling is not a new measurement; typical/heavy and active failures retain uncalibrated P99. predictionEvidence.latencyP99 has measured 0.65–1.35×, scaled 0.50–1.50× (beyond 1,000: 0.25–2×), or uncalibrated 0.50–2× (beyond: 0.25–3×) assumption bounds centered on final P99. These are not confidence intervals or provider measurements. Historical evidence may omit P99. latencyBasis describes the general modeled latency path; use latencyP99Basis specifically for P99. P99 is diagnostic, not scored. For compute, set characteristics.capacityRps for an explicit per-node RPS ceiling at which CPU reaches ~95%; do not use maxThroughput for that compute contract. Kubernetes rejects capacityRps: set maxThroughput for the total cluster RPS ceiling, or nodePools[].maxThroughput for per-node pool capacity. Omitted compute capacityRps uses the selected catalog tier and can intentionally produce a stressed baseline (for example, the AWS m5.large catalog denominator is 2,000 RPS); for a healthy, capacity-bounded compute experiment, declare an explicit per-node capacity such as 500 RPS. That value is an experiment control, not a universal hardware fact. For OCI flexible compute shapes, pass the documented positive integer characteristics.ocpus explicitly; VM.Standard.E4.Flex accepts 1–64 OCPUs and each OCPU maps to 2 vCPUs. OCPU count establishes capacity dimensions only, not provider-specific performance, throughput, or price. An uncounted flexible shape remains an unverified generic estimate. Check GET /api/prediction/generic-shapes for the catalog-derived generic fallback inventory. New prediction-only GCP standard capacity entries include e2-standard-2/4/8/16/32, n1-standard-1/2/4/8/16/32/64/96, and n2-standard-16/32/48/64/80/96/128; provider specifications establish vCPU/memory dimensions, not CWM performance or pricing. Version 1 predictionEvidence explicitly reports legacyGeneric at the top level and on every appCpuByResource item; its note identifies each generic resource's shape and fallback reason. For generic fixed compute, characteristics.instanceCount accepts integer 1–100 represented VMs; capacity aggregates and CPU is per VM. Do not combine it with autoscaling:true, minInstances, or maxInstances. Aurora Serverless v2 remains limited to 1 with multiAz:false or 2 with multiAz:true. For Aurora Serverless ACU limits, use characteristics.config.minCapacity/maxCapacity or flat characteristics.minCapacity/maxCapacity. The exact AWS database shape with serviceFamily: 'aurora-serverless' and size: 'db.serverless' also accepts flat characteristics.minAcu/maxAcu; those aliases are rejected elsewhere, including at the resource root or inside config. For that shape, multiAz:true with instanceCount:2 creates a separately billable reader (<writer-id>-reader) in another AZ. Inspect returned resources and metrics before using simulation.step to observe modeled failover; no AWS timing guarantee is implied. For database connection budgets, set characteristics.connectionDemand on a database: {mode:'declared',declaredConnections:240} uses that plan-time demand without RPS; {mode:'max',declaredConnections:240,idlePoolFloor:200} takes the maximum of load-derived demand and the declared/floor values; omitted configuration preserves load-derived behavior. declaredConnections and idlePoolFloor are ASSUMPTIONS / plan-time budgets (for example, replicas × per-pod pool size), not observed live DB connections. Set maxConnections to the usable limit you intend to test. Per-database metrics report connectionDemandMode, loadDerivedConnections, declaredConnections/idlePoolFloor, and modeledConnections; cost and DB CPU/latency remain based on existing load-driven behavior. Demand above the usable limit adds a bounded, rule-based pool-saturation error signal; it is not a provider-calibrated rate. Capacity, node-bound, SKU, and autoscaling values supplied through this MCP tool are recorded as agent-supplied in the immutable normalizationReceipt; request responseMode: 'full' to inspect it. Generic GKE telemetry and recovery apply only to worker nodes; the control-plane management fee is cost-only, with no modeled control-plane CPU, API throttling, or cooldown. To bound the autoscaled fleet size, set the top-level maxInstances / minInstances parameters. If you do not set maxInstances, the engine uses the provider default — AWS 50, GCP 15, Azure/OCI/DigitalOcean 10 — which may be much larger than your intended fleet size. The response includes effectiveMaxInstances / effectiveMinInstances so you can confirm the bounds that will be enforced. For a targeted CPU HPA scale-out threshold, send the canonical autoscalingTargetCpu field in this create call (for example, autoscalingTargetCpu: 70 for GKE). The compatible aliases scaleOutCpuThreshold, scaleOutCpuPercent, and autoscaleTargetCpuPercent are also accepted; if more than one is sent, their values must agree. Every create response includes hpaAudit with the supplied field, persisted thresholds, and any provider default. For ECS Fargate CPU-only target tracking, set ecsCpuTargetTracking: true, autoscalingTargetCpu, minInstances/maxInstances, and optional scaleOutCooldownSeconds/scaleInCooldownSeconds with simulationSecondsPerStep (default 1). Inspect autoscalingConfig in the compact response or applicationAutoscalingPolicy in the full response. Latency and throughput do not trigger ECS scaling in this mode. These four TOP-LEVEL fields are simulation-wide — the engine applies one CPU threshold identically to every resource's scale decision by default. To make ONE resource scale at a different CPU target than the rest of the simulation (e.g. a GKE cluster scaling out at 60% while an EC2 fleet in the same simulation scales out at 80%), set characteristics.scaleOutCpuThreshold and/or characteristics.scaleInCpuThreshold on that specific resource instead — the per-resource value wins over the simulation-wide default for that resource only. A misnamed near-miss field nested under characteristics (e.g. targetCPUUtilizationPercentage) is rejected with a 400 explaining the correct field name — it is never silently dropped and defaulted. Responses are compact by default: id, name, status, traffic, and a per-resource summary (id, name, status, cpuPercent, routedRps, availabilityState, isRoutable, and recoveryBlockedReason when provided). Pass responseMode: 'full' to get the complete simulation object instead. During a failure workflow, lower traffic to serviceable levels before calling simulation.recover_resource, then use simulation.step until the recovered resource is healthy. Recovery progress is included when applicable: recoveryProgress.state is parked, cooling_down, or healthy, and its parkWindow/cooldown objects report totalSteps, completedSteps, remainingSteps, target, and requiredSteps. Poll simulation.step until state is healthy, then use simulation.metrics to inspect the resulting state and metrics. No prerequisites. Returns the created simulation's id, which every other simulation.* tool consumes; the new simulation also becomes this session's current simulation, so subsequent per-simulation tools may omit simulationId. The likely next tool is simulation.step to advance time. Do not call api.spec to learn the simulation workflow — the tool descriptions in this session contain everything needed. Authenticate with an API key for unlimited persistent simulations.

  ConnectorNo auth

• create_counterparty_ruleA

  AgenticBooksA

  Creates (or updates) a persistent per-org rule mapping a counterparty to an account, then BACK-APPLIES it to every pending review event from that counterparty — each is properly approved (journal lines written, audit entry, ledger sync queued), not bulk edited. After this, future events from the counterparty auto-classify and never reach review. This is how you act on get_pending_by_counterparty: "categorise all my AWS as infrastructure" becomes one call. This WRITES financial data — only call it with an account you are confident in. The counterparty is matched on a normalised key, so "AWS, Inc." and "AWS EMEA" resolve to the same rule. Idempotent: re-running updates the single rule and re-approves nothing already approved. actor_id is optional — it defaults to the organisation entity, and if provided must belong to this org. GUARDRAIL (OOB approval): if the rule would back-apply to an unusually large set (many events, a large aggregate, or a large rolling-hour total across recent applies), it returns status "approval_required" and writes ONLY an approval request — YOU CANNOT BOOK IT YOURSELF; confirm:true does not bypass it. Your human gets an email and approves on the dashboard, at which point the action books automatically — do NOT retry the call; verify later by re-reading the books (e.g. get_pending_by_counterparty). If the response says the request was denied recently, do not re-ask for 24h. Small approvals apply immediately (status "applied").

  ConnectorOAuth

• check_text_for_secretsA

  TanodA

  utilpeek: Scan text for leaked secrets: API keys, tokens, private keys and seed phrases. For personal data use redact_pii; for injected instructions use check_text_for_prompt_injection. Returns every API key, token, private key or BIP-39 seed phrase in a text (AWS, GitHub, GitLab, Stripe, Slack, Google, OpenAI and other sk- keys, Hugging Face, npm, PyPI, SendGrid, Telegram, PEM and hex keys, JWTs, URL passwords), each with type, line, column, offset, confidence and a redacted preview. The secret itself is never returned: only its type, position and a redacted preview (a vendor prefix and at most 4 characters at each end; a seed phrase only its word count). Pattern-based: a clean result is no proof. Blank input is a 422 (not charged). Typically under 0.5 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/secret-scan-api.html

  ConnectorNo auth

• check_text_for_secretsA

  Tanod SecurityA

  utilpeek: Scan text for leaked secrets: API keys, tokens, private keys and seed phrases. For personal data use redact_pii; for injected instructions use check_text_for_prompt_injection. Returns every API key, token, private key or BIP-39 seed phrase in a text (AWS, GitHub, GitLab, Stripe, Slack, Google, OpenAI and other sk- keys, Hugging Face, npm, PyPI, SendGrid, Telegram, PEM and hex keys, JWTs, URL passwords), each with type, line, column, offset, confidence and a redacted preview. The secret itself is never returned: only its type, position and a redacted preview (a vendor prefix and at most 4 characters at each end; a seed phrase only its word count). Pattern-based: a clean result is no proof. Blank input is a 422 (not charged). Typically under 0.5 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/secret-scan-api.html

  ConnectorNo auth

• check_text_for_secretsA

  Tanod TextA

  utilpeek: Scan text for leaked secrets: API keys, tokens, private keys and seed phrases. For personal data use redact_pii; for injected instructions use check_text_for_prompt_injection. Returns every API key, token, private key or BIP-39 seed phrase in a text (AWS, GitHub, GitLab, Stripe, Slack, Google, OpenAI and other sk- keys, Hugging Face, npm, PyPI, SendGrid, Telegram, PEM and hex keys, JWTs, URL passwords), each with type, line, column, offset, confidence and a redacted preview. The secret itself is never returned: only its type, position and a redacted preview (a vendor prefix and at most 4 characters at each end; a seed phrase only its word count). Pattern-based: a clean result is no proof. Blank input is a 422 (not charged). Typically under 0.5 s. Price: USD 0.002. Free: 10 utilpeek calls per IP per UTC day. The submitted text is never logged or stored. Docs: https://tanod.dev/learn/secret-scan-api.html

  ConnectorNo auth

• file_readA

  Local MCPA

  Reads a plain text file from the local filesystem by its absolute path — the primary, default tool for reading a local text file (use this unless the file is a PDF, Word, Excel, or PowerPoint document, which have their own readers). Reads anywhere on this Mac — home, external disks, cloud drives, /tmp — with one exception: credential and identity locations (keychains, ~/.ssh, ~/.aws, browser logins, another user's home, Time Machine backups) are never read. Supports .txt, .md, .csv, .json, .xml, .log, .yaml, .toml and common code file types; auto-detects UTF-8 with Latin-1/Windows-1252 fallback. For files in OneDrive use onedrive_read_file, in Google Drive gdrive_read_file; for PDFs pdf_read, Word word_read, Excel excel_read.

  ConnectorOAuth