parentsquare-mcp

by jasonko

Overview Schema Source Related Servers Discussions Admin

Python

Remote

remove_class_staff

Remove teachers, assistants, or room parents from a class by user ID or role, without altering other staff assignments.

Instructions

Remove staff or room parents from a class. Requires PS_ENABLE_WRITES.

SAFETY: Never call this tool or add_class_staff in parallel, even for different sections. ParentSquare replaces the full staff list, and concurrent writes have caused unrelated associations to disappear. The server serializes calls within this process; still use one call at a time and verify with a fresh get_class read before the next class-staff write.

Pass user_ids to remove specific people, role to remove everyone holding that role on the class (e.g. role="ROOM_PARENT" clears that class's room parents), or both to remove only those people who hold that role. Everyone else on the class is preserved. To clear room parents school-wide, call list_classes and repeat this for each class with room_parent_count > 0.

Args: section_id: Class/section ID (from list_classes) user_ids: One or more people to remove (optional if role is given) role: Remove all holders of this role: TEACHER, ASSISTANT, or ROOM_PARENT

Input Schema

TableJSON Schema

Name	Required	Description	Default
`role`	No
`user_ids`	No
`section_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 9, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries full disclosure. It states the PS_ENABLE_WRITES requirement, warns that ParentSquare replaces the full staff list and that concurrent writes can cause unrelated associations to disappear, recommends serialization and verification with a fresh get_class read, and clarifies that everyone else on the class is preserved. This is thorough and candid.

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?

The description is focused and front-loaded: purpose first, then a labeled SAFETY section, then usage modes. Every sentence carries operational value; there is no filler. The structure makes critical warnings prominent without burying the core instructions.

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?

For a mutation tool with multiple invocation patterns, the description covers prerequisites, side effects, concurrency risks, parameter semantics, and a step-by-step workflow for a complex scenario (school-wide clearing). An output schema exists, so return details are not necessary here. Nothing needed to call it correctly is missing.

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 description coverage is 0%, so the description must explain each parameter and it does: section_id is defined as 'Class/section ID (from list_classes)', user_ids as 'One or more people to remove', and role as 'Remove all holders of this role: TEACHER, ASSISTANT, or ROOM_PARENT'. It also explains how they interact (both to filter by role+user), adding value far 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 opens with 'Remove staff or room parents from a class.' This is a specific verb+resource with clear scope. It also distinguishes from the sibling add_class_staff by mentioning it in the safety note, so an agent can tell them apart without opening the schema.

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 provides explicit when-to-use guidance: it explains the three modes (user_ids, role, both), gives a concrete example for ROOM_PARENT, and instructs on school-wide clearing via list_classes. It also warns against parallel calls with add_class_staff, clarifying the alternative. No ambiguity remains.

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