Skip to main content
Glama

cloud_recall

Read-only

Retrieve a full shared cloud record without importing it, or list and search records with paging by id, query, limit, and offset.

Instructions

Read a full shared cloud record without importing it by passing id, or list/search using the existing paging contract.

Input Schema

NameRequiredDescriptionDefault
idNoFull read without importing; omit to list/search.
cloudNo
limitNo
queryNo
offsetNo
initiativeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changedv0.8.0
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / cloud / default
      Removed value: -null
    • removedInput schema / properties / cloud / description
      Removed value: -"Cloud name to query in a multi-cloud setup. Required when several are\nconfigured."
    • addedInput schema / properties / cloud / minLength
      Added value: +1
    • changedInput schema / properties / cloud / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • addedInput schema / properties / id
      Added value: +{
      +  "description": "Full read without importing; omit to list/search.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • removedInput schema / properties / initiative / description
      Removed value: -"Initiative to list shared cloud nodes for."
    • addedInput schema / properties / initiative / minLength
      Added value: +1
    • removedInput schema / properties / limit / default
      Removed value: -null
    • removedInput schema / properties / limit / description
      Removed value: -"Page size, default 25, ceiling 500. A shared initiative can hold\nhundreds of nodes — more than a context window — so this read is\nbounded like every other list on the surface."
    • removedInput schema / properties / limit / format
      Removed value: -"uint"
    • changedInput schema / properties / limit / type
      Previous value: -[
      -  "integer",
      -  "null"
      -]New value: +"integer"
    • removedInput schema / properties / offset / default
      Removed value: -null
    • removedInput schema / properties / offset / description
      Removed value: -"How many to skip, for the next page. The result says when there is one."
    • removedInput schema / properties / offset / format
      Removed value: -"uint"
    • changedInput schema / properties / offset / type
      Previous value: -[
      -  "integer",
      -  "null"
      -]New value: +"integer"
    • removedInput schema / properties / query / default
      Removed value: -null
    • removedInput schema / properties / query / description
      Removed value: -"Search the cloud instead of listing it: a case-insensitive substring\nover shared node names and excerpts. Omit to list everything shared."
    • changedInput schema / properties / query / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • removedInput schema / title
      Removed value: -"CloudRecallParams"
  2. First observedv0.7.5

TDQS

B3.4/5.0
Behavior3/5

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

readOnlyHint=true already establishes the safety profile, so the lower bar applies. The description does add real value by clarifying the non-importing semantics, but it leaves the 'existing paging contract' undefined and says nothing about result limits or ordering behavior.

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?

One sentence, front-loaded with the primary action and followed by the branching condition — no filler. The phrase 'existing paging contract' is mildly opaque jargon that assumes external knowledge, which keeps it from a 5.

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?

There is no output schema, so the description should carry more of the return-shape and paging burden, and the required 'initiative' parameter is never explained at all. Adequate to attempt a call, but an agent would need to guess on several parameters.

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 17% across six parameters, so the description must compensate. It usefully explains the id parameter's dual role and gestures at paging via 'paging contract,' but cloud, query, offset, and the required initiative parameter get no semantic explanation anywhere.

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 names a specific verb and resource ('Read a full shared cloud record') and distinguishes two modes: full read by id versus list/search. It separates itself from the nearby 'pull'/'clouds' siblings conceptually via 'without importing it,' though it doesn't name them.

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

Usage Guidelines3/5

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

It gives one explicit routing rule ('by passing id, or list/search' — omit id to list), which implies when each mode applies. However, with siblings like pull, clouds, cloud_links, and link_cloud present, it never states when to prefer this tool over those, leaving the main ambiguity unresolved.

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