Skip to main content
Glama
viftode4
by viftode4

read_group_locker

Read-onlyIdempotent

Retrieve the shared locker files and links for a group you belong to by providing course and group IDs. Verifies membership before returning visible items.

Instructions

Read the shared locker page for an exact group you belong to. Use groupId from get_my_groups. Verifies membership and returns visible files and links; does not upload, delete or download locker files.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupIdYesExact Brightspace numeric identifier from another tool.
courseIdYesExact Brightspace numeric identifier from another tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations, the description adds valuable behavioral context: membership verification, the return contents ('visible files and links'), and exclusions ('does not upload, delete or download'). This is significant extra transparency, especially with no output schema present.

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

Conciseness5/5

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

Each of the three sentences earns its place: purpose, parameter source, and behavioral scope. It is front-loaded with the main action and avoids redundant restatement of the tool name or annotations.

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?

Given no output schema, the description adequately conveys the return type ('visible files and links'), the membership requirement, and the non-mutating scope. It could more explicitly distinguish this tool from list_group_locker_files or describe output structure, but it is sufficiently complete for invoking the tool 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?

The schema already describes both parameters as 'Exact Brightspace numeric identifier from another tool', so schema coverage is 100%. The description adds one useful hint ('Use groupId from get_my_groups'), but does not substantially expand on each parameter beyond the schema.

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 states a specific action ('Read the shared locker page') and a specific resource ('exact group you belong to'), and explicitly lists what it does not do ('does not upload, delete or download locker files'). This clearly differentiates it from file-level siblings like list_group_locker_files and read_group_locker_file.

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 gives clear usage context: read the page for an exact group you belong to, and use groupId from get_my_groups. It does not explicitly name alternatives or say when not to use this tool, but the constraints are strong enough for an agent to select it appropriately.

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