Skip to main content
Glama
Sign In
Cloady

Cloady

Official
by Cloady
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Ask Ai

askAi
Destructive

Ask an AI model questions and get answers about your Cloady account; with an API key, also write, upload, and deploy files or open support tickets.

Instructions

Public: without credentials a caller gets 7 answers a day per IP address. An API key or a signed-in session gets 60 an hour and answers about its own account, and can build: the AI writes files, uploads them and deploys them, which a read-scope key cannot. A key that isn't valid is refused rather than answered anonymously. Requests with deployment tools can take up to two hours; read-only and anonymous requests have a ten-minute deadline. Set the client timeout accordingly. deploy names a template, repository or image the answer suggests deploying. To carry the conversation on with Cloady support, open a ticket with createTicket: the AI answers it first.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "askAi"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestBodyNoThe JSON request body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.18.0

TDQS

A3.6/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 known. The description adds genuinely useful behavior beyond that: invalid keys are refused rather than downgraded to anonymous, deployment-capable requests can run up to two hours versus a ten-minute deadline, and the AI can write, upload and deploy files. It does not describe the response shape, streaming behavior, or whether a partially completed deploy can be aborted.

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

Conciseness3/5

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

Every sentence carries substantive information, but the paragraph is front-loaded with quota mechanics rather than purpose, and several sentences chain three or four clauses together (auth, rate limit and capability in one breath). It reads as a knowledge dump rather than a structured tool brief, which slows an agent trying to extract the call contract.

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 destructive, open-world, nested-parameter tool with no output schema, the description covers the critical operational risks: credential tiers, refusal of invalid keys, and widely varying request deadlines that affect client timeout settings. Gaps remain around the return value and the unexplained `deploy` reference, but an agent has enough to call it correctly.

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 100%, so the schema already documents q, model, workspace and providerOptions, making 3 the baseline. The description adds meaning only for a `deploy` field that does not appear anywhere in the input schema, which is more confusing than clarifying, and it says nothing about `workspace` scoping or how providerOptions interact with the selected model.

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

Purpose4/5

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

The description establishes an AI-answer resource through phrases like 'gets 7 answers a day' and 'the AI writes files, uploads them and deploys them,' which separates it from siblings such as generateImage and createTicket. It never states the core purpose outright in a single declarative sentence, opening instead with rate limits, so the verb+resource pairing has to be inferred from context.

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 clearly delineates access contexts: anonymous callers get 7/day per IP, key or session holders get 60/hour and account-scoped answers, and read-scope keys cannot build. It also routes continuation of a support conversation to createTicket. What is missing is any explicit when-not-to-use guidance or a named competing sibling for plain Q&A.

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