mcp-server-kilango
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HTTP_TOKEN | No | Token protecting the loopback /mcp endpoint | |
| KILANGO_API_KEY | Yes | A shared, workspace-bound API key (hub_live_... key) that self-scopes to one workspace | |
| KILANGO_AUDIT_LOG | No | Path for the audit log | |
| KILANGO_API_BASE_URL | No | The base URL of the Kilango API gateway | |
| KILANGO_ENABLE_WRITES | No | Coarse kill-switch for write operations | |
| KILANGO_PUBLIC_BASE_URL | No | The public base URL of Kilango |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kilango_get_workspaceA | Return the workspace this connector is bound to, plus the key role/scopes. Call this first to confirm which workspace and what capability (read vs write, ADMIN) you have. |
| kilango_get_metaA | Return server/tenant metadata for the connected workspace. |
| kilango_get_vocabularyA | Return tenant data to fill argument values: brands, portals, personas, installed apps (with their widget keys), and connected providers. Use this to discover valid ids before creating or editing. |
| kilango_search_operationsA | Search the full operator API contract (from /v1/openapi.json) for operations not covered by a curated tool. Returns operationIds usable with kilango_call_operation. |
| kilango_describe_operationA | Return the method, path, path/query params, whether it needs If-Match, and whether it is a write for a given operationId. Use before kilango_call_operation. |
| kilango_list_portalsA | List portals in the workspace. Optional filters: kind, status, brandId, q (free text). Paged with cursor. |
| kilango_get_portalA | Fetch one portal by uuid or slug. Returns counts, domains, urls, navigation, theme overrides, and the navigation ETag. |
| kilango_create_portalA | Create a portal in a brand. With seedHomePage (default true) it gets an "overblik" page + a navigation entry and starts as DRAFT with a preview token. Slug is not editable after creation. |
| kilango_update_portalC | Update a portal (name / kind / defaultPersonaId). Slug cannot be changed. |
| kilango_get_portal_readinessA | Return { ready, blockers[], warnings[] } for a portal. Each problem carries a code and whether it is overridable. Check before publishing. |
| kilango_publish_portalA | Publish a portal (idempotent). Pass force=true to publish despite overridable readiness blockers. |
| kilango_unpublish_portalB | Take a portal offline (back to DRAFT). |
| kilango_archive_portalC | Archive a portal. Requires an ADMIN key. |
| kilango_get_portal_previewB | Return { previewUrl, token } for previewing a DRAFT portal. |
| kilango_get_portal_navigationB | Return the portal navigation tree { navigation, etag }. The etag is needed to save navigation. |
| kilango_save_portal_navigationA | Replace the portal navigation tree (whole-document write). Each entry is { pageSlug, label, icon? }. The current ETag is fetched and sent as If-Match automatically; a concurrent change makes it retry once. |
| kilango_delete_portalA | Delete a portal. Requires an ADMIN key. Refuses if it has pages or accesses unless force=true. |
| kilango_list_pagesA | List the pages of a portal, ordered by sortOrder. |
| kilango_get_pageB | Fetch one page (by slug or id) including its layout. |
| kilango_get_page_blocksB | Return the ordered blocks of a page. Each block has a stable blockId; app-widget blocks carry a widgetInstanceId. |
| kilango_create_pageA | Create a page in a portal. sortOrder controls page order in navigation. Layout is added separately with kilango_save_page_layout / kilango_add_content_block. |
| kilango_update_pageC | Update a page (title / sortOrder / visibility). |
| kilango_delete_pageB | Delete a page. Requires an ADMIN key. |
| kilango_save_page_layoutA | Replace the whole page layout (a Puck payload { root, content: [...] }). Whole-document write: the current ETag is fetched and sent as If-Match automatically. Preserve each app-widget block's widgetInstanceId verbatim, or the widget row is recreated. |
| kilango_add_content_blockA | Add a Hub-native content block (e.g. Heading, RichText, WidgetGrid) to a page at an optional position (at most one of index/before/after). |
| kilango_update_content_blockC | Update a content block's props and/or move it (position). Position is at most one of index/before/after. |
| kilango_delete_content_blockB | Remove a block from a page. |
| kilango_place_widgetA | Place an app widget on a page. The app must be installed AND activated in the portal first (otherwise the app_not_activated_in_portal error names the fixing call). Visual position follows the widget's renderRole tier — read the returned rendering note; index 0 is not necessarily top of page. |
| kilango_update_widgetB | Update an app-widget block's config and/or position. |
| kilango_delete_widgetC | Remove an app-widget block from a page. |
| kilango_move_blockA | Move one block to a new position (index, or before/after another blockId). Fetches the current order, computes the complete permutation, and calls reorder with If-Match. Position within a render tier follows the widget renderRole, so the visual result may differ from the array index — read the rendering note. |
| kilango_reorder_blocksA | Set the full block order on a page. |
| kilango_list_catalog_appsA | List installable apps with their manifests (appClass, authMode, connectionFields, widgets). |
| kilango_get_catalog_appA | Return one app manifest: appClass, authMode (apikey/oauth), the connectionFields a human must supply, and its widgets (widgetKey + renderRole). |
| kilango_list_connectorsC | List providers and their scope capabilities. |
| kilango_list_app_installationsA | List apps installed in the workspace. |
| kilango_get_app_installationB | Return the installation record (pinned manifest version, config, status) for one app. |
| kilango_install_appA | Install an app into the workspace (idempotent; pins the manifest version). Installing does NOT make it visible — activate it per portal with kilango_activate_app_in_portal. For apps that need credentials, use kilango_connect_app instead. |
| kilango_uninstall_appA | Uninstall an app from the workspace. Requires an ADMIN key. Cascades: removes its widgets from all pages. |
| kilango_list_portal_appsA | List which installed apps are activated in a given portal. |
| kilango_activate_app_in_portalB | Activate an installed app in a portal (precondition for placing its widgets). Optional per-portal config. |
| kilango_deactivate_app_in_portalC | Deactivate an app in a portal. Cascades widget removal within that portal. |
| kilango_connect_appA | Install and connect an app to its backend. For apps that need credentials (API key), returns a one-time browser URL where the operator enters the secrets — they go straight to Kilango's vault, never through this chat. Apps without credentials are installed (and activated if a portal is given) immediately. OAuth apps are not connectable yet. |
| kilango_list_connectionsA | List the workspace's backend connections (one per provider). Secrets are never returned. |
| kilango_get_connectionA | Return the connection for one provider (status/health, never the secret). |
| kilango_check_connection_healthC | Verify a connection's credentials against the source system. |
| kilango_delete_connectionA | Remove a backend connection (drops the stored secret from Kilango's vault). |
| kilango_call_operationA | Escape hatch: call any operator API operation by its operationId (discover ids with kilango_search_operations / kilango_describe_operation). Provide path params, query, and body separately. If-Match operations fetch and send the current ETag automatically. Mutating calls are gated by KILANGO_ENABLE_WRITES and by the API key's own scopes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 48 tools
Most tools follow a clear resource+action pattern (portal, page, block, app, widget, connection), making them distinguishable. Some minor overlap exists: kilango_add_content_block vs kilango_place_widget both add items to a page, and kilango_move_block vs kilango_update_content_block/kilango_update_widget vs kilango_reorder_blocks all deal with positioning/moving elements. The descriptions do help disambiguate these cases, but an agent could misselect between move/reorder/update-position tools.
All 48 tools follow a consistent `kilango_` prefix with verb_noun naming: list/get/create/update/delete/archive/publish/unpublish/save/add/place/activate/deactivate/install/uninstall/connect each pair with a clear object (portal, page, block, widget, app, connection). The pattern holds uniformly across all tools, making the naming predictable.
48 tools is on the larger side, but the domain is genuinely broad — portal management, page building, widget placement, app lifecycle, connection management, and an escape hatch. Each tool covers a fairly distinct operation. However, there are many overlapping position/move tools (move_block, reorder_blocks, update_content_block, update_widget) that could arguably be consolidated, and the count feels slightly heavy.
The tool surface is remarkably complete for the domain: full portal lifecycle (create, update, get, list, publish, unpublish, archive, delete, preview, readiness), page CRUD with fine-grained block/widget operations, app catalog and installation/activation lifecycle, connection management, vocabulary discovery, navigation editing with ETag handling, and an escape-hatch call_operation for anything not covered. There are no obvious dead ends — even readiness blockers and force-publish edge cases are handled.