@integrity-labs/cloud-broker 0.4.3 → 0.4.4

package/dist/index.js

@@ -21249,7 +21249,7 @@ server.tool(
 );
 server.tool(
   "request_access",
-  'Request scoped, TTL-bounded AWS credentials for the current task. agent_id and run_id are optional \u2014 the broker fills them from the host MCP env (AGT_AGENT_ID / AGT_RUN_ID). Only pass them explicitly to attribute the grant to a different agent or run. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason? }. status="active" means credentials are ready; status="denied" means the request was rejected (denial_reason explains). status="pending" means approval is still outstanding \u2014 always check notification_status before deciding what to do next: "sent" means the Slack approval message reached the configured channel and poll_grant is appropriate; "failed" means the notification did NOT reach a human (typically channel_not_found because the bot is not a member of the approval channel) \u2014 quote grant_id + notification_failure_reason and recommend manual escalation instead of silently polling.',
+  'Request scoped, TTL-bounded AWS credentials for the current task. agent_id and run_id are optional \u2014 the broker fills them from the host MCP env (AGT_AGENT_ID / AGT_RUN_ID). Only pass them explicitly to attribute the grant to a different agent or run. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason?, notification_status?, notification_failure_reason? }. status="active" means credentials are ready, use them now. status="denied" means the request was rejected (denial_reason explains). status="pending" means approval is still outstanding \u2014 DO NOT poll. The broker pushes the resolution to you via direct-chat the moment a human approves or denies, so save the grant_id, return control, and resume when the inbound message arrives. Only check notification_status if you need to flag a setup issue to the user: "sent" means a human was paged; "failed" or "not_attempted" means no human was paged (typically channel_not_found because the approval-bot is not a member of the configured channel) \u2014 quote grant_id + notification_failure_reason and recommend manual escalation. poll_grant exists as an escape hatch for explicit re-checks but the autonomous flow does not need it.',
   requestAccessShape,
   async (args) => {
     try {
@@ -21263,7 +21263,7 @@ server.tool(
 );
 server.tool(
   "poll_grant",
-  'Single-shot status check for a grant. Use this when request_access returned status="pending"; back-off ~10s between polls. Returns { grant_id, status, secret_ref?, expires_at?, denial_reason? }.',
+  "Single-shot status check for a grant. The broker pushes resolution updates to you via direct-chat automatically \u2014 you do NOT need to poll in the normal flow. Use this only as an escape hatch: explicit re-check after a notification, or if you suspect a notification was lost (e.g. you got `request_access` returning pending more than ~5 minutes ago and have heard nothing). Returns { grant_id, status, secret_ref?, expires_at?, denial_reason? }.",
   pollGrantShape,
   async (args) => {
     try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@integrity-labs/cloud-broker",
-  "version": "0.4.3",
+  "version": "0.4.4",
   "description": "Cloud Access Broker — MCP server that mints scoped, TTL-bounded cloud credentials per agent task. v1 ships AWS support (request_access, poll_grant, release_access, describe_scope, preview_request — STS AssumeRole under the hood); GCP, Azure, and Cloudflare land alongside in the same package as the broker grows.",
   "type": "module",
   "bin": {