Tool Presets, Testing, and Enablement
The bundled presets are Contact Information, Business Hours, and Contact Request. They are templates, not verified facts about your organization.
Presets create editable starter tools; they do not discover facts about the website. Contact Information begins with blank contact values, Business Hours contains example hours, and Contact Request points to the WordPress administrator email. Every installed preset must therefore be opened, corrected, tested, and deliberately enabled.
A reliable setup moves from install a preset from the wizard or tools screen to the point where you enable and monitor the first production calls. The controls below explain the decisions along that path, including settings that support the conversation without changing the model’s answer directly.
What this feature does and when to use it
Section titled “What this feature does and when to use it”Use a preset to save setup time while retaining full responsibility for destinations and content.
Use this feature in the following situations:
- You want a safe starting structure for public contact details or opening hours.
- You need a basic contact-request email schema and will replace the destination/template.
- You are training administrators on the disabled-test-enable lifecycle.
Where to find it
Section titled “Where to find it”Before you begin
Section titled “Before you begin”- SmartSite Assistant is installed and activated.
- You are signed in with an account that can manage WordPress options.
Set it up step by step
Section titled “Set it up step by step”- Install a preset from the wizard or Tools screen.
- Open the new tool before enabling it.
- Replace all sample phone, email, address, URL, opening-hour, and destination values.
- Review the description, progress label, assistant assignment, parameters, and messages.
- Test Static Data without personal data; test Contact Request only with a controlled inbox.
- Inspect the returned result and real side effect.
- Enable and monitor the first production calls.
Fields, controls, and important values
Section titled “Fields, controls, and important values”Presets are starting examples, not finished business configuration. Testing shows what the saved tool actually returns or changes before the model is allowed to use it. A clean, focused result gives the AI useful context; an oversized or confusing result can make replies worse. Action tests may have real side effects, so use synthetic data and controlled destinations.
| Field, control, or status | What SmartSite Assistant does with it | How to use it and why it matters |
|---|---|---|
| Contact Information | Static data starter with blank phone/email/address and a /contact path. | “Contact Information” contributes to a real outgoing email, so begin with synthetic values and a controlled mailbox. Check substituted addresses and content, then confirm actual delivery; WordPress accepting the request does not mean the recipient received it. |
| Business Hours | Static starter: Monday–Friday 9:00–17:00 and weekends Closed. These are samples. | Keep the tool associated with “Business Hours” disabled while checking valid, missing, malformed, and repeated inputs. Enable it only when the model description is narrow and the complete result cannot reveal or change anything beyond the approved purpose. |
| Contact Request | Email starter sent to admin_email, with required name/email/topic and optional message. | Set “Contact Request” with privacy and abuse in mind. Keep recipients server-controlled where possible, validate any model-supplied value, and test the complete message because a successful tool call may still be filtered or misrouted by mail systems. |
| Test | Runs the saved implementation with supplied JSON arguments; action tests have real side effects. | “Test” can influence when the model calls a tool or what context the call returns. Inspect the entire output—not just the friendly answer—and make the implementation safe before exposing the definition to normal conversations. |
| Enabled | Runtime exposure control; leave off until test evidence is acceptable. | Treat “Enabled” as an availability decision, not a reset. Check what the feature will read or expose before enabling it, and remember that switching it off normally preserves the values for later use. |
How to confirm it is working
Section titled “How to confirm it is working”The reliable proof for Tool Presets, Testing, and Enablement is the observable result described above. Reproduce it with a realistic example; if only the admin screen changed, continue tracing the workflow until the visitor or connected system sees the intended effect.
Practical example
Section titled “Practical example”Change the Business Hours preset to seasonal hours and verify the raw JSON before exposing it.
Recommended practice
Section titled “Recommended practice”- Change one part of Tool Presets, Testing, and Enablement at a time and keep a short record of the previous value and test result.
- Use synthetic arguments and inspect the complete raw result before letting the model call the tool in visitor conversations.
Important warnings
Section titled “Important warnings”Common problems and focused checks
Section titled “Common problems and focused checks”| Problem | What to check and what to do next |
|---|---|
| Preset says installed but is not usable. | Open Tools, edit the preset, supply required values, save, test, and enable it. |
| Test inputs are rejected. | Provide valid JSON matching parameter names and string/number/boolean types. |
| Tool Presets, Testing, and Enablement is missing or does not match this guide. | Confirm the plugin is active and the account can manage WordPress options. Keep the tool disabled while comparing its schema, arguments, implementation result, and any side effect. |
| A change on Tool Presets, Testing, and Enablement does not produce the expected result. | Keep the exact notice and test case, then review the browser console and WordPress/PHP log. Keep the tool disabled while comparing its schema, arguments, implementation result, and any side effect. |
Screen reference
Section titled “Screen reference”- Capture
- Show the three preset cards with Contact Information installed and the other two available; no real organization data.
- Show
- Preset names, summaries, Installed/Install states, warning copy
- 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