Pushary

Propose Run Scope

propose_scope

Destructive

Request agreement on an unresolved or user-requested boundary for this session. Sends a real scope question and returns ratified, answered, contract and enforcement information. Only supported hooks can enforce file paths on path-bearing tool calls; promises are recorded but not enforced. Empty enforces means no automatic boundary checking. A contract never overrides host permissions or authorizes a separate action. The call waits at most 55 seconds; a pending proposal can be read with wait_for_answer.

Input Schema

TableJSON Schema

Name	Required	Description
`doneWhen`	Yes	What "finished" means for this run, one or two lines. Carried for the human to judge against; never enforced automatically.
`promises`	No	Boundaries that are not file paths: recipients, channels, spend limits, systems you will not open. For an agent whose work is not code (marketing, sales, support, operations), this is where the boundary goes. Shown to the user labelled "Promised, not checked" and recorded in the ledger, but NEVER enforced, because the gate judges a file path and these have none. Do not put these in allowedPaths.
`agentName`	No	Name of the agent asking, format "{Agent} - {project}".
`machineId`	No	Stable machine id, so two machines never collapse into one session.
`sessionId`	Yes	Your per-session id, as your client reports it for THIS run. Required, and it is the key the gate reads the contract back by: a value that matches no live session still returns ratified:true and enforces nothing. Never invent one, and never reuse one from another run.
`timeoutMs`	No	How long this call blocks, in milliseconds (max 55000).
`allowedPaths`	No	Globs you intend to change, e.g. ["src/*", "docs/.md"]. File paths only: a word that is not a path ("hubspot", "summer-campaign") matches no file and makes every edit read as out of scope. A bare directory is expanded for you, so "docs" also covers "docs/**". Omit or leave empty to propose no path restriction, which the user is told plainly.
`offLimitsPaths`	No	Globs you promise not to touch, e.g. [".env", "infra/"]. These win wherever they overlap allowedPaths. A leading "/" needs a directory before it, so "/.env" is expanded for you to also cover a root ".env".

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Present only when the scope is not in force, saying what to do instead of proceeding.
`value`	No	The raw answer behind ratified, "yes" or "no".
`status`	No	The underlying scope-question state.
`answered`	Yes	True when the user responded at all. Answered but not ratified means they declined, so ask what scope they want rather than proceeding.
`contract`	Yes	The scope as it is STORED and gated, echoed back so you and the server hold the same contract. Paths are the EXPANDED ones: a bare directory and a leading "**/" each gain the variant they would otherwise have missed, so this can contain more entries than you sent. The user was shown the paths you sent, because the added twin says the same thing to a reader; the expansion only changes what the matcher covers, never what it means.
`enforces`	Yes	What this contract CONTAINS that can be checked, not a promise about what the gate on this machine will do. An EMPTY array means nothing here is checked automatically: the contract is a recorded promise, and every action stays governed by the permission policy exactly as it was before. Never tell the user a boundary is enforced when this is empty.
`hookSeen`	No	Whether any agent hook has actually reported this sessionId. FALSE means the gate will look this contract up under a key that does not exist, so nothing will be checked no matter what ratified says: fix the session id rather than proceeding as if a scope were in force. ABSENT means the check could not run, which is not evidence either way.
`ratified`	Yes	True only on an explicit yes. The contract is in force for this session only when this is true; anything else means proceed as if no scope was agreed.
`nextAction`	No	Keep waiting with the same correlationId while the proposal is pending. Follow handoffAction first when present; a poll ending does not expire or cancel the proposal.
`correlationId`	Yes	Id of the scope question. Keep waiting with this id while the question is pending.
`handoffAction`	No	Race-safe directive for updated clients. Takes precedence over nextAction.
`enforcementNote`	No	Present only when there is something true to say about the limits of this contract. Repeat it to the user rather than paraphrasing it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

changedOutput schema / properties / nextAction / description

Previous value: -"Poll one live question once; otherwise ask in the current chat whether to continue without an enforced scope."New value: +"Keep waiting with the same correlationId while the proposal is pending. Follow handoffAction first when present; a poll ending does not expire or cancel the proposal."

Changed1 schema field changedOct 6, 2026

changedOutput schema / properties / correlationId / description

Previous value: -"Id of the scope question. Pass it to wait_for_answer once when the first wait times out."New value: +"Id of the scope question. Keep waiting with this id while the question is pending."

Changed12 schema fields changedSep 20, 2026

changedInput schema / properties / allowedPaths / description

Previous value: -"Globs you intend to change, e.g. [\"src/**\", \"docs/*.md\"]. Omit or leave empty to propose no path restriction, which the user is told plainly."New value: +"Globs you intend to change, e.g. [\"src/**\", \"docs/*.md\"]. File paths only: a word that is not a path (\"hubspot\", \"summer-campaign\") matches no file and makes every edit read as out of scope. A bare directory is expanded for you, so \"docs\" also covers \"docs/**\". Omit or leave empty to propose no path restriction, which the user is told plainly."

changedInput schema / properties / offLimitsPaths / description

Previous value: -"Globs you promise not to touch, e.g. [\"**/.env*\", \"infra/**\"]. These win wherever they overlap allowedPaths."New value: +"Globs you promise not to touch, e.g. [\".env*\", \"infra/**\"]. These win wherever they overlap allowedPaths. A leading \"**/\" needs a directory before it, so \"**/.env*\" is expanded for you to also cover a root \".env\"."

addedInput schema / properties / promises

Added value: +{
+  "description": "Boundaries that are not file paths: recipients, channels, spend limits, systems you will not open. For an agent whose work is not code (marketing, sales, support, operations), this is where the boundary goes. Shown to the user labelled \"Promised, not checked\" and recorded in the ledger, but NEVER enforced, because the gate judges a file path and these have none. Do not put these in allowedPaths.",
+  "items": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

changedInput schema / properties / sessionId / description

Previous value: -"Your per-session id. Required: a scope with no session cannot be enforced, and must never leak into another run."New value: +"Your per-session id, as your client reports it for THIS run. Required, and it is the key the gate reads the contract back by: a value that matches no live session still returns ratified:true and enforces nothing. Never invent one, and never reuse one from another run."

changedOutput schema / properties / contract / description

Previous value: -"The scope exactly as it was put to the user, echoed back so the agent and the human are holding the same contract."New value: +"The scope as it is STORED and gated, echoed back so you and the server hold the same contract. Paths are the EXPANDED ones: a bare directory and a leading \"**/\" each gain the variant they would otherwise have missed, so this can contain more entries than you sent. The user was shown the paths you sent, because the added twin says the same thing to a reader; the expansion only changes what the matcher covers, never what it means."

changedOutput schema / properties / contract / properties / allowedPaths / description

Previous value: -"Globs the run may change. Empty means no path restriction was proposed, which the user was told plainly."New value: +"Globs the run may change, after expansion. Empty means no path restriction was proposed, which the user was told plainly."

changedOutput schema / properties / contract / properties / offLimitsPaths / description

Previous value: -"Globs the run promised not to touch. These win wherever they overlap allowedPaths."New value: +"Globs the run promised not to touch, after expansion. These win wherever they overlap allowedPaths."

addedOutput schema / properties / contract / properties / promises

Added value: +{
+  "description": "Non-path boundaries as the user saw them. Recorded, never enforced.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / enforcementNote

Added value: +{
+  "description": "Present only when there is something true to say about the limits of this contract. Repeat it to the user rather than paraphrasing it.",
+  "type": "string"
+}

addedOutput schema / properties / enforces

Added value: +{
+  "description": "What this contract CONTAINS that can be checked, not a promise about what the gate on this machine will do. An EMPTY array means nothing here is checked automatically: the contract is a recorded promise, and every action stays governed by the permission policy exactly as it was before. Never tell the user a boundary is enforced when this is empty.",
+  "items": {
+    "enum": [
+      "paths"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / hookSeen

Added value: +{
+  "description": "Whether any agent hook has actually reported this sessionId. FALSE means the gate will look this contract up under a key that does not exist, so nothing will be checked no matter what ratified says: fix the session id rather than proceeding as if a scope were in force. ABSENT means the check could not run, which is not evidence either way.",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "correlationId",
-  "ratified",
-  "answered",
-  "contract"
-]New value: +[
+  "correlationId",
+  "ratified",
+  "answered",
+  "enforces",
+  "contract"
+]

Changed5 schema fields changedAug 24, 2026

addedOutput schema / properties / correlationId

Added value: +{
+  "description": "Id of the scope question. Pass it to wait_for_answer once when the first wait times out.",
+  "type": "string"
+}

addedOutput schema / properties / handoffAction

Added value: +{
+  "description": "Race-safe directive for updated clients. Takes precedence over nextAction.",
+  "enum": [
+    "cancel_then_ask_in_current_client",
+    "stop"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / nextAction

Added value: +{
+  "description": "Poll one live question once; otherwise ask in the current chat whether to continue without an enforced scope.",
+  "enum": [
+    "wait_for_answer",
+    "ask_in_current_client"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / status

Added value: +{
+  "description": "The underlying scope-question state.",
+  "enum": [
+    "answered",
+    "pending",
+    "cancelled",
+    "expired",
+    "missing",
+    "unavailable",
+    "notified",
+    "terminal",
+    "stopped"
+  ],
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "ratified",
-  "answered",
-  "contract"
-]New value: +[
+  "correlationId",
+  "ratified",
+  "answered",
+  "contract"
+]

Changed1 schema field changedAug 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "answered": {
+      "description": "True when the user responded at all. Answered but not ratified means they declined, so ask what scope they want rather than proceeding.",
+      "type": "boolean"
+    },
+    "contract": {
+      "additionalProperties": false,
+      "description": "The scope exactly as it was put to the user, echoed back so the agent and the human are holding the same contract.",
+      "properties": {
+        "allowedPaths": {
+          "description": "Globs the run may change. Empty means no path restriction was proposed, which the user was told plainly.",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "doneWhen": {
+          "description": "What finished means for this run, as the user saw it.",
+          "type": "string"
+        },
+        "offLimitsPaths": {
+          "description": "Globs the run promised not to touch. These win wherever they overlap allowedPaths.",
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "allowedPaths",
+        "offLimitsPaths",
+        "doneWhen"
+      ],
+      "type": "object"
+    },
+    "note": {
+      "description": "Present only when the scope is not in force, saying what to do instead of proceeding.",
+      "type": "string"
+    },
+    "ratified": {
+      "description": "True only on an explicit yes. The contract is in force for this session only when this is true; anything else means proceed as if no scope was agreed.",
+      "type": "boolean"
+    },
+    "value": {
+      "description": "The raw answer behind ratified, \"yes\" or \"no\".",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ratified",
+    "answered",
+    "contract"
+  ],
+  "type": "object"
+}

First observedJul 29, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: promises are recorded but never enforced, empty enforcement means no automatic checking, contracts never override host permissions, and the call blocks up to 55 seconds. It does not, however, explain the destructiveHint=true / idempotentHint=false profile — what state is altered or that a re-proposal is not idempotent — leaving a gap for a mutation-flagged tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first sentence and every subsequent sentence carries enforcement or routing information rather than filler. It is dense and slightly prose-heavy for a five-sentence block, but nothing reads as wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not detail returns, yet it names the key return fields (ratified, answered, contract, enforcement) to orient the agent. Combined with the rich annotations and schema, the only omission is the meaning of the destructive flag.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter thoroughly, including the enforcement semantics of allowedPaths, promises and offLimitsPaths. The description only reinforces the 55-second timeout already encoded as maximum 55000, adding no new syntax or semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Request agreement on an unresolved or user-requested boundary for this session'), making it clearly a scope-contract proposal rather than a generic question. It is distinguishable from ask_user by being boundary-specific, but it never explicitly contrasts itself with that nearest sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger ('an unresolved or user-requested boundary for this session') and routes the agent to a sibling for the follow-up case ('a pending proposal can be read with wait_for_answer'). It stops short of stating when a plain ask_user would be the better choice instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Pushary tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?