AXL MCP

AXL MCP lets AI assistants create and manage landing pages, courses, email campaigns, CRM records, and marketing workflows inside AXL.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

Get Fields Schema: Exact set of fields supported by the operation's 'fields' selector (GraphQL-like syntax: '{id, firstName, tags{id, text}}'), respecting the current admin's rights. Returns the root
Get Quiz Item Schema: Quiz/form item types and the shape of their 'SettingsJson' — a STRINGIFIED JSON object whose keys depend entirely on the item's 'Type', which the OpenAPI schema cannot show (it t
List Operations: List operations of one API module: operationId, HTTP method, path, summary. Paginated by 100. Optional 'search' filters within the module (every word must match operationId, path or s

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

AXL MCP lets AI assistants create and manage landing pages, courses, email campaigns, CRM records, and marketing workflows inside AXL. Built for growing expert businesses, it turns chat requests into real work across sales, marketing, and course delivery.

Connect your AI client to https://app.axl.tech/mcp and sign in to your AXL account.

Documentation: https://docs.axl.tech/mcp

Product overview

Watch AXL in 77 seconds: pages, courses, CRM, and automation.

Список инструментов сервера (16)

Технические названия из tools/list. Нужны только разработчикам.

get_fields_schema	Exact set of fields supported by the operation's 'fields' selector (GraphQL-like syntax: '{id, firstName, tags{id, text}}'), respecting the current admin's rights. Returns the root entity's scalar fields in full; nested entities are stubs marked expandable=true — expand one by re-calling with 'path'.
get_quiz_item_schema	Quiz/form item types and the shape of their 'SettingsJson' — a STRINGIFIED JSON object whose keys depend entirely on the item's 'Type', which the OpenAPI schema cannot show (it types the property as an opaque string). CALL THIS BEFORE creating or updating ANY form item: the server stores SettingsJson verbatim, never fills a default and never validates a key, so a guessed blob is saved with HTTP 200 and only breaks in the respondent's browser — and it must never be null or empty, not even for a separator. Without arguments returns the shared base settings, the conventions and the traps; 'category'/'search' list types; 'itemType' returns one type's full settings card with a ready-to-send example and the system contact attributes it may be bound to.
list_operations	List operations of one API module: operationId, HTTP method, path, summary. Paginated by 100. Optional 'search' filters within the module (every word must match operationId, path or summary). Module names come from capability_map (which also says what each module owns and where its traps are).
import_image_from_url	Import an EXTERNAL http(s) image into account storage (no Gemini charge). Returns image_url (+ preview). Optional sitePageId → Sites/{site}/{page}/AI; omit → account-root AI. SSRF-guarded.
capability_map	CALL THIS FIRST, before any other tool. Orientation map of the whole Admin API: the platform-wide conventions you cannot see from a schema, and six task areas — each listing what users ask for, the literal first calls that serve those requests, and the cross-module traps that would otherwise send you to the wrong module. Module names are namespace segments and several of them lie about their contents, so routing by name alone fails. Pass 'area' for that area's modules (purpose, gotcha, recipes) and its FULL trap list — the overview carries only the first two traps per area.
search_operations	Search operations across all API modules. Every word of the query must match the operationId, path, module, summary or a request-body property name (order-insensitive). Results are ranked by relevance; zero results include which words didn't match. It matches API vocabulary, not business vocabulary — if the request is phrased the way a user would phrase it, capability_map routes it faster; come here when no area fits or you already know the API's word for it.
get_extended_filter_schema	Format of extended filters ('extendedFilter' property of list filters): envelope, condition enum and filter types. Without arguments returns the full type catalog; 'search' filters it; 'filterType' returns the payload JSON schema of one type.
invoke_operation	Execute an Admin API operation through the standard HTTP pipeline (caller's token, account context and permissions apply). Success returns {success: true, body: ...}; an API error returns {success: false, errors: [{code, type, message, hint?}]} (statusCode added only when not 200); a guard refusal returns {error, details?}.
search_docs	The AXL product documentation (docs.axl.tech, the knowledge base an admin reads) — searchable, and readable in full. Use it for PRODUCT questions the API surface cannot answer: what a feature is, which flow it belongs to, what the business rules are, what the UI calls the thing the user just asked about, whether the platform can do X at all. It does NOT document the API — for operations, bodies and field semantics use capability_map / list_recipes / get_operation_schema. TWO STEPS: (1) search_docs(query="…") returns a ranked shortlist — title, UI section, the article's own summary, a matched snippet — and NOT the articles; (2) pick what looks relevant and call search_docs(slugs="slug-a,slug-b") to read those in full. Call with no arguments for the section outline, or section="CRM" to list one section. Articles are English-only.
regenerate_image	Edit/restyle an existing image; stores a NEW file and returns image_url (+ markdown preview). Does NOT patch site HTML. Billed — REQUIRES confirmSpend=true. PAGE/SITE: forPage=true + sitePageId; propose edit+quality+charge first. STANDALONE: show the new image.
list_recipes	Ready-made, VERIFIED recipes: intent -> operationId + a correct example body + notes on non-obvious conventions the schema can't show (e.g. 'a new tag is created only when id == text', or 'this endpoint adds, the *.Update endpoint replaces'). capability_map names the recipe for a task as 'recipe:<intent>' — fetch it here with search=<intent> before building that call by hand. Search is AND over every word, so ask for ONE intent per call ('upload_file', then 'create_landing_site') — bundling several returns nothing. With 'search' you get FULL recipes; without it, lightweight stubs of all recipes. A recipe that CREATES something also carries 'deadUnless': the surface a real client meets that artifact on and the connection that makes it work. Treat it as part of the job — most things here are invisible until something a visitor actually opens carries them, and the same text comes back on the invoke_operation result that creates one.
generate_image	Generate a BRAND-NEW image via Gemini; stores it and returns image_url (+ markdown preview). Billed — REQUIRES confirmSpend=true after a REAL human yes in a SEPARATE message. STANDALONE: omit sitePageId → account-root AI folder; after success SHOW the image. PAGE/SITE: forPage=true AND sitePageId=<page id> → Sites/{site}/{page}/AI; propose prompt+quality+charge first, then place the URL on the page. quality: standard/high/premium. On aiSpendExhausted: warn + Billing — do not retry.
get_scenario_node_schema	Scenario node types and the JSON schema of their polymorphic 'payload' config — the shape the OpenAPI schema cannot show (it types 'payload' as an opaque string). CALL THIS BEFORE creating or configuring ANY scenario node: the server fills a default payload only for events and listeners (every ACTION comes back null) and type-checks only 13 of 137 node types, so a guessed payload is stored with HTTP 200 and breaks at run time. Without arguments returns the graph model and workflow; 'kind'/'search'/'outputs' list node types (outputs='fail' answers "which steps can I attach error handling to?"); 'actionType' returns one node's payload schema, default payload and — critically — which link types it routes to; 'scenarioId' returns the trigger events THAT scenario accepts.
list_modules	Flat index of every Admin API module: operation count, the area it belongs to, what it owns and its known trap. This is a drill-down, NOT the entry point — call capability_map first to route a request to an area, then use this to see every module or list_operations(module) for one module's operations.
get_operation_schema	Full schema of one operation: parameters, request body (schema + example) and responses, plus 'hints' and any matching 'recipes'. Nested schemas are inlined up to depth 4; deeper objects are marked truncated. Large schemas are trimmed to fit — use section='request'/'response' to fetch one part in full.
check_scenario_node_payload	Dry-run a scenario node 'payload' against its config class BEFORE writing it: reports unknown/misspelled properties and type mismatches, and returns the normalized JSON. Read-only — nothing is created or changed. Worth calling for any node type whose get_scenario_node_schema card says validation=NONE, because there the server accepts a broken payload silently and the node only misbehaves once a contact reaches it.