Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Import Provider Service

importProviderService
Destructive

Reads one provider service and returns a deployApp-ready source plus its variables, including secrets; the token is one-shot and no deploy occurs until deployApp is called.

Instructions

Reads one service from the provider and returns what deployApp needs to recreate it: a source to pass to deployApp as it is, and the service's variables in values, secrets included. A service that runs an image comes back as an upload staged for it, deleted if no app uses it within three hours. The token is used for this call only and never stored, and nothing is deployed until deployApp is called.

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": "importProviderService"
  }
}

Input Schema

NameRequiredDescriptionDefault
providerYes
requestBodyNoThe JSON request body.
workspaceSlugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations mark this as destructive and open-world, and the description earns that by explaining the side effect: image-based services return a staged upload that is deleted if unused within three hours. It also discloses credential handling (token used for this call only, never stored), which is exactly the extra context annotations cannot carry. It does not spell out what gets destroyed or permission requirements beyond that.

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?

Four dense sentences with no filler; the critical constraints (token not stored, nothing deployed yet) are placed last as guardrails. Slightly heavy on output-shape detail, but every sentence carries a distinct obligation or caveat.

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?

With no output schema, the description must explain returns and does so precisely (`source`, `values` including secrets, staged upload for image services). For a nested three-parameter mutation with a destructive side effect it is close to sufficient; the main gap is provider/env selection semantics that neither schema nor description fully explain.

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 coverage is only 33%, so the description carries more burden than it takes on. It adds meaning for the token (one-shot, never stored) and describes the returned `source`/`values`, but leaves `provider`, `env`, and `workspaceSlug` — plus the `scope` field's provider-specific meaning — entirely to the schema.

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 names a specific verb+resource ("Reads one service from the provider") and immediately frames its role relative to siblings: it returns what deployApp needs to recreate the service. An agent can distinguish it from listImportableServices and deployApp without inspecting either schema.

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?

It establishes the pipeline context clearly — this is the read/import step that precedes deployApp, and "nothing is deployed until deployApp is called" defines that boundary. It stops short of explicit when-not guidance or naming listImportableServices for service discovery (that link appears only in the schema).

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