Design the assistant’s capabilities

From conversation to capability

A Tool lets the AI request code. That is more powerful than giving it information.

Tools can return controlled data, read a WordPress option, send email, contact another service, or call custom WordPress code. Every enabled Tool is a promise about what visitor conversation may cause—so design the promise before filling the form.

First decide: content or capability?

Use the Knowledge Base when the visitor needs an explanation that already exists in approved content. Use Assistant or Agent instructions when you need conversational behavior, scope, or tone. Use a Tool when the assistant needs current structured data or must cause an operation outside the conversation.

Put the requirement in the right part of SmartSite

Need	Best home	Example
Explain stable approved information	Knowledge Base	Cancellation policy, service description, product manual.
Shape the way a response is handled	Assistant or specialist Agent instructions	Ask one clarifying question; do not diagnose; transfer agitation.
Return a small controlled value	Data Tool	Branch phone numbers or a reviewed set of opening hours.
Look up live information	Webhook GET	Appointment availability from an authenticated booking API.
Create a real-world side effect	Email, webhook POST, or WordPress Hook	Submit a contact request or create a CRM lead.

If a policy page answers the question, do not create a webhook to return the same text. If a visitor expects a booking to be created, do not write an instruction that merely sounds as though it can book. Capabilities should be real, narrow, testable, and observable.

Meet the five Tool types

Static DataReturns JSON you maintain inside the Tool. Controlled and predictable.

WP OptionReturns the complete value of one exact WordPress option. Read-only, but potentially highly sensitive.

Send EmailBuilds and sends an HTML email through WordPress mail.

WebhookSends GET or POST from your WordPress server to an HTTP endpoint.

WordPress HookPasses arguments to a namespaced filter implemented by a developer.

The plugin automatically frames Static Data and WP Option tools as read-only data capabilities. A GET webhook is framed as live-data lookup. Email, non-GET webhook, and WordPress Hook are framed as actions with side effects. This helps model routing, but it does not replace security at the destination.

Every common field and the job it does

Common fields shared across Tool types

Field	Who uses it	Write it this way
Function Name	Runtime and integrations identify the Tool by this unique machine name.	Use a stable lowercase name with underscores, such as submit_contact_request. Do not rename casually after workflows depend on it.
Display Name	Administrators see the human-friendly label.	Use the capability name: “Submit Contact Request,” not “Tool 3.”
Description for AI	The model decides when the Tool fits the visitor’s request.	State exact intent, boundaries, and what the result means. Never treat the description as authentication.
Chat Display Label	Visitors may see this short activity label while execution is in progress.	Use calm present-tense language such as “Checking appointment availability.” Do not claim success before the result returns.
Tool Type	Selects the implementation and its type-specific fields.	Choose by actual behavior, not by the name you want displayed.
Assign to Assistant	Limits availability to All Assistants or one configured Assistant.	Choose the narrowest useful assignment. This reduces exposure but does not identify or authorize a visitor.
Parameters	Become the model-facing argument schema and supply runtime values.	Ask only for values execution genuinely requires; define clear names, types, descriptions, and Required status.
Response Success	Supplies configured feedback around a successful execution.	Describe what completed, without overstating delivery or business acceptance.
Response Error	Supplies configured feedback when execution fails.	Give a useful next step without revealing remote bodies, credentials, or internal details.
Enabled toggle	Controls whether the saved Tool is exposed and executable at runtime.	Keep it off during review and incident response. Check installed presets immediately because presets are created enabled.

Basic and Advanced runtime do not approve actions the same way

In Basic runtime, enabled tools assigned to the active Assistant are available to the model. If the model calls a valid action Tool, the runtime can execute it during that response. There is no separate plugin-enforced visitor confirmation gate for Basic action execution. Your Tool description, required parameters, receiver validation, and careful scope are therefore critical.

In Advanced Agents runtime, tools are also connected deliberately to specialists in the published flow. Email, non-GET webhook, and WordPress Hook actions pass through the advanced action-approval policy and duplicate-action protection. The visitor can be asked for explicit approval before the side effect runs. GET webhooks are treated as live-data lookups rather than side-effect actions.

Do not design a Tool assuming every site uses Advanced Agents

Admins can switch back to Basic runtime. A Tool that is safe only because an Advanced flow asks for confirmation is not safe enough for broad Basic assignment. Narrow the Assistant assignment, receiver permissions, parameters, and action itself.

Build the smallest useful Tool

1. Write the visitor outcome. “Send a request for a callback” is testable; “handle leads” is not.
2. Choose data or action. Decide whether execution only reads or causes a change.
3. Choose the narrowest type. Prefer controlled Static Data over exposing a large WP Option; prefer a dedicated webhook over a generic automation endpoint.
4. Name and describe it. Make the Function Name stable and the AI Description specific enough to distinguish it from every other Tool.
5. Minimize parameters. Keep destinations and authorization in fixed trusted configuration, not visitor-supplied arguments.
6. Assign narrowly. Use one Assistant when only one experience needs the Tool.
7. Save and disable. If it appears enabled, switch it off before entering live destinations or testing.
8. Test safely. Use synthetic data, a sandbox inbox/endpoint, and verify the real result at the receiver.
9. Run an end-to-end chat. Test intended wording, ambiguous wording, missing information, refusal, repetition, and a request that must not trigger it.
10. Enable and observe. Monitor Chat History and the receiving system during the first production use.

A description that routes well

Weak: “Sends contact details.” This does not say whether it reads or writes, when it is appropriate, or whether general questions should call it.

Stronger: “ACTION: Submit a callback request only after the visitor explicitly asks to be contacted and provides name, valid email, and topic. Do not use this Tool to answer general contact-information questions. Success means WordPress accepted the email for sending; it does not prove delivery.”

The stronger version improves routing and honest language. Still, the destination must validate input, mail must be monitored, and Basic runtime does not gain an approval gate from description wording.

Know what Enabled really controls

Disabled Tools are filtered out of runtime definitions and rejected from normal execution. The list toggle is therefore the immediate per-Tool kill switch. It does not erase configuration or test history. Deleting is permanent and can leave an Advanced flow draft referring to a missing Tool; flow checks should then catch the broken connection before the next publish.

Tool calls are executed sequentially by the response runtime. Even so, design every action for retries and duplicate requests. A visitor can repeat a message, a network can retry, or a later conversation can request the same outcome. Receiver-side idempotency is the reliable protection.

Every production Tool should also have a named business owner and a technical owner. The business owner confirms the outcome, wording, destination, and data are still appropriate; the technical owner maintains the integration and can investigate failures. An enabled Tool with no owner will eventually become an undocumented public capability.

The creation screen

tools-overview-create

Screenshot capture pending /images/screenshots/tools/overview-create.webp

Understand and Create Agent Tools

Capture

Show the Add Tool form at the type-selection stage with all five verified tool types visible.

Show

Tool type cards, Name, Display name, Description, Progress label, Assistant, Enabled

Viewport

Desktop, 1440 × 900

Annotate

Use numbered callouts only for controls referenced in the procedure.

Redact

OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text

Choose the next workshop

• Define inputs precisely in Parameters as contracts.
• Compare Static Data and WP Option.
• Build Email, Webhook, and WordPress Hook actions.
• Review the security and incident playbook.