Gookit
An MCP client can ask Gookit to create label output through named tools. The label workflow remains explicit: choose a template, confirm the records and copies, call print, then use query to check the returned job.
The output is a job result and PDF URL, not necessarily a conversational answer. Your agent can explain that result, while the API performs the label operation.
Connect to the label tools
The label MCP endpoint is https://label-api.gookit.co/api/v1/mcp. A compatible client must support its Streamable HTTP transport and the account’s authentication method.
Our verification used direct JSON-RPC requests with a developer Bearer key. That establishes the tool path, not every AI application’s connector setup or OAuth onboarding. If you plan to use Claude or another client, verify its remote MCP support and supported authentication options separately before sharing a setup recipe.
Keep credentials in the client’s connection settings rather than in prompts. The developer account and its templates remain separate from a commerce merchant’s access path.
Inspect before producing output
The live endpoint advertised these tools in our September 20, 2026 check:
| Tool | Role in the workflow |
|---|---|
help | Read tool parameters and examples |
query | Inspect saved templates or a print job |
render | Produce a preview for a template and data |
create | Save a template |
update | Change a saved template |
delete | Delete a saved template |
print | Submit a batch and return a job ID |
Preview and print operations consume output allowance. Before invoking them, show the intended layout, selected data and number of copies. Saving or deleting templates also changes account state, so keep those actions deliberate.
Give the agent a bounded task
Use a prompt that describes the record selection and result, for example:
Use my existing 50 by 30 mm name/SKU template. Prepare two Trail Bottle labels with SKU TB-1042 and one Desk Tray label with SKU DT-2006. Show the three-label total before submitting. After approval, submit once and check that job until completed or failed. Return the PDF link without changing or deleting my templates.
The prompt is a workflow instruction, not a guarantee that every client will enforce it. Check the actual proposed tool call and your client’s confirmation controls.
The print arguments for that task have the same data shape as the HTTP API:
{ "templateId": "YOUR_SAVED_TEMPLATE_ID", "items": [ {"quantity": 2, "data": {"name": "Trail Bottle", "sku": "TB-1042"}}, {"quantity": 1, "data": {"name": "Desk Tray", "sku": "DT-2006"}} ]}After receiving the job ID, use query with resource: "job" and id set to that ID. Do not call print again just because the PDF is still processing.
Read the result rather than assuming success
Check both the MCP response and the tool result. A transport response alone does not establish that a tool succeeded. Tool errors must stop the workflow; a print result with a job ID still needs a completed job.
For pending or processing states, wait before checking again and bound the total wait. For failed output, preserve the job ID and inspect the error. If a client loses the submission response, investigate rather than automatically repeating the billable action.
Once completed, download the temporary PDF URL without attaching the developer key to the storage request. Check the label count, page dimensions and decoded identifiers before printing.
Keep product data authoritative
Have the agent obtain records from an authorized source or an explicit sample supplied by you. Text inside product names or external documents should remain data, not instructions to change templates, reveal credentials or submit extra jobs.
The tested MCP path produced the same three-label fixture as the REST tutorial. Physical printer support and any specific AI client’s full onboarding flow require their own validation.