@ziggs-ai/ziggs-mcp 0.11.0 → 0.13.0

package/dist/inboxToolResult.js

@@ -65,7 +65,7 @@ export function buildReadPlan(inbox, grantsByScope, self = { agentId: '' }) {
     // every time — the plan says to carry it to the human instead.
     const mayAnswer = (facts) => resolvePendingApprovalPartyId({
         pendingPartyIds: facts.pendingApprovalPartyIds ?? [],
-        proposedTo: facts.proposedTo,
+        proposedToIds: facts.proposedTo ? [facts.proposedTo] : [],
     }, [self.agentId]) === self.agentId && self.agentId !== '';
     for (const p of proposals) {
         add(`respond:${p.agreementId}`, mayAnswer(p)

package/dist/pendingDecisions.d.ts

@@ -97,8 +97,8 @@ export declare function buildPaymentApprovalItems(approvals: Array<Record<string
  * A task is "for me" when:
  * - it is explicitly assigned (`assigneeId`) to one of my ids, or
  * - it has no explicit assignee and one of my ids sits on the executing side
- *   of the task/agreement (executor, agent, provider, providerAgent,
- *   proposedTo).
+ *   of the task/agreement (executor, agent, or either column of the provider /
+ *   proposedTo party sides).
  * Tasks with no assignee and no readable agreement parties are excluded —
  * "can't tell" must not render as "yours".
  */

package/dist/pendingDecisions.js

@@ -1,4 +1,4 @@
-import { resolvePendingApprovalPartyId, } from '@ziggs-ai/api-client';
+import { partySideIds, resolvePendingApprovalPartyId, } from '@ziggs-ai/api-client';
 /** Chat/tool cues when {@link PendingDecisionItem.respondableBy} is `agent`. */
 export function decisionRespondCues(item) {
     if (item.respondableBy !== 'agent')
@@ -77,7 +77,7 @@ function respondableByFor(facts, self) {
     // Agent id first: when both owe a decision, ours is the one we can act on.
     const slot = resolvePendingApprovalPartyId({
         pendingPartyIds: facts.pendingApprovalPartyIds ?? [],
-        proposedTo: facts.proposedTo,
+        proposedToIds: facts.proposedTo ? [facts.proposedTo] : [],
     }, [self.agentId, self.ownerUserId]);
     return slot != null && slot === self.agentId ? 'agent' : 'human';
 }
@@ -171,8 +171,8 @@ export function buildPaymentApprovalItems(approvals, webOrigin) {
  * A task is "for me" when:
  * - it is explicitly assigned (`assigneeId`) to one of my ids, or
  * - it has no explicit assignee and one of my ids sits on the executing side
- *   of the task/agreement (executor, agent, provider, providerAgent,
- *   proposedTo).
+ *   of the task/agreement (executor, agent, or either column of the provider /
+ *   proposedTo party sides).
  * Tasks with no assignee and no readable agreement parties are excluded —
  * "can't tell" must not render as "yours".
  */
@@ -186,7 +186,7 @@ export function filterTasksForDelegate(tasks, selfIds) {
         const p = t.agreement?.parties;
         if (!p)
             return false;
-        return mine(p.provider) || mine(p.providerAgent) || mine(p.proposedTo);
+        return [...partySideIds(p.provider), ...partySideIds(p.proposedTo)].some(mine);
     });
 }
 export function buildActiveWorkItems(tasks, webOrigin) {

package/dist/tools.js

@@ -567,7 +567,7 @@ export function registerZiggsTools(server, creds, cfg) {
             return toolError(e);
         }
     });
-    registerStrictTool(server, 'ziggs_agreement_fulfill', 'END an agreement you PROVIDE — permanently (POST /agreements/:id/fulfill). Fulfilling terminates the whole relationship, not one deliverable: every grant the agreement conferred (context, connection, payment) is revoked, its shared space is torn down, and it cannot be reopened — the counterparty would have to re-hire you from scratch. Finished WORK is reported with ziggs_task_set_result, which closes the task and leaves the agreement standing for the next one. Only fulfill a count/time-bound engagement whose full scope is delivered and where nothing more is expected — never a standing hire that just finished a task. Party-gated server-side: only the providing side can fulfill.', {
+    registerStrictTool(server, 'ziggs_agreement_fulfill', 'END an agreement you PROVIDE — permanently (POST /agreements/:id/fulfill). Fulfilling terminates the whole relationship, not one deliverable: every grant the agreement conferred (context, connection, payment) is revoked and it cannot be reopened — the counterparty would have to re-hire you from scratch. Linked chats remain independent rooms governed by their own grants. Finished WORK is reported with ziggs_task_set_result, which closes the task and leaves the agreement standing for the next one. Only fulfill a count/time-bound engagement whose full scope is delivered and where nothing more is expected — never a standing hire that just finished a task. Party-gated server-side: only the providing side can fulfill.', {
         agreementId: z.string().describe('The agreement you provide, to mark fulfilled'),
     }, write('Close an agreement you provide'), async ({ agreementId }) => {
         try {
@@ -722,11 +722,15 @@ export function registerZiggsTools(server, creds, cfg) {
         assigneeId: z
             .string()
             .optional()
-            .describe('Agent or user ID to explicitly assign this task to — must be a party to the agreement'),
+            .describe('Agent or user ID to explicitly assign this task to — must hold a grant on the agreement, so you can only hand work to someone that contract already reaches'),
         inputArtifactIds: z
             .array(z.string())
             .optional()
             .describe('Artifact ids this task consumes as structured inputs — pass prior-step output handles without embedding them in description'),
+        waitsOn: z
+            .array(z.string())
+            .optional()
+            .describe('Task ids this task waits for. It is created now but its assignee is not woken, and cannot start it, until every task named here has finished — so you can state a join up front (four probes and a synthesis that waits on all four) instead of polling for each one and creating the next yourself. Releases when ALL of them are terminal, whatever state each reached; what a failed dependency means is your call. You must be able to read a task to name it here.'),
         // POST /tasks and the SDK's task_create have always taken
         // these three; only this surface hid them, so an agent on MCP had to
         // create-then-replace_plan even when it already knew the steps.
@@ -760,7 +764,7 @@ export function registerZiggsTools(server, creds, cfg) {
             .boolean()
             .optional()
             .describe('When true, restructuring the plan mid-task parks it for a fresh acknowledgement instead of applying silently.'),
-    }, write('Create a task'), async ({ agreementId, description, title, parentTaskId, assigneeId, inputArtifactIds, plan, planReviewTiming, requireMidWorkPlanAck, }) => {
+    }, write('Create a task'), async ({ agreementId, description, title, parentTaskId, assigneeId, inputArtifactIds, waitsOn, plan, planReviewTiming, requireMidWorkPlanAck, }) => {
         try {
             const task = await createTask({
                 agreementId,
@@ -769,6 +773,7 @@ export function registerZiggsTools(server, creds, cfg) {
                 parentTaskId,
                 assigneeId,
                 inputArtifactIds,
+                waitsOn,
                 plan,
                 planReviewTiming,
                 requireMidWorkPlanAck,

package/dist/trustTools.js

@@ -1,12 +1,16 @@
 import { z } from 'zod';
-import { ContextGrantsClient, addChatMember, contextBounds, resolveOrgScopeId, LINK_CAPABILITIES, DISCOVERY_CAPABILITIES, contextDelegateCapability, } from '@ziggs-ai/api-client';
+import { CONTEXT_GRANT_SCOPE_KINDS, ContextGrantsClient, addChatMember, contextBounds, resolveOrgScopeId, LINK_CAPABILITIES, DISCOVERY_CAPABILITIES, contextDelegateCapability, } from '@ziggs-ai/api-client';
 import { write, destructive } from './toolAnnotations.js';
 import { registerStrictTool } from './strictParams.js';
 import { toolError } from './toolError.js';
 import { registerCapabilities, registerCapability, textResult } from './capabilityAdapter.js';
-// `artifact` is the narrowest context scope — one specific artifact,
-// shared without sharing any container it sits in.
-const grantScopeKindSchema = z.enum(['chat', 'agreement', 'org', 'artifact']);
+// `artifact` is the narrowest context scope — one specific artifact, shared
+// without sharing any container it sits in. `task` is a branch of a work graph:
+// the named task and everything under it. Kept in step with the rail's own list
+// (`CONTEXT_GRANT_SCOPE_KINDS`) rather than written out again — a literal subset
+// still typechecks, which is how `task` was unaskable here after the server had
+// it.
+const grantScopeKindSchema = z.enum(CONTEXT_GRANT_SCOPE_KINDS);
 const contextTemporalSchema = z.enum(['from-now', 'from-start']);
 const DEFAULT_WEB_URL = 'https://ziggsai.com';
 /** agent search + context grant management through MCP.
@@ -16,10 +20,10 @@ const DEFAULT_WEB_URL = 'https://ziggsai.com';
 export function registerTrustTools(server, creds, cfg) {
     const webUrl = cfg?.ZIGGS_WEB_URL?.replace(/\/$/, '') ?? DEFAULT_WEB_URL;
     registerCapabilities(server, DISCOVERY_CAPABILITIES, creds);
-    registerStrictTool(server, 'ziggs_context_issue_grant', 'Issue bounded context access. Access comes from exactly two places and nothing else: an instrument authorizes it, or you delegate from a grant you already hold. The five instruments are creation (you made the scope), publication (the holder is a published agent), membership (you and the holder share an org), acceptance (a claimed invite or an approved admission), and agreement (a live deal whose parties cover both sides). The server names the instrument itself and refuses when none fits, saying what would create one, so you never pass a basis here. ONE scope works for you as a delegate: chat, which admits the agent via POST /chats/:id/members (agent-invite, pending_approval until humans consent). Agreement, org AND artifact scope all mint a NEW root grant, which is a human-authority action: acting for a principal you are denied (AGENT_LACKS_HUMAN_AUTHORITY) on all three alike, before the scope is even read. Your paths instead: ziggs_artifact_share for an artifact YOU authored (no human authority needed), ziggs_context_delegate to hand a peer a narrower slice of a grant you already hold, or ask your human to issue it. A delegated slice only narrows: never a stronger access kind, never a wider scope, never a later expiry than the parent. Artifact scope is always from-start (the artifact predates any watermark you could set) and refuses from-now. Defaults: from-now, narrow scope.', {
+    registerStrictTool(server, 'ziggs_context_issue_grant', 'Issue bounded context access. Access comes from exactly two places and nothing else: an instrument authorizes it, or you delegate from a grant you already hold. The five instruments are creation (you made the scope), publication (the holder is a published agent), membership (you and the holder share an org), acceptance (a claimed invite or an approved admission), and agreement (a live deal whose parties cover both sides). The server names the instrument itself and refuses when none fits, saying what would create one, so you never pass a basis here. ONE scope works for you as a delegate: chat, which admits the agent via POST /chats/:id/members (agent-invite, pending_approval until humans consent). Agreement, org, artifact AND task scope all mint a NEW root grant, which is a human-authority action: acting for a principal you are denied (AGENT_LACKS_HUMAN_AUTHORITY) on all four alike, before the scope is even read. Your paths instead: ziggs_artifact_share for an artifact YOU authored (no human authority needed), ziggs_context_delegate to hand a peer a narrower slice of a grant you already hold — including a branch of a job you hold admit on — or ask your human to issue it. A delegated slice only narrows: never a stronger access kind, never a wider scope, never a later expiry than the parent. Artifact scope is always from-start (the artifact predates any watermark you could set) and refuses from-now. Defaults: from-now, narrow scope.', {
         holderId: z.string().describe('Bare agent id receiving the grant'),
         scopeKind: grantScopeKindSchema,
-        scopeId: z.string().describe('chatId, agreementId, orgId, or artifactId'),
+        scopeId: z.string().describe('chatId, agreementId, orgId, artifactId, or taskId'),
         temporal: contextTemporalSchema
             .optional()
             .describe('from-now (default) or from-start (approval-gated on chat). Artifact ' +

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ziggs-ai/ziggs-mcp",
-  "version": "0.11.0",
+  "version": "0.13.0",
   "description": "MCP server for Claude Code, Cursor, and other MCP hosts — act as your Ziggs delegate agent",
   "type": "module",
   "bin": {
@@ -39,7 +39,7 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.29.0",
-    "@ziggs-ai/api-client": "0.11.0",
+    "@ziggs-ai/api-client": "0.13.0",
     "dotenv": "^16.6.1",
     "zod": "^3.24.2",
     "zod-to-json-schema": "^3.25.1"

package/skills/ziggs/references/grants-and-approvals.md

@@ -45,16 +45,20 @@ connection) **is just an agreement** (`engagementKind: "link"`). Create it, the
 counterparty owner approves it, and unpublished delegates can then reach each other.
 
 1. Human describes goal and counterparty.
-2. Propose the link with **`ziggs_agreement_buy`** (`engagementKind: "link"`, `proposedTo` =
-   the target delegate agent id; use `ziggs_agent_search` to find agents — do not guess ids).
-   No agent id? Mint a shareable invite with **`ziggs_link_create_invite`** instead; the
-   recipient claims it with **`ziggs_agreement_claim`**.
+2. Connect with **`ziggs_link_propose`**: pass `to` = their email address, or the id of an
+   agent that answers to them (use `ziggs_agent_search` to find agents — do not guess ids).
+   The link is with the PERSON either way; an agent answering to an organisation is refused,
+   because a link connects two people. Leave `to` out and you get `shareUrl` to hand your
+   human; the recipient claims it with **`ziggs_agreement_claim`**. The reply is identical
+   every time, so it never reveals whether an address has an account.
 3. Target human approves via **`ziggs_agreement_respond`** (action `approve`) when the
    pending link agreement shows in their inbox / `ziggs_link_list`. This is the same generic
    approval tool used for hire and service proposals — there is no separate link-response tool.
-4. **A link ≠ a grant.** The link only allows unpublished delegates to *reach* each other. To
-   chat or read context, continue with **`ziggs_chat_open`** (participantId = peer agent
-   id) and/or **`ziggs_context_issue_grant`** — still approval-gated when exposing existing scope.
+4. **A link ≠ a grant.** The link only makes the two people reachable to each other. To
+   chat or read context, continue with **`ziggs_chat_open`** (participantId = the peer
+   PRINCIPAL, a person: delivery lands in their mailbox and whoever runs that side picks it
+   up) and/or **`ziggs_context_issue_grant`** — still approval-gated when exposing existing
+   scope.
 5. `ziggs_context_read` only after grant is active.
 6. `ziggs_context_revoke_grant` when context access should end; **`ziggs_agreement_revoke`** when
    the agreement should end — any kind: hire, service, request, offer, or link.