Skip to main content
Glama

Velane Cloud

by sh.velane.mcp

list_connections

List OAuth integrations connected for this tenant.

IMPORTANT — how to use integrations in workflow code:

Bun/TypeScript: import { integration } from '@velane/integrations' const client = integration('github') // provider slug const user = await client.get('/user') // GET const issue = await client.post('/repos/org/repo/issues', // POST { title: 'Bug', body: 'Details' }) await client.patch('/repos/org/repo/issues/1', { state: 'closed' }) await client.delete('/repos/org/repo/labels/old')

Python: from velane.integrations import integration client = integration("salesforce") cases = client.get("/services/data/v60.0/sobjects/Case/describe") result = client.post("/services/data/v60.0/sobjects/Case", {"Subject": "Login issue", "Status": "New"})

Methods: .get(path) .post(path, body) .patch(path, body) .put(path, body) .delete(path) All methods return parsed JSON. Paths are the provider's native API paths. @velane/integrations is always available — no install, no credentials needed in code. Call get_integration_docs(provider) to look up endpoints for any provider.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (default 50).
offsetNoNumber of results to skip for pagination.
providerNoFilter by provider/alias substring, e.g. 'github'.

TDQS

A3.6/5.0
Behavior3/5

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

There are no annotations, so the description carries the full behavioral burden. The word 'List' implies a read-only operation and tenant scoping is stated, but the description does not disclose the return shape, pagination behavior, or authentication expectations. The extensive code examples describe the integration client's behavior, not this tool's behavior.

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

Conciseness2/5

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

The purpose sentence is front-loaded, but the description is dominated by a lengthy TypeScript and Python tutorial on using integrations in workflow code. This content is not necessary for selecting or invoking list_connections, making the description significantly over-specified.

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

Completeness3/5

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

The description provides tenant scope, a pointer to get_integration_docs, and useful context about using integrations in code afterward. However, with no output schema, it omits the shape of the returned connection list, and the available space is spent on code examples rather than details about the tool's own behavior.

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

Parameters3/5

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

The input schema already documents all three parameters with descriptions, so the baseline is 3. The code examples clarify that provider values are provider slugs, but the schema already includes 'github' as an example; no significant additional parameter semantics are added.

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 first sentence states a specific verb and resource: 'List OAuth integrations connected for this tenant.' It also directs the agent to get_integration_docs for endpoint lookup, which clearly distinguishes this tool from that sibling.

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

Usage Guidelines4/5

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

The description gives clear context for when this tool is relevant: list connections, then use them in workflow code via integration(). It explicitly names get_integration_docs as the alternative for endpoint lookups. It lacks explicit when-not-to-use language, but the role of the tool is clear.

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

All Velane Cloud toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose: workflow lifecycle, invocation, logging, metrics, KV store, secrets, connections, and documentation. Even similar tools like get_logs vs get_invocation are well-differentiated by descriptions.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (create_workflow, get_workflow, list_workflows). The KV tools (kv_get, kv_set, kv_list, kv_delete) are internally consistent but deviate from the dominant verb_noun style by using a noun_verb prefix.

Tool Count4/5

With 18 tools, the count is slightly above the typical 3-15 range, but the broad platform scope (workflow management, invocation, logging, metrics, KV, secrets, connections, docs) justifies each tool's existence. No tool feels redundant.

Completeness3/5

Workflows have create, read, update (via update_draft), list, and publish, but lack a delete operation. Secrets support create and list but no delete/update, and connections only have list. These lifecycle gaps create potential dead ends for agents.

Resources