Skip to main content
Glama

list_children

Retrieve enrolled children, optionally filtered by school ID, with support for pagination via limit and offset parameters.

Instructions

List children enrolled, optionally filtered by school.

Use when: "show me all children at school 1234" or "list the next 50 children across all schools." Combine with offset for pagination.

Args: school_id: restrict to one school within the enterprise account. limit: max records to return (server-side cap applies). offset: skip N records for pagination.

Example: list_children(school_id="abc-123", limit=20) returns [{"id": "...", "first_name": "...", "last_name": "...", ...}, ...].

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
school_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

No annotations are provided, so the description bears the full burden. It discloses pagination behavior (offset) and a server-side cap on limit, and shows an example output. It lacks mention of read-only nature, authentication, or error handling, but for a list tool this is adequate.

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 concise and well-structured: purpose, usage guidance, parameter descriptions, and an example. Every sentence adds value with no redundancy.

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?

Given the presence of an output schema, the description covers the tool's purpose, usage, parameters, and pagination behavior. The example output compensates for missing schema details. No critical gaps remain.

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?

The schema coverage is 0%, but the description explains all three parameters in detail: school_id for restriction, limit with a server cap, offset for pagination. The example demonstrates usage and output format, adding significant value 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 clearly states the tool's verb ('List') and resource ('children enrolled'), with an example that distinguishes it from sibling list tools (e.g., list_classrooms) by specifying the resource type. The usage examples confirm it is for listing children.

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?

The description explicitly says 'Use when' with two example queries, covering filtered and unfiltered cases, and mentions pagination with offset. However, it does not provide 'when not to use' or explicitly name alternatives like get_child.

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/sanjibani/procare-mcp'

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