sideshift-operations

SideShift operations

Use the installed SideShift MCP server as the authoritative interface. Do not replace it with scraped pages, guessed REST calls, direct database access, or another company's credentials.

Establish the operating context

1. Call whoami before the first substantive operation in a task.
2. State the connected company and whether the required scope is present.
3. For any write or sensitive operation, verify the company again immediately before execution if the session may have changed.
4. If authorization is missing, direct the user through the host's SideShift connection command or setup flow. Never request that the user paste an access token, refresh token, API key, cookie, or client secret into chat.

Select tools from the authoritative catalog

The default server exposes consolidated functions: reads use a *_query function with a documented view; writes have explicit action names. Use the advertised schema and its view options. For example, campaigns_query(view="list") lists campaigns. whoami identifies this surface; it has no hidden catalog to search.

Some connections expose the full direct catalog instead. Use an obvious typed tool first. When no visible tool matches and find_capability (or catalog_search) is available, search by the user's intent, inspect the result with catalog_get_schema, and invoke it through catalog_invoke_read, catalog_invoke_write, or catalog_invoke_sensitive as appropriate.

Never invent a tool name, field, enum value, ID, scope, or outcome. Check the available function views or catalog results before concluding that a capability is unsupported.

Read, write, and sensitive behavior

Reads

Run read-only tools when they directly answer the user's request. Preserve material caveats, pagination, freshness indicators, and not found or insufficient data states.

Writes

Before a reversible write:

1. Resolve and show the exact target.
2. Load the authoritative schema.
3. Gather every required value.
4. Summarize the material arguments and expected state change.
5. Use an existing explicit authorization when it covers this exact action; otherwise ask for confirmation of the concrete change.
6. Execute once, then read back the resulting state when a read tool is available.