Skip to main content
Some PRINTOOLS operations require a separate hosted approval before execution. The selected action retains its own approval rules even when it belongs to a tool group that also contains ordinary reads.

​
When approval is required

The MCP response can contain APPROVAL_REQUIRED with a proposal ID and proposal digest. This means the requested operation has not completed. Ask the client to show the proposed action, affected record, and relevant recipients or values. Use the PRINTOOLS-hosted approval flow provided by a compatible integration. If your client shows only a proposal ID and no supported approval flow, stop and report the limitation; typing “approved” in the chat does not supply an approval claim. A hosted approval is separate from a customer’s artwork/proof review and separate from a client’s generic “allow this tool” prompt.

​
Completing the flow

  1. Review the exact proposal and account context.
  2. Approve or reject through the supported PRINTOOLS approval interface.
  3. Let the integration obtain the approval claim and resume the matching operation.
  4. Inspect the result and, where applicable, its durable operation or delivery status.
Approval is tied to the proposal. If the target or proposed input changes, use a new proposal instead of reusing an old approval. Expired or invalid claims require the supported approval flow again.

​
Delivery and asynchronous work

PDF generation, exports, and communication can return before all work is complete. Retain the returned identifiers and use the appropriate status action: Use the values returned by the server. An accepted request is not proof of completed delivery. If a response is lost, inspect existing status before creating a duplicate request. Integration authors must follow the underlying operation’s idempotency contract. Authentication · Example prompts · Troubleshooting