Each recipe is a prompt for your MCP client, the operations it should lead to, and what to check in the result. They assume the server is set up and you have provider keys for the models you want. Reword them for your product; the useful pattern is to say what you want, what not to do yet, and what to show you.

Build and talk to a text agent

Create a Talqing text agent called “Northwind chat” that answers questions about orders, delivery and returns for an online hardware store. Pick a model from the catalog I have a key for. It must ask for an order number before promising anything. Do not publish yet — show me the config.
Expected operations: describe_schema('AgentConfig'), get_catalog, list_provider_keys, create_agent.
Validate it, publish it, then open a chat with contact key test-1, ask where order 4471 is, show me the reply, and end the chat.
Expected: validate_agent, publish_agent, create_chat, create_chat_message (returns the agent’s turn), end_chat. A chat stays open until ended. See text conversations. Check that the reply it shows you came from create_chat_message, not from the model’s guess at what the agent would say.

Add a tool that calls your API

Add a tool called lookup_order to the Northwind agent. It takes an order number, calls GET https://api.northwind.example/orders/{{args.order_number}} with an Authorization header from the workspace secret NORTHWIND_API_KEY, and returns the status and delivery date. Run it against order 4471 before attaching it.
Expected: describe_schema('ToolOperations'), create_tool, run_tool (executes the draft for real), validate_tool, publish_tool, then get_agent and update_agent with the existing tools plus the new one, then validate_agent. Check:
  • Every json_schema property has a description — it is the model’s only instruction for that argument. See schema and description.
  • The secret exists. Creating one is admin-only. See secrets.
  • tools came back with the old entries. List fields (tools, mcps, faqs, handoffs) replace whole on update.
  • The agent is republished. Publishing an agent pins each tool’s version, so publishing only the tool changes nothing live. See versions.

Create an FAQ and attach it

Create an FAQ called “Northwind store FAQ” from faq.csv (columns question, answer). Attach it to the Northwind agent alongside any FAQs it already has, and validate. Do not publish.
Expected: create_faq with the entries (up to 500 per request), get_agent, update_agent with faqs plus {"faq_id": "…"}, validate_agent. Attaching reaches callers at the next publish_agent; later entry edits (update_faq_entry, create_faq_entries) apply without a publish. See FAQs.

Put an agent on a phone number

I have a Plivo account. Connect it to Talqing, provision the trunk, show me the numbers it owns, import the Bangalore one, and assign the Northwind voice agent. Stop and tell me if anything needs doing in the Plivo console.
Expected: list_telephony_providers (the credential fields the carrier needs), create_telephony_account, provision_telephony_account, list_remote_numbers, import_phone_numbers, assign_phone_number (the agent must be published). Check:
  • import_phone_numbers returns one result per number in items; read each ok.
  • get_phone_number shows readiness: live. Other values: needs_agent, needs_carrier_setup, setting_up, error, disabled.
  • The account’s setup_steps. A step with user_confirmable: true is work in the carrier console that no API can verify; you confirm it with patch_telephony_account. Ask the agent to read the steps back to you.
Then call the number yourself. See carrier accounts and phone numbers.

Run a call campaign

Create a call batch for the Northwind agent from our Bangalore number using leads.csv: phone is the number, first_name and plan go into userdata. Asia/Kolkata, weekdays 10:00–18:00, two at a time, two attempts. Do not start it — show me the first five recipients and the total.
Expected: create_call_batch with recipients[] (each a to plus a string map that becomes the call’s userdata), timezone, calling_window, max_concurrency (1–10) and max_attempts.
One create_call_batch can place up to 10,000 billable calls. Voicemail is answered and billed unless the agent has voicemail_detection on, and every call runs the agent’s current published version, so republishing mid-batch changes the calls that follow.
How is the batch doing?
Expected: get_call_batch (counts, next_dial_at, failure_reason if it stopped itself) and list_calls with batch_id. pause_call_batch lets live calls finish; cancel_call_batch is final. See batch calling.

Debug failed calls

Read the last five failed calls on the Northwind agent and tell me why each one ended. Quote the transcript.
Expected: list_calls with agent_id and status=failed (default window: last 30 days), then get_call on each. get_call returns snapshot (ok, and issues naming each problem found), the transcript with tool calls and outputs, final userdata, latency per stage, and the tools, starting_prompt and greeting that call actually ran. Related questions: “Which close reasons are most common this week, and what did we spend per day?” uses get_observability and call_stats. Check that the explanation quotes the transcript or userdata. See debugging agents and close reasons.

Build and run an agent task

Create an agent task called “qualify-lead” with inputs company name and website. It should research the company with web search and return industry, employee_range, fit (good, weak or none) and a two-sentence rationale. Run it on Northwind Hardware and show me the trace.
Expected: describe_schema('TaskConfig'), create_task, validate_task, publish_task, run_task (waits and returns output, trace, steps used and cost). Pass task_id with task_version: "draft" to run_task to try an edit before publishing, or background: true and read it back with get_task_run.
run_task executes for real: its tools call your endpoints with your secrets, and the model spends your provider tokens.
Check that output has every declared field. Each output field’s description is the instruction for that value — fit is limited to three words only because its description says so. See inputs and output.

Working practices

  • Ask for the validation result, pasted. validate_agent, validate_tool and validate_task check rules a draft cannot show. A claim of “ready” without one of these calls behind it is unverified.
  • Ask to see the write before it is sent when it touches a list field — one missing entry silently detaches a tool or FAQ.
  • Say when to publish and when to dial. The model is instructed to wait for you on both; keep client approval prompts on as well. See permissions.

Next

Permissions

What the server cannot do, and what to approve by hand.

Prompting

Writing the system prompt your agent runs on.