Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

List Importable Services

listImportableServices
Destructive

Lists the projects and services your provider token can access, marking each as importable or not with reasons. The token is used once and never stored.

Instructions

Lists the projects and services the provider token can see, each marked importable or not, with the reason. The token is used for this call only and never stored. Import one with importProviderService.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspaceSlug": "<workspaceSlug>",
      "provider": "<provider>"
    },
    "name": "listImportableServices"
  }
}

Input Schema

NameRequiredDescriptionDefault
providerYes
requestBodyNoThe JSON request body.
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description usefully adds that the token is one-shot and never stored, which matters for a credential-bearing call, but it never explains why the tool is flagged destructive or what side effects an outbound provider call could have — leaving a notable tension with the 'Lists' framing.

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

Conciseness5/5

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

Two short sentences, front-loaded with the operation and result shape, followed by the credential-handling note and the routing pointer. No restatement of the title, no padding.

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

Completeness4/5

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

For a three-parameter, nested-body, no-output-schema tool, the description covers what is returned (per-service importable flag with reason) and the credential contract. It omits error behavior for an invalid or under-scoped token and any rate-limit/outbound-call caveats, which is the main remaining hole.

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?

Schema description coverage is 33%: token and scope are documented inline, while provider and workspaceSlug have no descriptions. The description adds only the notion that the token's visibility (provider account/team scope) determines the results, and says nothing about the provider enum or the workspaceSlug, so it does not fully compensate for the gap.

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?

States a specific verb and resource ('Lists the projects and services the provider token can see') and adds the shape of the result ('each marked importable or not, with the reason'). It also names the follow-up sibling importProviderService, so the agent can place it precisely among the ~120 siblings.

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?

Usage is clearly implied: call this first with a provider token to see what is importable, then hand an item to importProviderService. The forward pointer is explicit, but there is no statement of when not to use it (e.g., an already-linked integration) or precondition ordering beyond the implicit discover-then-import flow.

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

Deploy Server

Other Tools