Skip to main content
Glama

viaSocket

call_any_api_of_viasocket

Destructive

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 Schema

NameRequiredDescriptionDefault
urlYesFull endpoint URL with path variables replaced by real values, e.g. https://api.example.com/users/42. Put query params in `query`, not here.
bodyNoJSON request body, as the endpoint's docs show it. Leave it out when the endpoint takes no body.
queryNoQuery params as name/value pairs; an array sends the param once per item. Example: {"type": "flow", "bringflows": true}
methodYesHTTP method from the endpoint's docs
headersYesRequest 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 put a token here yourself. Pass {} when the endpoint needs no headers. Example: {"proxy_auth_token": "", "Content-Type": "application/json"}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as destructive, non-idempotent, and open-world, but the description adds substantial behavioral context: auth headers must be passed with an empty value, the signed-in user's token is filled automatically, a sign-in prompt may appear on first use, and the response shape is { status, ok, headers, data } including error details. It also clarifies the tool attaches the viaSocket sign-in and must not be used for other services.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and the read/write distinction, then proceeds through docs lookup, skill loading, parameter passing, and auth behavior. It is appropriately detailed for a destructive open-world tool, but several sentences restate schema guidance already present in the input schema, making it longer than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity—five parameters, required auth handling, destructive annotations, and no output schema—the description is complete. It explains how authentication is injected, how to pass headers and query parameters, how to obtain endpoint details, what the response contains, and which services the tool must not be used for.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines all five parameters in detail. The description reinforces key semantics—full URL with path variables filled in, query params in `query` rather than the URL, JSON body in `body`, and method restricted to POST/PUT/PATCH/DELETE—but much of this is already present in the schema. It adds marginal value with the fallback rule that if no auth header is named, the token is sent as Authorization.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: send POST, PUT, PATCH, or DELETE requests to any viaSocket API endpoint for the user. It explicitly distinguishes this write tool from its read-only sibling by naming call_any_read_api_of_viasocket and noting 'every write (create, update, publish, delete).' This is clear enough for an agent to distinguish it from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit routing rules: use call_any_read_api_of_viasocket for GET requests, look up the endpoint with get_viasocket_api_docs first, and load the quickstart-viasocket-developer-hub skill before proceeding. It also states a critical exclusion: only for viaSocket endpoints documented on this server, never Embarko or other services.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources