@superglue/cli 1.1.25 → 1.1.27

package/skills/superglue/SKILL.md

@@ -25,7 +25,7 @@ Read these on demand — they are authoritative for their topic and kept in sync
 | `sg skill redis`          | Redis command syntax, connection URLs, key type handling                                             |
 | `sg skill sftp-smb`       | SFTP, FTP, and SMB operations, file upload/download semantics, path handling                         |
 | `sg skill file-handling`  | File detection, parsing, `file::` reference syntax, lazy base64 access, transform-produced files     |
-| `sg skill access-rules`   | RBAC roles, tool/system permissions, mutation detection, custom rules (enterprise only)              |
+| `sg skill access-rules`   | RBAC roles and binary tool/system allowlists (enterprise only)                                       |
 
 ## CRITICAL RULES — READ FIRST
 
@@ -33,7 +33,7 @@ Read these on demand — they are authoritative for their topic and kept in sync
 
 1. **Check CLI exists**: Run `sg --version`. If it fails with `command not found`, install: `npm install -g @superglue/cli`.
 2. **Keep CLI and SDK up to date**: Always use the latest versions. Run `sg update` to update the CLI. For the SDK, run `npm install @superglue/client@latest` (JS) or `pip install --upgrade superglue-client` (Python).
-3. **Verify configuration**: Run `sg system list`. If it fails with `fetch failed` or auth errors, the CLI needs configuration via `sg init` (see Setup below).
+3. **Verify configuration**: Run `sg system list`. If it fails with `fetch failed` or auth errors, the CLI needs configuration via `sg init` (see Setup below). For custom/self-hosted instances, the CLI must know both the instance API endpoint and an org-scoped API key.
 
 **Calling systems and running tools**
 
@@ -103,11 +103,11 @@ Verify with `sg system list` — should return a list (possibly empty) without e
 
 Set during `sg init` or via `SUPERGLUE_CLI_PRESET` env var. Stored in `config.json` as `"preset"`.
 
-| Preset    | Description                                                        |
-| --------- | ------------------------------------------------------------------ |
-| `runner`  | Run saved tools by ID only. Read-only lookups. No building/editing |
-| `builder` | Runner + build/edit/save tools, call systems. No system CRUD       |
-| `admin`   | Full access (default)                                              |
+| Preset    | Description                                                                      |
+| --------- | -------------------------------------------------------------------------------- |
+| `runner`  | Run saved tools by ID only. Read-only lookups. No building/editing               |
+| `builder` | Runner + build/edit/save tools, call systems, manage MCP servers. No system CRUD |
+| `admin`   | Full access (default)                                                            |
 
 Blocked commands print a clear error showing the current preset and how to change it.
 
@@ -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)
 
@@ -160,6 +161,30 @@ sg tool run --draft <draftId> --payload-file payload.json
 
 Streams live execution logs to the terminal. Use `--include-step-results` for raw per-step responses and `--include-config` for the full config dump.
 
+### Creating/Editing a Named MCP Server
+
+Named MCP servers expose a selected set of saved tools through an MCP endpoint. The CLI always uses the configured superglue API endpoint, so it works for Cloud and self-hosted instances when `SUPERGLUE_API_ENDPOINT` or `--endpoint` points at the right API.
+
+1. Verify CLI setup: `sg system list` or `sg mcp list`
+2. Find saved tools to expose: `sg tool list` or `sg tool find <query>`
+3. Create the server:
+   ```bash
+   sg mcp create --name sales-tools --tool get_customer --tool create_invoice
+   ```
+4. Use the returned `server.connection.endpoint` and `clientConfig` in the MCP client.
+5. Edit later with:
+   ```bash
+   sg mcp edit --id <serverId> --add-tool another_tool
+   sg mcp edit --id <serverId> --tools get_customer,create_invoice
+   ```
+
+Auth modes:
+
+- `oauth` (default): OAuth-capable MCP clients authenticate users through the MCP auth flow.
+- `creator_api_key`: private/headless clients must send `Authorization: Bearer <SUPERGLUE_API_KEY>` where the key is active and assigned to the MCP server creator.
+
+If `sg mcp ...` returns "MCP server management is not available", the target instance or plan does not support named MCP server management. The default all-tools MCP endpoint may still be usable at `<api-endpoint>/mcp`.
+
 ---
 
 ## Reference
@@ -168,23 +193,27 @@ 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`       |
+| `run_command` with `vfs` for `/org/mcp-servers/` | `sg mcp list` / `sg mcp find --id <id>`       | Returns endpoint, auth mode, selected tool IDs, and client config  |
+| `create_mcp_server`                              | `sg mcp create --name <n> --tool <id>`        | Creates a named MCP endpoint for selected saved tools              |
+| `edit_mcp_server`                                | `sg mcp edit --id <id> ...`                   | Edits name, auth mode, description, or selected tool IDs           |
+| (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 +244,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"
@@ -222,6 +254,19 @@ sg system oauth --system-id gmail --scopes "https://www.googleapis.com/auth/gmai
 sg system oauth --system-id my_api --grant-type client_credentials --scopes "read write"
 ```
 
+**MCP server commands:**
+
+```bash
+sg mcp list
+sg mcp find sales
+sg mcp find --id <serverId>
+sg mcp create --name sales-tools --tool get_customer --tool create_invoice
+sg mcp create --name sales-tools --tools get_customer,create_invoice --auth-mode oauth
+sg mcp edit --id <serverId> --add-tool another_tool
+sg mcp edit --id <serverId> --remove-tool old_tool
+sg mcp edit --id <serverId> --auth-mode creator_api_key
+```
+
 **Run commands:**
 
 ```bash
@@ -437,6 +482,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

@@ -1,137 +1,77 @@
 # Access Rules (RBAC)
 
-On superglue, roles define tool-level and system-level allowlists. Users can have multiple roles. Roles and access rules are only available on enterprise organizations. Non-enterprise orgs do not have RBAC — all users have admin access on personal organizations.
+On superglue, roles define binary tool-level and system-level allowlists. Users can have multiple roles. Roles and access rules are only available on enterprise organizations.
 
 ## Data Model
 
-### Role
-
 ```typescript
 interface Role {
   id: string;
   name: string;
   description?: string;
-  tools: "ALL" | string[]; // tool allowlist
-  systems: "ALL" | Record<string, SystemPermission>; // system allowlist
-  isBaseRole?: boolean; // true for admin, member, enduser
-}
-```
-
-### SystemPermission
-
-Each system entry is either a predefined access level or a custom rule:
-
-```typescript
-type SystemPermission = SystemAccessLevel | { rules: CustomRule[] };
-```
-
-| Type               | Meaning                                          |
-| ------------------ | ------------------------------------------------ |
-| `"read-write"`     | All HTTP methods allowed                         |
-| `"read-only"`      | Only GET and HEAD; POST/PUT/PATCH/DELETE blocked |
-| `{ rules: [...] }` | Custom JS expressions that gate access           |
-
-Systems not listed in the role's `systems` map are DENIED, unless the system access is set to `"ALL"`.
-
-### CustomRule
-
-```typescript
-interface CustomRule {
-  id: string;
-  name: string;
-  expression?: string; // JS expression, receives stepConfig
-  isActive: boolean;
+  tools: "ALL" | string[];
+  systems: "ALL" | string[];
+  isBaseRole?: boolean;
 }
 ```
 
-Custom rules are inline in the systems map. A system either has a standard access level OR a custom rule, never both. Custom rules must return truthy to **allow** the request. If it returns falsy, throws, or has no expression, the request is blocked (fail-closed).
+Only `"ALL"` means open access. Empty arrays, missing fields, or `null` mean no direct access from that role.
 
 ## Tool Permissions
 
 - `tools: "ALL"` — every tool is allowed, including tools created in the future
-- `tools: ["tool-id-1", "tool-id-2"]` — only these specific tools are allowed; new tools are NOT auto-included (but see Auto-Append below)
+- `tools: ["tool-id-1", "tool-id-2"]` — only these specific tools are allowed
+- Effective tool visibility also requires access to every system referenced by that tool's request steps
 
 ## System Permissions
 
-- `systems: "ALL"` — every system allowed at READ_WRITE level, including future systems. Custom rules are not possible in this mode.
-- `systems: { "gmail": "read-write", "stripe": "read-only" }` — SPECIFIC mode: per-system access levels; unlisted systems are denied.
-- `systems: { "gmail": { rules: [{ name: "block-deletes", expression: "stepConfig.method !== 'DELETE'", isActive: true }] } }` — custom rule on a specific system
+- `systems: "ALL"` — every current and future system is allowed
+- `systems: ["gmail", "stripe"]` — only these specific systems are allowed
+- System access is binary by system ID: listed means allowed, omitted means denied.
 
-## Mutation Detection by Protocol
+## Tool/System Entanglement
 
-Read-only mode blocks mutating requests. How "mutating" is determined per protocol:
+A saved tool is effectively visible and runnable only when both are true:
 
-- **HTTP** — POST, PUT, PATCH, DELETE are mutating; GET and HEAD are read-only
-- **Postgres** — SQL statements starting with or containing INSERT, UPDATE, DELETE, DROP, ALTER, CREATE, TRUNCATE, etc. are mutating; everything else (SELECT) is read-only
-- **FTP / SMB** — operations other than `list`, `get`, `exists`, `stat` are mutating
-- **Redis** — commands not in the read-only set (GET, MGET, EXISTS, KEYS, SCAN, TTL, TYPE, HGET, HGETALL, LRANGE, SMEMBERS, SCARD, etc.) are mutating
-- **Transform** — never mutating (pure data transformation, no external system)
+1. The user has tool access through at least one role.
+2. The user has access to every `systemId` referenced by the tool's request steps.
 
-On parse failure, all protocols default to **mutating** (fail-closed).
+When granting a tool, inspect the tool's request-step `systemId` values and grant required systems when the user should be able to see or run the tool.
 
-## Custom Rule Expressions
-
-Custom rules only apply in SPECIFIC mode. If systems is `"ALL"`, no custom rules exist.
-
-Expressions receive a **resolved** `stepConfig` object — all template variables (`<<variable>>` and `<<(sourceData) => ...>>` expressions) are substituted with their actual runtime values before the rule evaluates. This means rules see the real URL, headers, body, and query params, not raw templates.
-
-```typescript
-interface StepConfig {
-  url: string;
-  method: string;
-  headers: Record<string, string>;
-  queryParams: Record<string, string>;
-  body: unknown;
-  systemId: string;
-}
-```
-
-Example expressions:
-
-```javascript
-// Block all POST requests to a specific endpoint
-stepConfig.method !== "POST" || !stepConfig.url.includes("/admin");
-
-// Only allow GET requests to /api/v1/read endpoints
-stepConfig.method === "GET" && stepConfig.url.includes("/api/v1/read");
+## Multi-Role Semantics
 
-// Block requests with certain headers
-!stepConfig.headers["x-dangerous-header"];
+Users can have multiple roles. Resolution is union:
 
-// Block a specific datasource ID in the resolved body
-!(typeof stepConfig.body === "object" && stepConfig.body?.datasource?.id === "blocked-id");
-```
+| Layer   | Semantics                                             |
+| ------- | ----------------------------------------------------- |
+| Tools   | If any role allows a tool, the tool ID is allowed     |
+| Systems | If any role allows a system, the system ID is allowed |
 
-## Multi-Role Semantics
+Assigned roles can add access but cannot remove access granted by another role.
 
-Users can have multiple roles. Resolution is **union (most permissive wins) everywhere**:
-
-| Layer        | Semantics                      | Example                                                                     |
-| ------------ | ------------------------------ | --------------------------------------------------------------------------- |
-| Tools        | Union (most permissive wins)   | If role A allows tool X and role B doesn't, tool X is allowed               |
-| Systems      | Union (most permissive wins)   | If role A gives READ_ONLY and role B gives READ_WRITE, result is READ_WRITE |
-| Custom rules | Per-role union (any role wins) | If any role's complete rule set allows the request, it goes through         |
+## Base Roles
 
-Custom rule detail:
+Every user has exactly one base role:
 
-- **Within a single role**, all custom rules for that system must pass (AND logic)
-- **Across roles**, evaluation is per-role: if any role fully allows the request (all its rules pass, or it has no custom rule for that system), the request is allowed (OR logic)
+- **`admin`** — full access to everything. The admin role is immutable.
+- **`member`** — default for org team members. Starts with `tools: "ALL"`, `systems: "ALL"`. Tool and system allowlists can be narrowed. Name and description cannot be changed. Cannot be deleted.
 
-## Base Roles
+Users can also have additional custom roles on top of their base role. Custom roles are fully editable and can be created/deleted.
 
-Every user has exactly **one** base role. There are three:
+## Personal Roles
 
-- **`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.
+Admins can create a personal role for a specific user. A personal role is a per-user override that grants individual tool and system access independent of shared roles.
 
-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.
+- Each user can have at most one personal role.
+- Personal roles use the same `tools` and `systems` allowlist structure.
+- Personal role allowlists are unioned with the user's other roles.
+- Managed via the Personal Roles tab in Access Rules or the REST API (`POST /v1/users/:userId/personal-role`).
 
-### Auto-append on resource creation
+## 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 `tools` list
+- New system created -> appended to the creator's personal role `systems` list
 
-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.

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.
+- **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
 
@@ -74,7 +81,6 @@ Left sidebar navigation:
    e. Wrap result: `{ currentItem, data, success }`
    f. On failure: abort if `failureBehavior !== "continue"`
 3. **Output transform** (if present): run JS function, validate against outputSchema
-4. **Response filters** (if present): remove/mask/fail on pattern matches
 
 ### Strategy Routing