@superglue/cli 1.1.24 → 1.1.26

package/dist/skills/superglue/SKILL.md

@@ -147,9 +147,10 @@ Blocked commands print a clear error showing the current preset and how to chang
 
 1. Search for an existing system first: `sg system find <query>`
 2. If creating: `sg system create --name "..." --url "..." --credentials '{...}'`. Prefer `--template <id>` when one exists — it auto-fills URL and OAuth config
-3. For OAuth: `sg system oauth --system-id <id> --scopes "..."` opens a browser flow. User approves → tokens saved automatically
-4. Verify connectivity with `sg system call`
-5. For updates: `sg system edit --id <id>` with the fields to change
+3. For OAuth: `sg system oauth --system-id <id> [--scopes "..."]` opens a browser flow. User approves → tokens saved automatically
+4. For user-owned non-OAuth credentials: `sg system credentials set --system-id <id> --credentials '{...}'`
+5. Verify connectivity with `sg system call`
+6. For updates: `sg system edit --id <id>` with the fields to change
 
 ### Running a Tool (Ad-hoc)
 
@@ -168,23 +169,24 @@ Streams live execution logs to the terminal. Use `--include-step-results` for ra
 
 Agents familiar with the web tool names can map them directly to CLI commands:
 
-| Web agent tool               | CLI command                                   | Notes                                                              |
-| ---------------------------- | --------------------------------------------- | ------------------------------------------------------------------ |
-| `build_tool`                 | `sg tool build --config '{...}'`              | CLI is not AI-powered — you provide the full JSON config           |
-| `edit_tool`                  | `sg tool edit --tool <id> --patches '[...]'`  | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
-| `run_tool`                   | `sg tool run --tool <id>` / `--draft <id>`    | Add `--include-step-results` to inspect per-step data              |
-| `save_tool`                  | `sg tool save --draft <draftId>`              | Persists a draft to the database                                   |
-| `inspect_tool` / `find_tool` | `sg tool find --id <id>` / `sg tool find <q>` | Full config with `--id`, compact search with a query string        |
-| `create_system`              | `sg system create --name "..." --url "..."`   | Use `--template <id>` when available                               |
-| `edit_system`                | `sg system edit --id <id> ...`                | Supports `--env dev\|prod`                                         |
-| `find_system`                | `sg system find <query>` / `--id <id>`        | Returns `storedCredentials` and system URL                         |
-| `call_system`                | `sg system call --url "..." --system-id <id>` | Authenticated ad-hoc calls for testing / schema introspection      |
-| `search_documentation`       | `sg system search-docs --system-id <id> -k`   | Targeted keyword search over ingested system docs                  |
-| `authenticate_oauth`         | `sg system oauth --system-id <id> --scopes`   | Opens browser flow. Supports `--grant-type client_credentials` too |
-| `get_runs`                   | `sg run list` / `sg run get <runId>`          | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
-| (no direct equivalent)       | `sg init`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
-
-Web-agent-only concepts with no CLI equivalent: `load_skill` (references are accessed via `sg skill <topic>` instead), `create_schedule`/`edit_schedule`/`find_schedule` (manage schedules via web app or REST API), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).
+| Web agent tool                               | CLI command                                   | Notes                                                              |
+| -------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------ |
+| `build_tool`                                 | `sg tool build --config '{...}'`              | CLI is not AI-powered — you provide the full JSON config           |
+| `edit_tool`                                  | `sg tool edit --tool <id> --patches '[...]'`  | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
+| `run_tool`                                   | `sg tool run --tool <id>` / `--draft <id>`    | Add `--include-step-results` to inspect per-step data              |
+| `save_tool`                                  | `sg tool save --draft <draftId>`              | Persists a draft to the database                                   |
+| `run_command` with `vfs` for `/org/tools/`   | `sg tool find --id <id>` / `sg tool find <q>` | Full config with `--id`, compact search with a query string        |
+| `create_system`                              | `sg system create --name "..." --url "..."`   | Use `--template <id>` when available                               |
+| `edit_system`                                | `sg system edit --id <id> ...`                | Supports `--env dev\|prod`                                         |
+| `run_command` with `vfs` for `/org/systems/` | `sg system find <query>` / `--id <id>`        | Returns `storedCredentials` and system URL                         |
+| Credentials VFS / user-owned credentials     | `sg system credentials get/set/clear`         | Manage current user's credentials for user-owned systems           |
+| `call_system`                                | `sg system call --url "..." --system-id <id>` | Authenticated ad-hoc calls for testing / schema introspection      |
+| `run_command search`                         | `sg system search-docs --system-id <id> -k`   | Targeted keyword search over ingested system docs                  |
+| `authenticate_oauth`                         | `sg system oauth --system-id <id> [--scopes]` | Opens browser flow. Supports `--grant-type client_credentials` too |
+| `run_command` with `vfs` for `/org/runs/`    | `sg run list` / `sg run get <runId>`          | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
+| (no direct equivalent)                       | `sg init`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
+
+Web-agent-only concepts with no CLI equivalent: `run_command`'s virtual filesystem (CLI uses concrete `sg` subcommands), `create_schedule`/`edit_schedule` (manage schedules via web app or REST API), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).
 
 ### Command Reference
 
@@ -215,6 +217,9 @@ sg system edit --id my_api --credentials '{...}'
 sg system list
 sg system find slack
 sg system find --id my_api --env dev
+sg system credentials get --system-id my_api
+sg system credentials set --system-id my_api --credentials '{"api_key":"sk-xxx"}'
+sg system credentials clear --system-id my_api
 sg system call --url https://api.example.com/users --system-id my_api --method GET \
   --headers '{"Authorization":"Bearer <<my_api_access_token>>"}'
 sg system search-docs --system-id slack -k "send message channels"
@@ -437,6 +442,8 @@ Basic auth auto-encodes: if the value after `Basic ` isn't already base64, the e
 **Credential lifecycle:**
 
 - Pass ALL credentials (including secrets) via `--credentials '{"api_key":"...","client_secret":"..."}'` on create/edit
+- For user-owned systems, use `sg system credentials set --system-id <id> --credentials '{...}'` to save credentials for the current API-key user
+- Use `sg system credentials get --system-id <id>` to inspect current-user credential keys; values are masked unless `--reveal` is passed
 - OAuth tokens (`access_token`, `refresh_token`) auto-refresh before each step execution
 - Non-sensitive fields (`client_id`, `auth_url`, `token_url`) are stored alongside secrets in the same `--credentials` JSON
 

package/dist/skills/superglue/references/access-rules.md

@@ -123,15 +123,25 @@ Every user has exactly **one** base role. There are three:
 
 - **`admin`** — Full access to everything. Bypasses all RBAC checks. The admin role is **immutable** — it cannot be edited at all, nor can it be re-assigned.
 - **`member`** — Default for org team members. Starts with `tools: "ALL"`, `systems: "ALL"`. Tool and system allowlists can be narrowed to restrict access. Name and description cannot be changed. Cannot be deleted.
-- **`enduser`** — Default for end users / portal consumers. Starts with `tools: []`, `systems: {}` (no access). Tool and system allowlists must be explicitly populated to grant access. Name and description cannot be changed. Cannot be deleted.
+- **`enduser`** — Default for end users with Credentials-only access. Starts with `tools: []`, `systems: {}` (no access). Tool and system allowlists must be explicitly populated to grant access. Name and description cannot be changed. Cannot be deleted.
 
 Base roles define the starting permissions that custom roles can extend or build on top of. Users can also have additional **custom roles** on top of their base role. Custom roles are fully editable (name, description, tools, systems) and can be created and deleted.
 
+## Personal Roles
+
+Admins can create a **personal role** for a specific user. A personal role is a per-user override that scopes which tools and systems that individual can access — independent of their base role and shared custom roles.
+
+- Each user can have at most one personal role
+- Personal roles follow the same structure as custom roles (tools allowlist, systems map, custom rules)
+- Resolution: personal role permissions are unioned with the user's other roles (most permissive wins)
+- Use case: giving a single team member access to a sensitive system without creating a shared role
+- Managed via the **Personal Roles** tab in Access Rules (web app) or the REST API (`POST /v1/users/:userId/personal-role`)
+
 ### Auto-append on resource creation
 
-When a user creates a new tool or system, the backend automatically adds it to the **creator's base role** — but only if that base role uses SPECIFIC mode (not `"ALL"`) for the relevant field:
+When a user creates a new tool or system, the backend automatically adds it to the **creator's personal role**:
 
-- New tool created → appended to the creator's base role's `tools` list (skipped if `tools: "ALL"`)
-- New system created → appended to the creator's base role's `systems` map with `read-write` access (skipped if `systems: "ALL"`)
+- New tool created → appended to the creator's personal role's `tools` list
+- New system created → appended to the creator's personal role's `systems` map with `read-write` access
 
-This only affects the base role, not additional custom roles. It ensures that a user on a restricted allowlist automatically gets access to resources they create.
+This only affects the creator's personal role, not base roles or additional custom roles. It ensures that a user on a restricted allowlist automatically gets access to resources they create without granting those resources to everyone with the same base role.

package/dist/skills/superglue/references/http.md

@@ -29,6 +29,9 @@ All fields support `<<variable>>` and `<<(sourceData) => ...>>` expressions.
 | `pagination`  | no       | See Pagination section                                  |
 | `systemId`    | no       | Links system credentials and URL. Omit for public APIs  |
 
+For APIs that require the same query key multiple times, use an array value:
+`{ metadataHeaders: ["From", "Subject"] }` -> `?metadataHeaders=From&metadataHeaders=Subject`.
+
 ## Authentication
 
 Credentials are never injected automatically. You must place auth headers explicitly using `<<systemId_credentialKey>>` syntax.

package/dist/skills/superglue/references/odbc.md

@@ -34,9 +34,9 @@ The path contains the **database name**. The ODBC driver is specified via the `D
 
 **Supported drivers:**
 
-| Driver    | Database                     | Default Port |
-| --------- | ---------------------------- | ------------ |
-| `FreeTDS` | SAP ASE (Sybase), SQL Server | 5000         |
+| Driver    | Database                                   | Default Port |
+| --------- | ------------------------------------------ | ------------ |
+| `FreeTDS` | SAP ASE (Sybase), SQL Anywhere, SQL Server | 5000         |
 
 Additional query parameters (beyond `DRIVER`) are passed through to the ODBC connection string as key=value pairs.
 
@@ -136,11 +136,41 @@ FreeTDS defaults to TDS 5.0 for Sybase connections. If you encounter protocol er
 odbc://user:pass@host:5000/mydb?DRIVER=FreeTDS&TDS_Version=5.0
 ```
 
-| TDS Version | Use Case                   |
-| ----------- | -------------------------- |
-| `5.0`       | SAP ASE / Sybase (default) |
-| `7.0`       | SQL Server 7.0+            |
-| `7.4`       | SQL Server 2012+           |
+| TDS Version | Use Case                           |
+| ----------- | ---------------------------------- |
+| `5.0`       | SAP ASE / Sybase, SAP SQL Anywhere |
+| `7.0`       | SQL Server 7.0+                    |
+| `7.4`       | SQL Server 2012+                   |
+
+### SAP SQL Anywhere
+
+SQL Anywhere (SA16/SA17) works with FreeTDS using TDS version 5.0. Always specify `TDS_Version=5.0` explicitly:
+
+```
+odbc://user:pass@host:2638/mydb?DRIVER=FreeTDS&TDS_Version=5.0
+```
+
+Key differences from SAP ASE:
+
+- Default port is **2638** (not 5000)
+- Uses `TOP n` instead of `SET ROWCOUNT n` for row limiting: `SELECT TOP 10 * FROM table`
+- Does not support `LIMIT` syntax
+- `DB_NAME()` returns the current database name
+- `sa_db_info()` lists all running databases on the server
+- Only databases explicitly loaded by the server process are available — if you get "database not found", the database name must match the logical name the server assigned at startup (either from `-n` flag or the `.db` filename without extension)
+
+### Database-Specific Error Codes
+
+ODBC often surfaces error codes from the underlying database or driver. Do not treat those codes as generic ODBC meanings. If the message identifies a database engine, use that vendor's SQLCODE documentation instead of inferring from connection-string shape.
+
+For SQL Anywhere errors surfaced through ODBC:
+
+| SQLCODE | Meaning                      | Implication                                                                                                                   |
+| ------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `-103`  | Invalid user ID or password  | The database was reached far enough to reject authentication. Do not treat this as a missing database name.                   |
+| `-83`   | Specified database not found | The database name/path could not be resolved. Check the database name, DBN/DBF settings, server name, and TDS/driver routing. |
+
+For other ODBC-backed databases, look up the database/driver-specific error code before concluding what failed.
 
 ## Common Pitfalls
 
@@ -154,7 +184,7 @@ odbc://user:pass@host:5000/mydb?DRIVER=FreeTDS&TDS_Version=5.0
 
 When an ODBC step fails and the cause is not obvious:
 
-1. **Read the error message** — superglue includes the a truncated query preview in the error. Check for syntax errors, missing columns, or type mismatches.
+1. **Read the error message** — superglue includes a truncated query preview in the error. Check for syntax errors, missing columns, or type mismatches.
 2. **Verify connection credentials** — use `sg system find` to confirm `storedCredentials` keys match the placeholders in your URL. Test connectivity with a simple `SELECT 1` via `sg system call`.
 3. **Check database-side access** — connection refused or permission denied errors typically mean the database user lacks access. Verify with the user that the credentials have the required grants.
 4. **Check driver availability** — if the error mentions "driver not found", the `DRIVER` query parameter does not match any registered driver in `/etc/odbcinst.ini`. Verify the driver name is correct and the driver is installed in the Docker image.

package/dist/skills/superglue/references/superglue-info.md

@@ -18,9 +18,11 @@ If the user is asking general questions (not building):
 
 ## Authentication
 
-All superglue interfaces (API, SDK, CLI, MCP) require only an **API key**. Self-hosted deployments also need the API endpoint URL. There are no workspace IDs, project IDs, or other identifiers — the API key is the only credential needed.
+API, SDK, CLI, and webhook usage require an **API key**. MCP clients can use OAuth when supported, or API keys for non-interactive setup. Self-hosted deployments also need the API/MCP endpoint URL. There are no workspace IDs, project IDs, or other identifiers.
 
-Users can generate and manage API keys in **Control Panel → API Keys**. The API endpoint is displayed on the same page.
+MCP authentication is separate from API/SDK/CLI setup. For MCP OAuth, dynamic client registration, Langdock setup, and named server permissions, use the MCP documentation.
+
+Users can generate and manage API keys in **My Credentials -> superglue API keys**. The API endpoint is displayed on the same page.
 
 ## Interfaces
 
@@ -34,30 +36,35 @@ Users can generate and manage API keys in **Control Panel → API Keys**. The AP
 
 Tools can be triggered via webhook: `POST {apiEndpoint}/v1/hooks/{toolId}?token={apiKey}`
 
-On superglue Cloud, the API endpoint is `https://api.superglue.cloud`. Self-hosted and enterprise deployments use their own API endpoint — users can find theirs under Control Panel → API Keys.
+On superglue Cloud, the API endpoint is `https://api.superglue.cloud`. Self-hosted and enterprise deployments use their own API endpoint — users can find theirs under My Credentials -> superglue API keys.
 
 ### OAuth Callback URL
 
 OAuth flows require a callback URL: `{appEndpoint}/api/auth/callback`
 
-On superglue Cloud, the app endpoint is `https://app.superglue.cloud`. Self-hosted and enterprise deployments use their own app URL. If a user doesn't know their endpoints, they can check the browser URL bar for the app endpoint, and Control Panel → API Keys for the API endpoint.
+On superglue Cloud, the app endpoint is `https://app.superglue.cloud`. Self-hosted and enterprise deployments use their own app URL. If a user doesn't know their endpoints, they can check the browser URL bar for the app endpoint, and My Credentials -> superglue API keys for the API endpoint.
 
 ## Web App UI Layout
 
-Left sidebar navigation:
-
-- **Agent** — AI chat assistant for building and debugging tools/systems
-- **Landscape** — Visual graph showing all tools and their connected systems
-- **Tools** — List of saved tools. Click a tool to open its playground for editing, testing, and running.
-- **Systems** — List of connected external systems with credentials and documentation
-- **Control Panel** (expandable):
-  - Overview: Dashboard summary
-  - Runs: Execution history for all tool runs with status, errors, and step results
-  - Schedules: Manage scheduled/recurring tool runs
-  - API Keys: View and manage superglue API keys
-  - Organization: Team members and org settings
-  - Notifications: Configure alerts for tool run failures
-- **Docs** — Link to docs.superglue.cloud
+Use this section as the source of truth for high-level web app navigation. Do not invent UI locations that are not listed here.
+
+The persistent left sidebar contains these top-level items:
+
+- **Agent** (`/`) — primary AI chat assistant for building and debugging tools and systems.
+- **Landscape** (`/landscape`) — graph overview of tools, systems, and their connections.
+- **Tools** (`/tools`, detail at `/tools/{toolId}`) — saved tools; opens the tool playground for editing, testing, and running.
+- **Systems** (`/systems`, detail at `/systems/{systemId}`) — connected external systems with credentials and documentation.
+- **My Credentials** (`/credentials`) — credential management. The **My Credentials** section is for personal user-owned system credentials; the **superglue API keys** section is for API keys. Admins and members open it inside the normal app shell from the sidebar; end users only see this standalone credentials surface.
+- **Runs** (`/runs`, detail at `/runs/{runId}`) — execution history for full, draft, and single-step tool runs. Runs is a top-level sidebar item, not a Control Panel sub-item.
+- **Control Panel** (`/admin`) — expandable group for organization and account administration:
+  - **Overview** (`/admin`) — dashboard summary, including failed-run and schedule summaries.
+  - **Schedules** (`/admin?view=schedules`) — scheduled and recurring tool runs.
+  - **Access Rules** (`/admin/access`) — role and access-rule configuration; visible to admins on paid tiers. Use the access-rules reference for RBAC behavior, base roles, and personal roles.
+  - **Organization** (`/admin?view=organization`) — organization members, invites, and org-level settings; visible on paid tiers. Member management actions are admin-gated.
+  - **MCP Servers** (`/admin?view=mcp-servers`) — manage and export named MCP server endpoints. Use the MCP documentation for behavior, permissions, and client setup.
+  - **Notifications** (`/admin?view=notifications`) — user notification preferences and failure-alert channels.
+
+Below the navigation, the sidebar shows the organization switcher and Sign Out. Depending on the plan, it also shows **Upgrade Plan** or **Subscription**; Subscription opens the external Stripe billing portal. There is no standalone Settings, Profile, or in-app Billing page.
 
 ## Internals
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@superglue/cli",
-  "version": "1.1.24",
+  "version": "1.1.26",
   "bin": {
     "sg": "./dist/cli.js"
   },

package/skills/superglue/SKILL.md

@@ -147,9 +147,10 @@ Blocked commands print a clear error showing the current preset and how to chang
 
 1. Search for an existing system first: `sg system find <query>`
 2. If creating: `sg system create --name "..." --url "..." --credentials '{...}'`. Prefer `--template <id>` when one exists — it auto-fills URL and OAuth config
-3. For OAuth: `sg system oauth --system-id <id> --scopes "..."` opens a browser flow. User approves → tokens saved automatically
-4. Verify connectivity with `sg system call`
-5. For updates: `sg system edit --id <id>` with the fields to change
+3. For OAuth: `sg system oauth --system-id <id> [--scopes "..."]` opens a browser flow. User approves → tokens saved automatically
+4. For user-owned non-OAuth credentials: `sg system credentials set --system-id <id> --credentials '{...}'`
+5. Verify connectivity with `sg system call`
+6. For updates: `sg system edit --id <id>` with the fields to change
 
 ### Running a Tool (Ad-hoc)
 
@@ -168,23 +169,24 @@ Streams live execution logs to the terminal. Use `--include-step-results` for ra
 
 Agents familiar with the web tool names can map them directly to CLI commands:
 
-| Web agent tool               | CLI command                                   | Notes                                                              |
-| ---------------------------- | --------------------------------------------- | ------------------------------------------------------------------ |
-| `build_tool`                 | `sg tool build --config '{...}'`              | CLI is not AI-powered — you provide the full JSON config           |
-| `edit_tool`                  | `sg tool edit --tool <id> --patches '[...]'`  | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
-| `run_tool`                   | `sg tool run --tool <id>` / `--draft <id>`    | Add `--include-step-results` to inspect per-step data              |
-| `save_tool`                  | `sg tool save --draft <draftId>`              | Persists a draft to the database                                   |
-| `inspect_tool` / `find_tool` | `sg tool find --id <id>` / `sg tool find <q>` | Full config with `--id`, compact search with a query string        |
-| `create_system`              | `sg system create --name "..." --url "..."`   | Use `--template <id>` when available                               |
-| `edit_system`                | `sg system edit --id <id> ...`                | Supports `--env dev\|prod`                                         |
-| `find_system`                | `sg system find <query>` / `--id <id>`        | Returns `storedCredentials` and system URL                         |
-| `call_system`                | `sg system call --url "..." --system-id <id>` | Authenticated ad-hoc calls for testing / schema introspection      |
-| `search_documentation`       | `sg system search-docs --system-id <id> -k`   | Targeted keyword search over ingested system docs                  |
-| `authenticate_oauth`         | `sg system oauth --system-id <id> --scopes`   | Opens browser flow. Supports `--grant-type client_credentials` too |
-| `get_runs`                   | `sg run list` / `sg run get <runId>`          | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
-| (no direct equivalent)       | `sg init`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
-
-Web-agent-only concepts with no CLI equivalent: `load_skill` (references are accessed via `sg skill <topic>` instead), `create_schedule`/`edit_schedule`/`find_schedule` (manage schedules via web app or REST API), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).
+| Web agent tool                               | CLI command                                   | Notes                                                              |
+| -------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------ |
+| `build_tool`                                 | `sg tool build --config '{...}'`              | CLI is not AI-powered — you provide the full JSON config           |
+| `edit_tool`                                  | `sg tool edit --tool <id> --patches '[...]'`  | JSON Patch (RFC 6902). Use `--draft <id>` for drafts               |
+| `run_tool`                                   | `sg tool run --tool <id>` / `--draft <id>`    | Add `--include-step-results` to inspect per-step data              |
+| `save_tool`                                  | `sg tool save --draft <draftId>`              | Persists a draft to the database                                   |
+| `run_command` with `vfs` for `/org/tools/`   | `sg tool find --id <id>` / `sg tool find <q>` | Full config with `--id`, compact search with a query string        |
+| `create_system`                              | `sg system create --name "..." --url "..."`   | Use `--template <id>` when available                               |
+| `edit_system`                                | `sg system edit --id <id> ...`                | Supports `--env dev\|prod`                                         |
+| `run_command` with `vfs` for `/org/systems/` | `sg system find <query>` / `--id <id>`        | Returns `storedCredentials` and system URL                         |
+| Credentials VFS / user-owned credentials     | `sg system credentials get/set/clear`         | Manage current user's credentials for user-owned systems           |
+| `call_system`                                | `sg system call --url "..." --system-id <id>` | Authenticated ad-hoc calls for testing / schema introspection      |
+| `run_command search`                         | `sg system search-docs --system-id <id> -k`   | Targeted keyword search over ingested system docs                  |
+| `authenticate_oauth`                         | `sg system oauth --system-id <id> [--scopes]` | Opens browser flow. Supports `--grant-type client_credentials` too |
+| `run_command` with `vfs` for `/org/runs/`    | `sg run list` / `sg run get <runId>`          | Filter `list` by `--tool`, `--status`, `--source`, `--limit`       |
+| (no direct equivalent)                       | `sg init`, `sg update`, `sg skill`            | CLI-specific setup, updater, and this reference system             |
+
+Web-agent-only concepts with no CLI equivalent: `run_command`'s virtual filesystem (CLI uses concrete `sg` subcommands), `create_schedule`/`edit_schedule` (manage schedules via web app or REST API), `authenticate_oauth`'s dedicated MCP `authenticate` tool (CLI uses `sg system oauth`).
 
 ### Command Reference
 
@@ -215,6 +217,9 @@ sg system edit --id my_api --credentials '{...}'
 sg system list
 sg system find slack
 sg system find --id my_api --env dev
+sg system credentials get --system-id my_api
+sg system credentials set --system-id my_api --credentials '{"api_key":"sk-xxx"}'
+sg system credentials clear --system-id my_api
 sg system call --url https://api.example.com/users --system-id my_api --method GET \
   --headers '{"Authorization":"Bearer <<my_api_access_token>>"}'
 sg system search-docs --system-id slack -k "send message channels"
@@ -437,6 +442,8 @@ Basic auth auto-encodes: if the value after `Basic ` isn't already base64, the e
 **Credential lifecycle:**
 
 - Pass ALL credentials (including secrets) via `--credentials '{"api_key":"...","client_secret":"..."}'` on create/edit
+- For user-owned systems, use `sg system credentials set --system-id <id> --credentials '{...}'` to save credentials for the current API-key user
+- Use `sg system credentials get --system-id <id>` to inspect current-user credential keys; values are masked unless `--reveal` is passed
 - OAuth tokens (`access_token`, `refresh_token`) auto-refresh before each step execution
 - Non-sensitive fields (`client_id`, `auth_url`, `token_url`) are stored alongside secrets in the same `--credentials` JSON
 

package/skills/superglue/references/access-rules.md

@@ -123,15 +123,25 @@ Every user has exactly **one** base role. There are three:
 
 - **`admin`** — Full access to everything. Bypasses all RBAC checks. The admin role is **immutable** — it cannot be edited at all, nor can it be re-assigned.
 - **`member`** — Default for org team members. Starts with `tools: "ALL"`, `systems: "ALL"`. Tool and system allowlists can be narrowed to restrict access. Name and description cannot be changed. Cannot be deleted.
-- **`enduser`** — Default for end users / portal consumers. Starts with `tools: []`, `systems: {}` (no access). Tool and system allowlists must be explicitly populated to grant access. Name and description cannot be changed. Cannot be deleted.
+- **`enduser`** — Default for end users with Credentials-only access. Starts with `tools: []`, `systems: {}` (no access). Tool and system allowlists must be explicitly populated to grant access. Name and description cannot be changed. Cannot be deleted.
 
 Base roles define the starting permissions that custom roles can extend or build on top of. Users can also have additional **custom roles** on top of their base role. Custom roles are fully editable (name, description, tools, systems) and can be created and deleted.
 
+## Personal Roles
+
+Admins can create a **personal role** for a specific user. A personal role is a per-user override that scopes which tools and systems that individual can access — independent of their base role and shared custom roles.
+
+- Each user can have at most one personal role
+- Personal roles follow the same structure as custom roles (tools allowlist, systems map, custom rules)
+- Resolution: personal role permissions are unioned with the user's other roles (most permissive wins)
+- Use case: giving a single team member access to a sensitive system without creating a shared role
+- Managed via the **Personal Roles** tab in Access Rules (web app) or the REST API (`POST /v1/users/:userId/personal-role`)
+
 ### Auto-append on resource creation
 
-When a user creates a new tool or system, the backend automatically adds it to the **creator's base role** — but only if that base role uses SPECIFIC mode (not `"ALL"`) for the relevant field:
+When a user creates a new tool or system, the backend automatically adds it to the **creator's personal role**:
 
-- New tool created → appended to the creator's base role's `tools` list (skipped if `tools: "ALL"`)
-- New system created → appended to the creator's base role's `systems` map with `read-write` access (skipped if `systems: "ALL"`)
+- New tool created → appended to the creator's personal role's `tools` list
+- New system created → appended to the creator's personal role's `systems` map with `read-write` access
 
-This only affects the base role, not additional custom roles. It ensures that a user on a restricted allowlist automatically gets access to resources they create.
+This only affects the creator's personal role, not base roles or additional custom roles. It ensures that a user on a restricted allowlist automatically gets access to resources they create without granting those resources to everyone with the same base role.

package/skills/superglue/references/http.md

@@ -29,6 +29,9 @@ All fields support `<<variable>>` and `<<(sourceData) => ...>>` expressions.
 | `pagination`  | no       | See Pagination section                                  |
 | `systemId`    | no       | Links system credentials and URL. Omit for public APIs  |
 
+For APIs that require the same query key multiple times, use an array value:
+`{ metadataHeaders: ["From", "Subject"] }` -> `?metadataHeaders=From&metadataHeaders=Subject`.
+
 ## Authentication
 
 Credentials are never injected automatically. You must place auth headers explicitly using `<<systemId_credentialKey>>` syntax.

package/skills/superglue/references/odbc.md

@@ -34,9 +34,9 @@ The path contains the **database name**. The ODBC driver is specified via the `D
 
 **Supported drivers:**
 
-| Driver    | Database                     | Default Port |
-| --------- | ---------------------------- | ------------ |
-| `FreeTDS` | SAP ASE (Sybase), SQL Server | 5000         |
+| Driver    | Database                                   | Default Port |
+| --------- | ------------------------------------------ | ------------ |
+| `FreeTDS` | SAP ASE (Sybase), SQL Anywhere, SQL Server | 5000         |
 
 Additional query parameters (beyond `DRIVER`) are passed through to the ODBC connection string as key=value pairs.
 
@@ -136,11 +136,41 @@ FreeTDS defaults to TDS 5.0 for Sybase connections. If you encounter protocol er
 odbc://user:pass@host:5000/mydb?DRIVER=FreeTDS&TDS_Version=5.0
 ```
 
-| TDS Version | Use Case                   |
-| ----------- | -------------------------- |
-| `5.0`       | SAP ASE / Sybase (default) |
-| `7.0`       | SQL Server 7.0+            |
-| `7.4`       | SQL Server 2012+           |
+| TDS Version | Use Case                           |
+| ----------- | ---------------------------------- |
+| `5.0`       | SAP ASE / Sybase, SAP SQL Anywhere |
+| `7.0`       | SQL Server 7.0+                    |
+| `7.4`       | SQL Server 2012+                   |
+
+### SAP SQL Anywhere
+
+SQL Anywhere (SA16/SA17) works with FreeTDS using TDS version 5.0. Always specify `TDS_Version=5.0` explicitly:
+
+```
+odbc://user:pass@host:2638/mydb?DRIVER=FreeTDS&TDS_Version=5.0
+```
+
+Key differences from SAP ASE:
+
+- Default port is **2638** (not 5000)
+- Uses `TOP n` instead of `SET ROWCOUNT n` for row limiting: `SELECT TOP 10 * FROM table`
+- Does not support `LIMIT` syntax
+- `DB_NAME()` returns the current database name
+- `sa_db_info()` lists all running databases on the server
+- Only databases explicitly loaded by the server process are available — if you get "database not found", the database name must match the logical name the server assigned at startup (either from `-n` flag or the `.db` filename without extension)
+
+### Database-Specific Error Codes
+
+ODBC often surfaces error codes from the underlying database or driver. Do not treat those codes as generic ODBC meanings. If the message identifies a database engine, use that vendor's SQLCODE documentation instead of inferring from connection-string shape.
+
+For SQL Anywhere errors surfaced through ODBC:
+
+| SQLCODE | Meaning                      | Implication                                                                                                                   |
+| ------- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `-103`  | Invalid user ID or password  | The database was reached far enough to reject authentication. Do not treat this as a missing database name.                   |
+| `-83`   | Specified database not found | The database name/path could not be resolved. Check the database name, DBN/DBF settings, server name, and TDS/driver routing. |
+
+For other ODBC-backed databases, look up the database/driver-specific error code before concluding what failed.
 
 ## Common Pitfalls
 
@@ -154,7 +184,7 @@ odbc://user:pass@host:5000/mydb?DRIVER=FreeTDS&TDS_Version=5.0
 
 When an ODBC step fails and the cause is not obvious:
 
-1. **Read the error message** — superglue includes the a truncated query preview in the error. Check for syntax errors, missing columns, or type mismatches.
+1. **Read the error message** — superglue includes a truncated query preview in the error. Check for syntax errors, missing columns, or type mismatches.
 2. **Verify connection credentials** — use `sg system find` to confirm `storedCredentials` keys match the placeholders in your URL. Test connectivity with a simple `SELECT 1` via `sg system call`.
 3. **Check database-side access** — connection refused or permission denied errors typically mean the database user lacks access. Verify with the user that the credentials have the required grants.
 4. **Check driver availability** — if the error mentions "driver not found", the `DRIVER` query parameter does not match any registered driver in `/etc/odbcinst.ini`. Verify the driver name is correct and the driver is installed in the Docker image.

package/skills/superglue/references/superglue-info.md

@@ -18,9 +18,11 @@ If the user is asking general questions (not building):
 
 ## Authentication
 
-All superglue interfaces (API, SDK, CLI, MCP) require only an **API key**. Self-hosted deployments also need the API endpoint URL. There are no workspace IDs, project IDs, or other identifiers — the API key is the only credential needed.
+API, SDK, CLI, and webhook usage require an **API key**. MCP clients can use OAuth when supported, or API keys for non-interactive setup. Self-hosted deployments also need the API/MCP endpoint URL. There are no workspace IDs, project IDs, or other identifiers.
 
-Users can generate and manage API keys in **Control Panel → API Keys**. The API endpoint is displayed on the same page.
+MCP authentication is separate from API/SDK/CLI setup. For MCP OAuth, dynamic client registration, Langdock setup, and named server permissions, use the MCP documentation.
+
+Users can generate and manage API keys in **My Credentials -> superglue API keys**. The API endpoint is displayed on the same page.
 
 ## Interfaces
 
@@ -34,30 +36,35 @@ Users can generate and manage API keys in **Control Panel → API Keys**. The AP
 
 Tools can be triggered via webhook: `POST {apiEndpoint}/v1/hooks/{toolId}?token={apiKey}`
 
-On superglue Cloud, the API endpoint is `https://api.superglue.cloud`. Self-hosted and enterprise deployments use their own API endpoint — users can find theirs under Control Panel → API Keys.
+On superglue Cloud, the API endpoint is `https://api.superglue.cloud`. Self-hosted and enterprise deployments use their own API endpoint — users can find theirs under My Credentials -> superglue API keys.
 
 ### OAuth Callback URL
 
 OAuth flows require a callback URL: `{appEndpoint}/api/auth/callback`
 
-On superglue Cloud, the app endpoint is `https://app.superglue.cloud`. Self-hosted and enterprise deployments use their own app URL. If a user doesn't know their endpoints, they can check the browser URL bar for the app endpoint, and Control Panel → API Keys for the API endpoint.
+On superglue Cloud, the app endpoint is `https://app.superglue.cloud`. Self-hosted and enterprise deployments use their own app URL. If a user doesn't know their endpoints, they can check the browser URL bar for the app endpoint, and My Credentials -> superglue API keys for the API endpoint.
 
 ## Web App UI Layout
 
-Left sidebar navigation:
-
-- **Agent** — AI chat assistant for building and debugging tools/systems
-- **Landscape** — Visual graph showing all tools and their connected systems
-- **Tools** — List of saved tools. Click a tool to open its playground for editing, testing, and running.
-- **Systems** — List of connected external systems with credentials and documentation
-- **Control Panel** (expandable):
-  - Overview: Dashboard summary
-  - Runs: Execution history for all tool runs with status, errors, and step results
-  - Schedules: Manage scheduled/recurring tool runs
-  - API Keys: View and manage superglue API keys
-  - Organization: Team members and org settings
-  - Notifications: Configure alerts for tool run failures
-- **Docs** — Link to docs.superglue.cloud
+Use this section as the source of truth for high-level web app navigation. Do not invent UI locations that are not listed here.
+
+The persistent left sidebar contains these top-level items:
+
+- **Agent** (`/`) — primary AI chat assistant for building and debugging tools and systems.
+- **Landscape** (`/landscape`) — graph overview of tools, systems, and their connections.
+- **Tools** (`/tools`, detail at `/tools/{toolId}`) — saved tools; opens the tool playground for editing, testing, and running.
+- **Systems** (`/systems`, detail at `/systems/{systemId}`) — connected external systems with credentials and documentation.
+- **My Credentials** (`/credentials`) — credential management. The **My Credentials** section is for personal user-owned system credentials; the **superglue API keys** section is for API keys. Admins and members open it inside the normal app shell from the sidebar; end users only see this standalone credentials surface.
+- **Runs** (`/runs`, detail at `/runs/{runId}`) — execution history for full, draft, and single-step tool runs. Runs is a top-level sidebar item, not a Control Panel sub-item.
+- **Control Panel** (`/admin`) — expandable group for organization and account administration:
+  - **Overview** (`/admin`) — dashboard summary, including failed-run and schedule summaries.
+  - **Schedules** (`/admin?view=schedules`) — scheduled and recurring tool runs.
+  - **Access Rules** (`/admin/access`) — role and access-rule configuration; visible to admins on paid tiers. Use the access-rules reference for RBAC behavior, base roles, and personal roles.
+  - **Organization** (`/admin?view=organization`) — organization members, invites, and org-level settings; visible on paid tiers. Member management actions are admin-gated.
+  - **MCP Servers** (`/admin?view=mcp-servers`) — manage and export named MCP server endpoints. Use the MCP documentation for behavior, permissions, and client setup.
+  - **Notifications** (`/admin?view=notifications`) — user notification preferences and failure-alert channels.
+
+Below the navigation, the sidebar shows the organization switcher and Sign Out. Depending on the plan, it also shows **Upgrade Plan** or **Subscription**; Subscription opens the external Stripe billing portal. There is no standalone Settings, Profile, or in-app Billing page.
 
 ## Internals