Skip to main content
Glama

get-files

Read-only

Retrieve file objects from Concrete CMS sorted by last updated, newest first, with configurable limits and optional custom attributes.

Instructions

Returns a list of file objects, sorted by last updated descending. The most recent file objects appear 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": "get-files"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoThe number of objects to return. Must be 100 or less. Defaults to 10.
includesNoincludes parameter

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0-alpha.1

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the meaningful behavioral detail that results are sorted by last-updated descending, but says nothing about pagination, total counts, or what happens when more files exist than the limit — relevant context for a list operation.

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?

The description is short and front-loaded, but the second sentence ("The most recent file objects appear first") is a pure restatement of "sorted by last updated descending" and earns no additional place. That space would be better spent on pagination or scope information.

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?

For a simple read-only list tool with fully documented parameters and no output schema, the description needs only enough to establish scope and ordering behavior. Ordering is covered, but the absence of any note on file scope, pagination, or return volume leaves a modest gap.

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 both parameters (limit with its 100 cap and default of 10, and includes) are fully documented in the schema. The description adds no parameter-level meaning beyond that, which is acceptable given the schema carries the burden.

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 states a specific verb and resource — returning a list of file objects — and adds the default ordering (last updated descending), which distinguishes it from get-file-by-id. It stops short of naming sibling tools or stating the scope of files covered (e.g. all files vs. a workspace).

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no mention of when to prefer get-file-by-id, and no statement about pagination or how the fixed ordering interacts with the limit parameter. The agent must infer that this is the enumeration tool from the name alone.

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