Five

Showing 25 of 106 from the live probe.

• List Databases

  List the databases configured for the application. Returns databaseKey needed for create_table.

• List Tables

  List all tables (data sources) in the application. PREFER get_app_overview — it ALREADY includes every table plus forms, queries, data views, functions, processes, menus, and roles in ONE response. Calling both list_tables AND get_app_overview back-to-back is the most common Phase 1 redundancy (~50KB wasted per build). Only call list_tables on its own when get_app_overview's full response would be wasteful for what you need (rare — it's no more expensive than list_tables in practice).

• List Forms

  List all forms in the application. Returns formKey, formId, and title for each form. Use formKey as referenceFormKey on lookup fields, as linkFormKey on linked list pages, and with update_form to add or change help text on an existing form.

• Get App Overview

  ═══ ⚠ NARRATION DISCIPLINE — ONE SENTENCE BEFORE EVERY TOOL CALL ═══ Before EACH tool call you make in this build — every one, not just "important" ones — emit a single sentence of plain text stating what you're about to do: the tool name and the key piece of context (a key UUID, a primary argument, an intent). Examples: - "Creating the dashboard module with moduleId='AdminDashboard'." - "Calling batch_create_landing_pages with 4 entries — one per role section." - "Re-running audit_build to ve

• List Roles

  List all roles in the application. Returns roleKey and name for each role. roleKey is needed for set_permissions, set_role_security, assign_menu, and create_user.

• Update Help Text

  Update help text on an application, any number of forms, and any number of data views — all in a single sequential call. ALWAYS use this tool when adding help text to an existing app. NEVER call update_application, update_form, update_data_view, batch_update_forms, or batch_update_data_views separately — the Five server has a single system transaction and any parallel calls to those tools cause a UNIQUE constraint failure on iAction_.iVersionKey. This tool processes everything sequentially to a

• Update Application

  Update application settings: help text, help URL, menu layout (userInterface), or lifecycle hook functions (doLogon etc). Only use this when updating the application alone with nothing else. If updating any forms or data views at the same time, use update_help_text instead to avoid server transaction conflicts. MENU LAYOUT (userInterface): Sets iApplication.DefaultUserInterface. Three valid values: "BOS" (Boston — LEFT SIDEBAR menu, the layout most often requested by name), "JFK" (top tabs, the

• Update Form

  Update an existing form's attributes in isolation. Use this when updating exactly one form and nothing else simultaneously. If updating multiple forms / application / data views at the same time, use update_help_text instead (parallel calls cause a UNIQUE constraint failure). DATA FILTER: the dataFilter parameter writes to iForm.DataFilter — a SQL WHERE clause appended to every form-data read. Supports {{five.stack.<DataSourceID>.<PrimaryKey>}} substitution (drawn from per-session security stac

• Batch Update Forms

  Update forms in batches. Same per-item semantics as update_form (helpText, helpURL, dataFilter, listOrder, readOnlyIf, and the form-trigger *FunctionKey fields — each optional, omit to leave unchanged). Trigger fields accept a functionKey GUID or FunctionID name; "" clears; On* run client-side, Do* run server-side (five.field/five.form/five.selectAction rejected there — use context.new/context.old). DEFAULT BEHAVIOR: include EVERY form that needs updating in ONE call. A post-build DataFilter sw

• Update Form Page

  Update attributes on a single form page in isolation. Only use this when updating exactly one page and nothing else simultaneously. If fixing page order across multiple forms, use batch_update_form_pages instead — parallel calls cause a UNIQUE constraint failure on the Five server.

• Batch Update Form Pages

  Update page order or caption on multiple form pages in a single call, processed sequentially. Always use this instead of calling update_form_page multiple times — parallel calls cause a UNIQUE constraint failure on iAction_.iVersionKey in the Five server. Typical use: fixing General (F-type) pages to appear before Loans (L-type) pages across several forms.

• Update Form Field

  Update one form field from a PREVIOUS session. NEVER use during the current build (batch_create_forms applies all properties at creation). PREFER batch_update_form_fields when updating 2+ fields — see that tool for the LOOKUP VARIANTS guide. This tool is for ONE isolated field change post-build.

• Batch Update Form Fields

  Update attributes on form fields that were created in a PREVIOUS session. NEVER call this during the current build — batch_create_forms already applies displayType, fieldData, defaultValue, showIf, readOnlyIf, isLookup, referenceFormKey, includeInList, and all trigger keys at creation time. If you find yourself wanting to call this after batch_create_forms, you forgot to set properties at creation — but do NOT fix it here, the properties are already applied. This tool exists ONLY for editing exi

• List Data View Fields

  List all data view fields for the application, including their dataViewKey, fieldIds, and captions. Use this to discover which data views exist and their keys.

• List Queries

  List all queries in the application including their SQL. Returns queryKey (same as dataSourceKey — use when binding a data view), queryId, and sql for each query. Use this to inspect or verify query SQL without having to run it.

• List Users

  List all users for the application. Returns userKey, userId, fullName, email, roleKey, userRecordKey, enabled, and locked for each user. Passwords are never returned.

• List Menus

  List all menu items for the application. Returns menuKey, menuId, caption, menuOrder, parentMenuKey (empty if top-level), and actionKey (the form/data-view this item links to). Use menuId with assign_menu.

• List Form Pages

  List all form pages for the application. Returns formPageKey, formKey, pageId, caption, pageType (F=data, L=linked list, A=embedded action, J=join, G=grid), pageOrder, and linkFormKey (for non-F pages). Use formPageKey with update_form_page.

• List Form Fields

  List all form fields for the application. Returns formFieldKey, formKey, fieldId, and caption for every field on every form. ONLY use this when modifying forms from a PREVIOUS session — during the current build, batch_create_forms already returns fieldKeys and applies all properties at creation time. Do NOT call this to 'verify' or 'polish' forms you just created.

• List Data Views

  List all data views in the application. Returns dataViewKey, dataViewId, and title for each data view. Use dataViewKey with update_data_view to add or change help text on an existing data view.

• List Themes

  List all themes available for the application. Returns themeKey and name for each theme. NOTE: list_themes returns NAMES ONLY — it does NOT return color values. To get the active theme's palette + typography (which every visual artifact must reference for cohesion), use get_active_theme instead.

• Set Theme

  Apply a theme to the application's default instance. Use list_themes first to see the available themes and their keys. After applying, call get_active_theme to read the palette values for use in Modules / Reports / Landing Pages.

• Set Application Logo

  Set the application's logo and/or small logo. These are the brand marks the platform shows in three places: • Sidebar header (large logo when the navigator is expanded, small logo when collapsed) • Sign-in / login page (large logo above the credentials form) • Report PDF headers via the {{logo}} and {{smallLogo}} Handlebars tokens ═══ FORMAT ═══ Pass a complete data URL string: `data:image/<type>;base64,<base64-encoded-bytes>` — e.g. `data:image/png;base64,iVBORw0KGgo...`. Supported MIM

• Get Active Theme

  Return the active theme's palette + typography for the application. THIS IS A RE-ENTRY TOOL: create_theme and update_theme responses ALREADY contain this exact payload, so during a build you should never need it — cache the create_theme/update_theme response instead. Call get_active_theme ONLY when you need the theme and have no cached response: modifying an app in a fresh session, or after set_theme switched to a theme you haven't seen. Call it AT MOST ONCE and cache the response in your workin

• Create Theme

  Create and optionally apply a theme. TWO ENTRY POINTS — pick the one that matches what the user actually said: • USER NAMED BRAND COLOURS → use `palette` + `chrome` with their hex codes directly. THIS IS THE PRIMARY PATH. • USER ONLY DESCRIBED A VIBE (no colours) → pick a `mood` from the curated list. Fallback path. Your #1 job is to make the app match the customer's actual brand. Moods are high-quality fallbacks when the brief is silent on colour — they are NOT a substitute for the colour