Skip to main content
Glama
kuklaph
by kuklaph

Read Access Rights

cascade_read_access_rights
Read-onlyIdempotent

Check who has read or write access to a Cascade asset by retrieving its ACL entries and default permission level.

Instructions

Read access rights (users/groups + permission levels) for a Cascade asset.

Returns the complete ACL (access control list) for an asset: which users and groups can read or write it, and what the default level is for everyone else. Access levels are "none", "read", and "write" for allLevel, and "read" or "write" for explicit ACL entries. Useful for auditing permissions before sharing content or before a bulk edit.

Args:

  • identifier (object, required): The asset whose ACL to read

    • id (string, optional): Asset ID (preferred)

    • path (object, optional): { path, siteId OR siteName }

    • type (string, required): Entity type of the asset

Returns: Cascade OperationResult: { success: true, accessRightsInformation: { identifier: { ... }, aclEntries: [ { name, type: "user"|"group", level }, ... ], allLevel: "none"|"read"|"write" } } On failure: { success: false, message: "" }

Examples:

  • Use when: "Who has edit access to /about?" -> { identifier: { type: "folder", path: { path: "/about", siteName: "www" } } }

  • Use when: "Audit page permissions" -> { identifier: { type: "page", id: "..." } }

  • Don't use when: You want to change permissions — use cascade_edit_access_rights.

  • Don't use when: You want workflow settings — use cascade_read_workflow_settings.

Error Handling:

  • "Asset not found" when the identifier doesn't resolve

  • "Permission denied" when credentials lack admin/read-acl rights. Responses are JSON text; structuredContent is authoritative when the response fits. Oversized responses return bounded _cache metadata for cascade_read_response. For cascade_read, read_mode controls preview versus raw Cascade payload shape.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
identifierNoThe asset or container whose access rights to read.
Behavior4/5

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

Annotations already mark the tool as read-only and idempotent. The description adds useful behavioral context (e.g., error handling, response format includes structuredContent, and oversized responses return _cache metadata). However, it includes a tangential mention of cascade_read and read_mode that may be slightly confusing.

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 well-structured with sections but contains redundant or extraneous details (e.g., 'Responses are JSON text...' paragraph seems generic and not specific to this tool). It could be more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having only one parameter and no output schema, the description thoroughly explains the input structure, return shape (including ACL entries and allLevel), error messages, and usage examples, making it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a brief description. The description significantly adds value by detailing the identifier's nested structure (id, path, type) and providing concrete examples, greatly aiding correct parameter usage.

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 clearly states the tool reads access rights for a Cascade asset, details the ACL and permission levels, and distinguishes itself from siblings like cascade_edit_access_rights and cascade_read_workflow_settings.

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

Usage Guidelines5/5

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

The description explicitly provides when-to-use (e.g., 'Who has edit access to /about?') and when-not-to-use (e.g., for changing permissions, use cascade_edit_access_rights; for workflow settings, use cascade_read_workflow_settings). It also includes error handling guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kuklaph/cascade-cms-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server