# viaSocket (remote · mcp.viasocket.com)

Build and run automations across 2,300+ apps and build app integrations from any MCP client.

- Trust score: 66/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `mcp.viasocket.com`: 66/100 (this document), [markdown](https://verifymcp.io/servers/com-viasocket-mcp/mcp.md), [page](https://verifymcp.io/servers/com-viasocket-mcp/mcp)

## Channel facts

- Endpoint: `https://mcp.viasocket.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (call_any_api_of_viasocket).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 64/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4253 tokens (~212/item across 20 items; 20 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 7/100
  - Stability observed for 2 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 21 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### How do I install the viaSocket MCP server?

viaSocket is a hosted endpoint at https://mcp.viasocket.com/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http com-viasocket-mcp 'https://mcp.viasocket.com/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "com-viasocket-mcp": {
      "url": "https://mcp.viasocket.com/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "com-viasocket-mcp": {
      "type": "http",
      "url": "https://mcp.viasocket.com/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.com-viasocket-mcp]
url = "https://mcp.viasocket.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-viasocket-mcp": {
      "type": "remote",
      "url": "https://mcp.viasocket.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-viasocket-mcp --url 'https://mcp.viasocket.com/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-viasocket-mcp:
    url: "https://mcp.viasocket.com/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "com-viasocket-mcp": {
      "Transport": "http",
      "Url": "https://mcp.viasocket.com/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add com-viasocket-mcp -t streamable-http -u 'https://mcp.viasocket.com/mcp'
```

### Other

```json
{
  "mcpServers": {
    "com-viasocket-mcp": {
      "type": "http",
      "url": "https://mcp.viasocket.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 66, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-04 (score 65, 0)

- [functional improvement] Stability: unverified → 0.03

### 2026-11-03 (score 65)

First indexed and scored.

## MCP tools (20)

### `search_viasocket_docs` (~57 tokens)

Search the viaSocket documentation with a natural-language question. Returns the most relevant passages with their page URLs.

Input parameters:

- `query` (string, required): What to look for, e.g. "how do I send a WhatsApp template message"

### `get_viasocket_api_docs` (~203 tokens)

Browse the viaSocket API docs, one level at a time. Call it without arguments to get the top level: the modules and pages with a short description and the endpoints they hold. Call it with `path` set to a module's or page's link (or path) to get what is inside it; each listing links the next level. Call it with `path` set to an endpoint's link ending in ".openapi.yml" to get that endpoint as an OpenAPI file: method, url, headers, query params, path variables, a request body example and sample responses. Fetch only the level you need.

Input parameters:

- `path` (string): A link from a listing, exactly as given (e.g. "https://docs.example.com/sms/llms.txt" or ".../sms/send-sms.openapi.yml"), or just the path ("sms", "sms/send-sms.openapi.yml"). Leave it out for the to…

### `call_any_api_of_viasocket` (~500 tokens)

Send a POST, PUT, PATCH or DELETE request to any viaSocket API endpoint for the user and return its response: every write (create, update, publish, delete). For GET requests use call_any_read_api_of_viasocket. Look the endpoint up with get_viasocket_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-viasocket-developer-hub skill first: it explains which tool to use when. Pass the full url with path variables filled in, the headers the docs list, query params in `query` (not in the url) and the JSON body in `body`. For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Only for the viaSocket endpoints documented on this server: it attaches the viaSocket sign-in, so never use it for Embarko (ship.embarko.ai) or any other service. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

Input parameters:

- `body` (object): JSON request body, as the endpoint's docs show it. Leave it out when the endpoint takes no body.
- `headers` (object, required): Request headers as name/value pairs, as the docs list them. Give the auth header (Authorization, proxy_auth_token, x-api-key, ...) an empty value "" so the signed-in user's token is filled in; never…
- `method` (string, required): HTTP method from the endpoint's docs
- `query` (object): Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true}
- `url` (string, required): Full endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here.

### `list_plugins` (~127 tokens)

List every viaSocket Developer Hub plugin (app) the user's organization owns. Send filter=getAllPlugins and identifier equal to the orgId in the path. Start here to find a pluginId (rowid).

Input parameters:

- `fields` (string): Optional comma-separated list of columns to return, e.g. rowid,name,status,iconurl
- `filter` (string): Required. Must be getAllPlugins. e.g. getAllPlugins
- `identifier` (string): Required. Your orgId (same as the path)
- `orgId` (string, required): Your viaSocket organization id

### `list_auth_versions` (~132 tokens)

List a plugin's authentication versions (filter=getAuthDetails, identifier=<pluginId>) to find an authid. Responses include decrypted client secrets: never show them to the user.

Input parameters:

- `fields` (string): Optional comma-separated columns
- `filter` (string): Required. getAuthDetails (all of a plugin's auth versions) or updateAuthDetails (one auth version by rowid). e.g. getAuthDetails
- `identifier` (string): Required. Plugin id for getAuthDetails; auth version rowid for updateAuthDetails
- `orgId` (string, required): Your viaSocket organization id

### `list_actions_and_triggers` (~140 tokens)

List a plugin's actions and triggers (filter=getAllActions, identifier=<pluginId>), or get one (filter=getActionDetails, identifier=<actionId>). Use it to find an actionId.

Input parameters:

- `fields` (string): Optional comma-separated columns, e.g. rowid,name,type,status
- `filter` (string): Required. getAllActions (by plugin) or getActionDetails (one action by rowid). e.g. getAllActions
- `identifier` (string): Required. Plugin id for getAllActions; action id for getActionDetails
- `orgId` (string, required): Your viaSocket organization id

### `list_action_versions` (~119 tokens)

List all versions of an action or trigger (filter=getActionVersions, identifier=<actionId>), with code, inputs, authid, status and verification status. Use fields to keep the response small.

Input parameters:

- `fields` (string): Optional comma-separated columns, e.g. rowid,versionid,status,verificationstatus
- `filter` (string): Required. Must be getActionVersions. e.g. getActionVersions
- `identifier` (string): Required. Action id
- `orgId` (string, required): Your viaSocket organization id

### `get_plugin_analytics` (~138 tokens)

Get run counts, error counts and flow counts for every action and trigger version of a plugin (filter=getPluginDetails, identifier=<pluginId>, optional startTime and endTime dates).

Input parameters:

- `endTime` (string): Optional end date. e.g. 2026-10-19
- `filter` (string): Required (access check). Use getPluginDetails. e.g. getPluginDetails
- `identifier` (string): Required. Plugin id
- `orgId` (string, required): Your viaSocket organization id
- `startTime` (string): Optional start date. e.g. 2026-10-01

### `get_org_details_by_token` (~74 tokens)

Get the viaSocket organization (id and details) that the signed-in user's token belongs to. Read-only, no inputs. Call this first whenever you need the organization id (orgId) for other viaSocket Developer Hub calls such as List Plugins, Get Plugin or analytics, instead of asking the user for it.

### `list_embed_projects` (~155 tokens)

List an organization's embed projects (type=embed) for viaSocket SDK setup. Each data.projects[].id is a project_id (VIASOCKET_PROJECT_ID). Reuse an existing embed: one embed serves a whole product. Only if there is none, create one with the Create Embed Project endpoint (via call_any_api) after the developer confirms.

Input parameters:

- `bringflows` (string): Optional. true also returns the flows of each project. e.g. false
- `orgId` (string, required): Organization id from Find Organizations or Get Org Details By Token
- `type` (string): Required. `embed` for SDK projects (`flow` and `default` are the workspace's own automation projects). e.g. embed

### `call_any_read_api_of_viasocket` (~407 tokens)

Read from any viaSocket API endpoint with a GET request for the user and return its response. Use it once you know the exact endpoint: look it up with get_viasocket_api_docs first to get its URL, headers, query params and body, unless the skill or a dedicated tool on this server already gives them exactly. Load the quickstart-viasocket skill first: it explains which tool to use when. For POST, PUT, PATCH and DELETE use call_any_api_of_viasocket. Pass the full url with path variables filled in, the headers the docs list, and query params in `query` (not in the url). For the auth header the docs name (Authorization, proxy_auth_token, x-api-key, ...), pass it with an empty value "": the signed-in user's token is filled in automatically. Never put a real or made-up token there; if the docs name no auth header, leave it out and the token is sent as Authorization. If the API needs the user to sign in, they're asked the first time. Returns { status, ok, headers, data }: the HTTP status and the response body, including error details on failure.

Input parameters:

- `headers` (object, required): Request headers as name/value pairs, as the docs list them. Give the auth header (Authorization, proxy_auth_token, x-api-key, ...) an empty value "" so the signed-in user's token is filled in; never…
- `query` (object): Query params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true}
- `url` (string, required): Full endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here.

### `report_feedback` (~475 tokens)

Report a problem to viaSocket while building with it: an error, a confusion, wrong docs or skills, a user correction, or a missing capability. Problems only, never success; no need to ask the user; a failed report never stops the task. Plugs: fix or extend the user's own plugs (the ones in list_plugins) yourself, and build a plug for an app that has none. A plug used in flows but not in list_plugins is viaSocket's: never edit it, report it here (refs.pluginId, refs.actionId; a missing action, trigger or field is kind missing_capability, with exactly what is needed and why). Body: source (sdk | http_api | plug | action | trigger | connection | skill | other), kind (error | confusion | missing_capability | wrong_instructions | user_correction) and feedback (what happened, in plain words), plus optional severity, stage, intent, attempted, expected, actual, error, refs, env and retries. Never include secrets, tokens or script_id. The org and user come from the sign-in.

Input parameters:

- `actual` (string): e.g. 500 INTERNAL
- `attempted` (string): e.g. Ran Send Message with channel and text from the document's sample
- `env` (object): e.g. {"sdkVersion":"0.7.0","framework":"nextjs","language":"typescript","client":"claude-code"}
- `error` (object): e.g. {"status":500,"code":"INTERNAL","message":"failed"}
- `expected` (string): e.g. Message posted
- `feedback` (string): e.g. Slack Send Message returns 500 on valid input; same call worked yesterday
- `intent` (string): e.g. Post to a Slack channel when an order is created
- `kind` (string): e.g. error
- `refs` (object): e.g. {"app":"slack","pluginId":"rowslack123","actionId":"rowsendmsg01","requestId":"req_abc"}
- `retries` (number): e.g. 2
- `severity` (string): e.g. degraded
- `source` (string): e.g. action
- `stage` (string): e.g. actions_and_events

### `report_published` (~242 tokens)

Call once right after you publish something on the user's own plug (one in list_plugins): a new plug, or a new action, trigger, version or connection on it. viaSocket then reviews the published plug and may add missing actions or triggers. Body: pluginId (the plug rowid, required), published (new_plug | new_action | new_trigger | new_version | connection), plus optional app (the app's name), actionIds (rowids of the actions or triggers just published) and note (plain words, never secrets). No need to ask the user; a failed call never stops the task. The org and user come from the sign-in. Not for problems: use report_feedback for those.

Input parameters:

- `actionIds` (array): e.g. ["rowaction1234","rowtrigger567"]
- `app` (string): e.g. Tally
- `note` (string): e.g. Published privately with 4 actions and 1 trigger; OAuth 2.0 connection
- `pluginId` (string): e.g. rowtally12345
- `published` (string): e.g. new_plug

### `get_viasocket_embed_secret` (~156 tokens)

Gets the viaSocket organization's embed signing secret (VIASOCKET_EMBED_SECRET) into the developer's .env encrypted, so you never see it. Use it in SDK setup. Get orgId with get_org_details_by_token first. Before calling, run `docstar-cli key request` in the project folder and pass its publicKey; then run the `save` command this tool returns, then its `emit` command (the developer can choose another .env file). Never ask for, print or repeat the secret.

Input parameters:

- `orgId` (string, required): The orgId the key is created for
- `publicKey` (string, required): The publicKey printed by `docstar-cli key request`, exactly as printed

### `list_connections` (~98 tokens)

The app accounts the signed-in user has already connected to viaSocket. Body {} answers rows with auth_id, service_id, service_name and connection_label (a JSON string: parse it before showing it, e.g. the email of the Gmail account). Match service_id to find the auth_id an action or automation needs; if the user has several accounts of one app, ask which. If the app is not there, use create_connection_link.

### `create_connection_link` (~113 tokens)

Make a sign-in link so the user connects an app account (Google, Slack, an API key…) to viaSocket. Body { "service_ids": ["<service_id>"] } answers data[] with a connection_url per app. Give the user the link, wait until they say they signed in, then call list_connections again to get the auth_id. It only makes the link; nothing is connected until the user signs in.

Input parameters:

- `service_ids` (array): e.g. ["rowbu58rc"]

### `run_app_action` (~266 tokens)

Do one thing in the user's app right now, on their own account: send an email, post a message, add a row, create a record, fetch data. Body { service_id, action_id, auth_id, instructions, thread_id }: service_id from search_apps, action_id from list_app_actions, auth_id from list_connections, instructions in plain words carrying every value (recipient, subject, body, sheet name…), thread_id an id you make up and reuse for retries of the same request. viaSocket's builder turns the instructions into the action's input and runs it; the reply is the app's own result. It acts for real, so say exactly what it will do (which account, which action, which values) and get the user's yes first. For something that should happen repeatedly ("every time", "every morning"), build an automation instead, as the skill describes.

Input parameters:

- `action_id` (string): e.g. row1jrbor
- `auth_id` (string): e.g. authAbC123xyz
- `instructions` (string): e.g. List the channels in the workspace
- `service_id` (string): e.g. rowbu58rc
- `thread_id` (string): e.g. slack-send-message-sales

### `search_apps` (~126 tokens)

Find an app the user wants to use from their AI: Gmail, Slack, Google Sheets, HubSpot, Notion, Trello or any of 2,300+ apps. Body { "searchquery": "gmail" } answers services[] with service_id, service_name and service_description. This is the first step whenever the user asks to send, read, create, update or search something in one of their apps, or to automate something across apps. The catalog is public: no sign-in needed for this call.

Input parameters:

- `searchquery` (string): e.g. slack

### `list_app_actions` (~113 tokens)

List what an app can do for the user. Body { "serviceId": "<service_id from search_apps>" } (camelCase) answers actions[] with action_id, action_name, action_description and fields_for_action_details. Use it to pick the action that matches the request (Gmail "Send Email", Google Sheets "Add Row", HubSpot "Create Contact") before connecting or running anything. Public catalog, no sign-in needed.

Input parameters:

- `serviceId` (string): e.g. rowbu58rc

### `quickstart-viasocket-developer-hub` (~149 tokens)

Quickstart for viaSocket: use the user's own apps from their AI (send an email, post to Slack, add a sheet row, read a CRM; any of 2,300+ apps), build automations (flows) across those apps, and for developers: build and manage viaSocket plugins in the Developer Hub, set up a product's viaSocket keys, give a product its own MCP server. Routes plug work through the plug skills index, product integration through the viaSocket skill, and Embarko deploy through Embarko's quickstart. Load this before any viaSocket task. Call this to load the full instructions for this skill before doing the task.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-viasocket-mcp/mcp#diagnostics

## Score history

- 2026-11-05: 66
- 2026-11-04: 65
- 2026-11-03: 65

## Common questions

### What is the viaSocket MCP server?

viaSocket is an MCP server listed in the public MCP registry as com.viasocket/mcp. Build and run automations across 2,300+ apps and build app integrations from any MCP client. This page covers its hosted endpoint (https://mcp.viasocket.com/mcp).

### Is the viaSocket MCP server safe to use?

viaSocket scores 66 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the viaSocket MCP server expose?

viaSocket exposes 20 tools: search_viasocket_docs, get_viasocket_api_docs, call_any_api_of_viasocket, list_plugins, list_auth_versions, and 15 more. Their descriptions and schemas cost roughly 3,790 tokens of context every time the server is loaded.

### Does the viaSocket MCP server require authentication?

No. We connected to viaSocket without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the viaSocket MCP server still maintained?

viaSocket is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://mcp.viasocket.com/mcp
- Website: https://viasocket.com/
- Changelog RSS feed: https://verifymcp.io/servers/com-viasocket-mcp/mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-viasocket-mcp/mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-viasocket-mcp/mcp