Skip to main content
Glama
Sign In

uCoz

by io.github.ucoz-skills
OverviewDiscussionsAdmin

Read site files

files_read
Read-onlyIdempotent

Lists files and folders of the site file manager, returns file info and quota, reads text files.

Input Schema

NameRequiredDescriptionDefault
pageNoList page, from 1.
pathNoClean path without edge slashes, passed as a parameter (never as a URL suffix). Empty string is the site root; content_get, content_put and mkdir need a non-empty path. Allowed bytes are A-Z a-z 0-9 . _ / -; segments cannot be empty, ".", "..", or start with a dot. Folder for list, info, upload, upload_url and move; file for content_get and content_put; new folder for mkdir; source for rename, move and delete.
sortNolist: name (default), size, or mtime. Anything else is treated as name.
limitNolist: the earlier name of per_page; per_page wins when both are set, and 0 counts as not set.
orderNolist: asc (default). Only desc changes direction.
actionYesOperation to run. Each oneOf entry describes one action and lists its parameters.
detailNoRecord form of a paged list. brief (default): name, path, type, size, objects in a folder and modification time (UTC, ISO 8601). Titles and excerpts are plain text; names, logins, paths, URLs and other identifiers are as the source gives them. full: complete records. A list reply is at most 30 KB and holds every record of its page: a record that does not fit in full comes in brief form, marked detail brief, the reply counts such records in brief_records, and get by id returns the complete record; brief records shorten their excerpts, then keep only their ids and titles. Only a page that does not fit even so is cut: truncated is true and next names the offset to go on from.
filterNolist: a quota.limits.filters name, or a comma-separated extension list (png,jpg). Unknown names are ignored.
offsetNoRecords to skip from the start of a list; overrides page. A list reply cut at its size limit names the offset that follows in next.
per_pageNoRecords per page: 1-50, 20 by default, larger values count as 50.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / action / oneOf
      Previous value: -[
-  {
-    "const": "list",
-    "description": "Lists a folder of the site file manager (default: site root, sorted by name, no filter). Optional: path, filter, sort, order, offset, limit."
-  },
-  {
-    "const": "info",
-    "description": "Returns information about a file or folder. Optional: path."
-  },
-  {
-    "const": "quota",
-    "description": "Returns the disk quota and the upload limits (size, allowed filters)."
-  },
-  {
-    "const": "content_get",
-    "description": "Reads a text file. Other files come back as FM_NOT_TEXT or FM_TOO_LARGE_TO_READ. Required: path."
-  }
-]New value: +[
+  {
+    "const": "list",
+    "description": "Lists a folder of the site file manager (default: site root, sorted by name, no filter) a page at a time. Brief entries by default; detail=full gives complete entries. The reply has page, per_page, total, has_more, truncated and next. Optional: path, filter, sort, order, page, per_page, offset, detail, limit."
+  },
+  {
+    "const": "info",
+    "description": "Returns information about a file or folder. Optional: path."
+  },
+  {
+    "const": "quota",
+    "description": "Returns the disk quota and the upload limits (size, allowed filters)."
+  },
+  {
+    "const": "content_get",
+    "description": "Reads a text file. Other files come back as FM_NOT_TEXT or FM_TOO_LARGE_TO_READ. Required: path."
+  }
+]
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Record form of a paged list. brief (default): name, path, type, size, objects in a folder and modification time (UTC, ISO 8601). Titles and excerpts are plain text; names, logins, paths, URLs and other identifiers are as the source gives them. full: complete records. A list reply is at most 30 KB and holds every record of its page: a record that does not fit in full comes in brief form, marked detail brief, the reply counts such records in brief_records, and get by id returns the complete record; brief records shorten their excerpts, then keep only their ids and titles. Only a page that does not fit even so is cut: truncated is true and next names the offset to go on from.",
+  "enum": [
+    "brief",
+    "full"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / limit / description
      Previous value: -"list: slice length. 0 (default) means the rest of the listing."New value: +"list: the earlier name of per_page; per_page wins when both are set, and 0 counts as not set."
    • changedInput schema / properties / offset / description
      Previous value: -"list: slice start after sorting. Default 0."New value: +"Records to skip from the start of a list; overrides page. A list reply cut at its size limit names the offset that follows in next."
    • addedInput schema / properties / page
      Added value: +{
+  "description": "List page, from 1.",
+  "type": "number"
+}
    • addedInput schema / properties / per_page
      Added value: +{
+  "description": "Records per page: 1-50, 20 by default, larger values count as 50.",
+  "type": "number"
+}
  2. Added

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds almost nothing beyond them; the one useful nugget, that only text files can be read, is stated more completely in the schema's content_get entry. No mention of auth requirements, size limits, or error 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?

A single front-loaded sentence that leads with the primary list capability and then covers the secondary actions. Nothing is padded, though for a 4-action, 10-parameter tool the compression is close to under-specification rather than tight writing.

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?

No output schema exists, so return values are opaque at the description level, and with four distinct actions and ten parameters the one-sentence summary is thin. It is rescued by unusually rich enum and parameter descriptions in the schema, which supply the action-to-parameter mapping, but the overview itself does little for an agent deciding between content_get and content_read.

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% and the action enum's oneOf entries exhaustively document which parameters each action takes, so the description need not carry parameter meaning. It adds none, which is the correct baseline of 3 when the schema does all the work.

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 the resource (site file manager) and four concrete operations: list, info, quota, and read text content. It is clearly a read-side tool, so it is distinguishable from files_write and files_delete. It stops short of naming any sibling explicitly, which keeps it at 4 rather than 5.

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?

It enumerates what the tool can do but never says when to choose it over alternatives — notably content_read, which appears to overlap with content_get, or when a caller should use files_write/files_delete for the mutation side. The only routing signal is the action enum, which is schema data, not description guidance.

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

All uCoz toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources