Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pickuppatrol-mcp Change my daughter's dismissal plan for tomorrow to after-school care"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for PickUp Patrol — the school dismissal app. Read and change how your children leave school: their weekly default plan, one-off changes for specific dates, and the school's dismissal options and cutoff times.
Developed and maintained by AI (Claude Code). Use at your own discretion.
app.pickuppatrol.net runs a ServiceStack JSON API
behind an Ionic/Vue SPA. There is no published API, but the service is reachable
server-side with an ordinary HTTPS request — no browser extension, no bot wall,
no captcha. The server signs in with your own email and password and holds the
resulting session in memory.
Every request shape is captured in docs/PICKUPPATROL-API.md,
read off the shipped client rather than guessed, and exercised against a real
account — reads, a write, and its restore.
Related MCP server: schoology-mcp
// .mcp.json
{
"mcpServers": {
"pickuppatrol": {
"command": "npx",
"args": ["-y", "@chrischall/pickuppatrol-mcp"],
"env": {
"PICKUPPATROL_USERNAME": "you@example.com",
"PICKUPPATROL_PASSWORD": "…"
}
}
}
}For local development, copy .env.example to .env and fill it in.
The server starts without credentials — it answers the host's install-time probe and only reports the configuration error on the first tool call.
Reads
Tool | What it gives you |
| The signed-in account and the students linked to it |
| Every student with their weekly defaults and review flag |
| One student in full |
| A student's weekly default plan, day by day |
| Day-by-day plans across a date range |
| One student, one date — including whether it is locked |
| A school's dismissal options and the rules each imposes |
| School profile, notify times, cutoff times, settings |
| Dates no plan can be set for, and dates already changed |
| Car numbers the school issued to this account |
| Credentials sign in and the API answers |
Writes — every one requires confirm: true. Without it the tool makes no
change and returns a dry-run of the exact payload it would send.
Tool | What it changes |
| Dismissal for one or more specific dates, or clears them back to the default |
| The weekly default plan, or clears every default |
| The school's "defaults need review" prompt |
Rules are enforced before anything is sent. Each dismissal option carries its
own requirements — a note, a car number, an early-dismissal time, or a
restriction to particular students. pup_set_plan checks them against the
school's own list and refuses with the school's wording, so a rejected write is
a validation message rather than an opaque 400.
Writes are verified by re-reading. A 2xx from PickUp Patrol is not proof: a
change made after the school's cutoff is accepted and silently ignored. Every
write re-reads the affected dates and compares the transportation id and the
note — never ModifiedDate, which advances on its own and would make every
write look successful. The note is part of the proof because every dismissal
option seen so far requires one, which makes a note-only edit ordinary: an
id-only comparison would report success from a field that never had to move.
The result says verified: true/false, and names the dates that did not move.
skills/pickuppatrol-api/ is a shell-out skill covering the same API with
curl and jq, for scripts or a machine where the server is not installed.
npm install
npm run build
npm test # fast
npm run test:coverage # coverage-enforced at 100%Tests never touch the network: the transport is injected, and the MCP tools run through a real in-memory client/server pair.
GetPlanEdit returns a date's override, not the effective plan. A date with
no specific plan reads back TransportationId: null even when the student has a
weekly default for that weekday. pup_get_plan passes that through as-is;
pup_list_students is where the weekly defaults live.
Sign-in is a session cookie, not a JWT. Authenticate returns
BearerToken: null on this deployment and sets ss-id/ss-pid/ss-opt. The
client keeps whichever the server returns and sends both, so a future switch to
JWTs needs no change here.
A rejected sign-in is never retried. PickUp Patrol counts failed attempts against the account and a lockout clears only through their support desk, so the error is cached and every later call fails instantly with the same message.
The weekly-default write is a read-modify-write of the whole student record,
because the API has no default-plans endpoint. The server always reads the
student immediately before writing, and changes only DefaultPlans.
Credentials live in .env (gitignored) or the MCP host's config, and are
never written to a result or a log.
MIT
A student's weekly default dismissal plan — how they normally leave school on each day of the week — and whether the defaults still need a parent review.
| Name | Required | Description | Default |
|---|---|---|---|
| student_id | Yes | Student id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the meaning of the returned data, especially the parent-review status, but it does not describe behavioral details like response shape, error cases, or any implicit constraints. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. The core concept is front-loaded, and the parenthetical definition of what a default plan means earns its place by making the tool self-explanatory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one parameter, the description sufficiently explains what the tool returns: the weekday-by-weekday default dismissal plan and the parent-review status. There is no output schema, so the description could be more explicit about the exact shape, but the current description is complete enough for an agent to know when and why to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the student_id parameter already has a helpful description noting it comes from pup_list_students. The tool description adds no additional parameter-level semantics, so the baseline of 3 is appropriate because the schema already carries the explanatory weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly: a student's weekly default dismissal plan, including whether it still needs parent review. This goes beyond the tool name by explaining what 'default plans' mean and what the caller can expect. It is distinguishable from siblings like pup_get_plan and pup_list_plans because it emphasizes 'defaults' and 'parent review', though it does not explicitly use a verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a student's default weekly dismissal plan and its review status. It does not explicitly say when to prefer this over pup_get_plan, pup_list_plans, or pup_set_default_plans, and it gives no when-not-to-use guidance. The intended use is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dismissal plan for one student on one date — the option in force, any note, the early-dismissal time, and whether the date is locked because the cutoff has passed.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| student_id | Yes | Student id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already signaling a safe read operation, the description adds value by explaining that the response includes a lock status tied to whether the cutoff has passed. It also clarifies the composition of the returned plan, which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the exact scope and return contents without filler. Every clause earns its place, and the dash-separated enumeration makes the payload easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two fully documented parameters, readOnlyHint=true, and no output schema, the description is complete enough. It tells the agent what will be returned, which is the main missing piece given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both required parameters with useful descriptions: date format is YYYY-MM-DD and student_id references pup_list_students. The tool description does not add parameter-level detail beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely identifies the resource: the dismissal plan for one student on one date, and enumerates the key fields returned (option in force, note, early-dismissal time, lock status). The singular scope distinguishes it from siblings like pup_list_plans and pup_set_plan, even though it uses a noun phrase rather than an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for one student on one date' gives clear context for when this tool is appropriate: a targeted lookup of a single plan. It does not explicitly name alternative tools or say when not to use it, but the scope is unambiguous enough for an agent to select it over list-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A school profile together with its per-weekday notify times and plan cutoff times, and the settings that decide whether parents may set plans at all.
| Name | Required | Description | Default |
|---|---|---|---|
| school_id | Yes | School id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares readOnlyHint=true, so the read-only nature is already established. The description adds value by enumerating the returned data: school profile, notify times, cutoff times, and settings. This gives the agent a clear expectation of the output structure without contradicting the annotation. It doesn't go into response format details, but the annotation lowers the bar for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that fronts the main object ('A school profile') and then lists the specifics. Every word contributes to the understanding, with no filler or redundancy. It is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description sufficiently conveys the primary contents of the response. It names the key components (profile, notify times, cutoff times, settings) without needing exhaustive schema-level detail. The absence of error handling or edge-case notes is acceptable given the tool's simplicity and the readOnly annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the school_id parameter, including its source ('from pup_list_students'), achieving 100% coverage. The description does not add any additional meaning to the parameter beyond echoing the schema. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource (school) and what it returns: a school profile, per-weekday notify times, plan cutoff times, and parent-restriction settings. It is distinct from sibling tools like pup_get_student or pup_get_session because it focuses on the school-level data. The verb 'get' is implied by the tool name and the description matches the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied through the parameter description 'School id, from pup_list_students', which suggests a prerequisite call to list students to obtain a valid id. However, there is no explicit guidance on when to choose this tool over alternatives, nor any exclusions. The context is minimal but not absent, so it meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The signed-in PickUp Patrol parent account: name, email, last sign-in, and the students linked to it. Start here to discover student and school ids.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context beyond that by naming exactly what the session contains and how it can be used to bootstrap discovery of related IDs, which is helpful given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the core meaning of the session object and adds the key usage hint about discovering IDs, making it easy for an agent to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only session getter with no output schema, the description covers the essential return contents and the intended entry-point use case. It could be marginally richer by noting that the linked students contain the IDs to be extracted, but overall it is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics for the description to clarify. The description appropriately reinforces that the tool is a simple starting point, matching the baseline expected for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 'The signed-in PickUp Patrol parent account' and lists the key fields returned: name, email, last sign-in, and linked students. It also explains its role as the starting point for discovering student and school IDs, which distinguishes it from sibling student/school-specific tools, though it lacks an explicit verb like 'returns' or 'gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Start here to discover student and school ids' gives clear contextual guidance for when to call this tool before other tools. It does not explicitly name alternatives or exclusions, but the entry-point framing is sufficient for a zero-parameter session retrieval tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One student in full, including the default dismissal plan for each weekday. Pass raw: true for the untouched API record.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the unprojected API record instead of the summary | |
| student_id | Yes | Student id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only. The description adds meaningful behavior by noting that the default response is a projected summary and that passing raw: true returns the untouched API record. It does not discuss auth or error behavior, but for a simple read-only fetch 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and the raw modifier placed second. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only fetch by ID with full schema coverage, the description sufficiently communicates what the default output includes and how to get the raw record. It does not describe not-found or error behavior, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description reinforces the raw: true behavior but does not add meaning beyond the schema's 'unprojected API record' wording. student_id is already described as coming from pup_list_students.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States that the tool returns one student's complete record and specifically calls out the default dismissal plan per weekday, which is a distinctive resource detail. It is clearly distinguishable from sibling tools like pup_list_students and pup_get_school.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One student in full' implies use when a single student's detailed record is needed, and the dismissal plan mention signals a likely use case. However, it does not explicitly contrast this tool with alternatives such as pup_list_students or pup_get_plan, so the when-to-use guidance is mostly inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the configured credentials sign in and the PickUp Patrol API answers. Reports the server version and the students the account can see.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the readOnlyHint=true annotation, the description adds meaningful context by specifying what the read actually does: it validates credentials, checks API responsiveness, and reports server version plus visible students. This goes beyond the annotation and gives the agent a clear expectation of the tool's behavior and output scope. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The primary purpose is front-loaded ('Verify the configured credentials sign in'), followed by the concrete outputs. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only health check with no output schema, the description provides everything an agent needs to decide whether to invoke it and to interpret its results: it reports server version and visible students. The only minor ambiguity is naming the student-report side effect, but the healthcheck framing makes it clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and no input schema properties, so the description does not need to explain parameter meaning. The description appropriately focuses on what the tool returns instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Verify') and resource (configured credentials + PickUp Patrol API), and distinguishes this healthcheck tool from data-list siblings like pup_list_students by framing the student report as part of a connectivity check. It also names concrete outputs: server version and visible students.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: this is the tool to run when you need to confirm credentials work and the API is reachable. However, it does not explicitly say when to prefer this over sibling tools like pup_get_session or pup_list_students, nor does it state exclusions such as 'use pup_list_students when you only need the student list.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The car numbers a school has issued to this account, for dismissal options where usesCarNumbers is true.
| Name | Required | Description | Default |
|---|---|---|---|
| school_id | Yes | School id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only safety profile is covered. The description adds useful context about the data scope ('issued to this account') and the usesCarNumbers condition, but it does not describe response format, pagination, or behavior when usesCarNumbers is false. Given the annotation coverage, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant content. It front-loads the primary output ('The car numbers...') and includes the key conditional context without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter, read-only list tool with an annotated schema. The description explains what is returned and the condition under which it is relevant. No output schema exists, but the return concept is straightforward enough that the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage: school_id is described as 'School id, from pup_list_students'. The tool description does not add further parameter-level meaning, so the schema already carries the burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (car numbers issued to the account) and the use case (dismissal options where usesCarNumbers is true). It is clear enough to distinguish this from siblings like pup_list_students or pup_list_transportations, though it relies on the tool name for the verb 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool applies: dismissal options where usesCarNumbers is true. It does not explicitly name alternatives or exclusions, but the stated condition gives an agent enough context to decide when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dates a plan cannot be set for at a school (holidays, closures, weekends), and optionally the dates in a range that already differ from the student defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | YYYY-MM-DD | |
| school_id | Yes | School id, from pup_list_students | |
| start_date | No | YYYY-MM-DD; with end_date, also return dates that differ from the default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds meaningful behavioral details about what date categories are included and the optional 'differs from defaults' behavior. However, it does not clarify output structure, ordering, whether the optional result is additive, or what happens if only one of start_date or end_date is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the core purpose and then states the optional behavior, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the annotations provide read-only safety, but there is no output schema and the description leaves some operational details unclear, such as the exact relationship between the non-school-day list and the 'differs from defaults' list, and how the date range parameters interact. It is adequate for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented well in structured form. The description reinforces the range/diff behavior but does not add significant semantic detail beyond what the schema already provides for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function as listing dates when a plan cannot be set at a school, with explicit categories such as holidays, closures, and weekends. It also mentions the optional behavior related to student defaults. It does not explicitly compare against sibling tools, but the resource and verb are specific enough to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this tool when determining dates a plan cannot be scheduled. The optional start/end date behavior is mentioned, but there is no explicit guidance on when to use this tool versus related siblings like pup_list_plans or pup_get_default_plans, nor are any exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Day-by-day dismissal plans across a date range for every student on the account, as PickUp Patrol returns them.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | YYYY-MM-DD | |
| start_date | Yes | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the safety profile, and the description adds that the data is returned as PickUp Patrol provides it. However, it does not disclose ordering, pagination, or potential size/volume behavior beyond the date range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that packs the resource, scope, and data source with no filler. The most important distinction — every student and date range — is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with two well-documented parameters, the description provides sufficient scope and a hint at the return style ('as PickUp Patrol returns them'). An output schema is absent, but the description covers the essential invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents both parameters as YYYY-MM-DD strings. The description only reinforces the date-range concept and does not add extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('list'), the resource ('plans'), and the scope ('every student on the account, across a date range'). It is distinguishable from singular plan tools like pup_get_plan and from default-plan tools, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across a date range for every student on the account' gives clear context for when this bulk retrieval tool is appropriate. It does not offer exclusions or point to siblings, but the intended usage is readily inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every student on the account, each with their weekly default dismissal plan and whether those defaults still need a parent review.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation, lowering the burden on the description. The description adds useful outcome context (each student's plan and review state) but does not disclose ordering, pagination, or other runtime behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence conveys scope and content with no filler. The key idea, 'every student on the account,' is front-loaded, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description sufficiently describes the returned information: all students, their default dismissal plan, and review status. Nothing essential is missing for an agent to know when to call this tool and what it will get back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to explain about inputs. The description does add meaning by summarizing what the account-wide result set contains, which is sufficient given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('every student on the account') and what is included per student, so an agent can tell this is a list-all tool. It lacks an explicit imperative verb and does not explicitly contrast with siblings like pup_get_student, though the plural framing and account-wide scope make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the account-wide student listing and that it surfaces dismissal-plan review status, which gives helpful context. However, it does not explicitly state when to prefer this over pup_get_student, pup_list_plans, or pup_get_default_plans, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dismissal options a school offers (bus, car pickup, walker, absent …) with the rules each one imposes: whether a note is required, whether it takes a car number, whether it is an early dismissal, and the daily cutoff time. Read this before setting a plan.
| Name | Required | Description | Default |
|---|---|---|---|
| school_id | Yes | School id, from pup_list_students | |
| include_inactive | No | Include options the school has deactivated (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint: true, so the description does not need to restate safety. It adds useful domain context about the returned rules and ordering guidance, but it does not disclose additional operational behaviors such as pagination, response size, or handling of inactive options beyond what the schema parameter indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose, enumerates the returned rule categories, and includes a practical directive. Every part earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with fully documented parameters and no output schema, the description explains what the agent will learn from the tool and when to call it. It could slightly improve by noting the include_inactive behavior or response shape, but these are not critical gaps given the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented structurally. The description adds no parameter-specific detail beyond what the schema provides, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (dismissal/transportation options for a school) and the kind of operation (listing/reading available options and their rules). It is specific enough that an agent can distinguish it from sibling tools like pup_list_students or pup_list_plans 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Read this before setting a plan.' This provides actionable context for planning workflows and implies it should precede plan-modifying operations, though it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a student's default plans as reviewed, clearing the school's 'needs review' prompt. Requires confirm: true.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| reviewed | No | Defaults to true | |
| student_id | Yes | Student id, from pup_list_students |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety burden. It discloses that confirmation is required and that the operation changes state by clearing the needs-review prompt. It does not detail what the preview looks like or whether the action is reversible, but the core behavior is exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, action first, with no filler. The state-change effect and the confirmation requirement each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus fully described schema provide enough for an agent to call the tool: purpose, effect, required confirmation, and parameter source. It lacks explicit mention of the preview behavior without confirm, but that is already in the schema's confirm parameter description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds a small amount by explaining that confirm must be true and by relating the action to default plans, but it does not expand on the 'reviewed' parameter's semantics beyond the schema's 'Defaults to true'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') and a specific resource ('a student's default plans'), and names the outcome ('clearing the school's 'needs review' prompt'). This clearly separates it from siblings like pup_set_default_plans, which set plan content rather than review status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the context for use: when a student's default plans need to be flagged as reviewed and the school's needs-review prompt cleared. It also gives a prerequisite (confirm: true), but it does not explicitly mention when to prefer this over sibling tools such as pup_set_default_plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a student's weekly default dismissal plan for one or more weekdays, or clear every default. This is how the child leaves school on any date without a specific plan, so it requires confirm: true; without it you get a dry-run. Read pup_list_transportations first.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Weekdays to change, as names ("Monday") or ids (1 = Sunday … 7 = Saturday) | |
| note | No | Note for the school; required by some options | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| clear_all | No | Remove every weekday default instead of setting one (days is ignored) | |
| student_id | Yes | Student id, from pup_list_students | |
| transportation_id | No | Dismissal option id from pup_list_transportations | |
| early_dismissal_time | No | HH:MM, required when the option is an early dismissal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and largely succeeds: it discloses that this is a mutation, that clear_all removes defaults, that confirm:true is required to avoid a dry-run, and that a prerequisite read is needed. It could add permission or post-success behavior details, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the action is first, the critical confirm/dry-run behavior follows, and the prerequisite lookup is last. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema and no annotations, the description covers what the tool does, when it applies, the confirmation safety valve, and the dependency on pup_list_transportations. It is slightly light on return-value expectations, but that is less critical given the thorough schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds useful context about confirm and clear_all behavior, but it does not add much meaning beyond the schema entries themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Change a student's weekly default dismissal plan for one or more weekdays, or clear every default.' This clearly identifies what the tool does and distinguishes it from the one-off pup_set_plan tool via 'on any date without a specific plan.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default-plan context, tells the agent to read pup_list_transportations first, and states the confirm:true requirement. It does not explicitly say 'use pup_set_plan for one-off plans,' but the specificity context makes the division of labor reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change how a student is dismissed on one or more specific dates, or clear those dates back to the student's weekly default. This changes how a child actually leaves school, so it requires confirm: true; without it you get a dry-run of the exact payload. Read pup_list_transportations first — options differ in whether they require a note, a car number or an early-dismissal time.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Note for the school; required by some options | |
| dates | Yes | One or more YYYY-MM-DD dates to apply this plan to | |
| confirm | No | Must be true to proceed. Without this, the tool returns a preview. | |
| car_number | No | Car number, for options where usesCarNumbers is true | |
| student_id | Yes | Student id, from pup_list_students | |
| transportation_id | Yes | Dismissal option id from pup_list_transportations, or null to clear these dates back to the student's default plan | |
| early_dismissal_time | No | HH:MM, required when the option is an early dismissal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It clearly states that this mutates real-world dismissal and requires confirm:true, otherwise it's a dry-run. However, it doesn't explain whether setting a date overwrites an existing plan or how clearing works relative to existing overrides, which is a notable gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, then a clear usage pointer and confirm requirement. No redundancy, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, mutation, confirm semantics) and absence of output schema, the description covers the essential purpose, confirms the dry-run behavior, and points to the right resource for option-specific requirements. It doesn't describe the response format, but that's not mandatory without an output schema. The delegation to pup_list_transportations is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters, so the description adds value by explaining the relationship between transportation_id and null (clearing to default), and highlighting that note, car_number, and early_dismissal_time are conditional on the selected option. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Change' or 'clear') and resource ('how a student is dismissed on one or more specific dates'), and distinguishes from default-plan tools by explicitly mentioning weekly default. It also references reading pup_list_transportations, clarifying the relationship to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to read pup_list_transportations first and explains that options differ by required fields (note, car number, early-dismissal time). It also notes the confirm requirement for real execution vs. dry-run. It doesn't explicitly say when to use pup_set_default_plans instead, but the context implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2pup_get_default_planspup_get_planpup_get_schoolpup_get_sessionpup_get_studentpup_healthcheckpup_list_car_numberspup_list_non_school_dayspup_list_planspup_list_studentspup_list_transportationspup_mark_defaults_reviewedpup_set_default_planspup_set_planScored across 14 tools
Most tools target a distinct resource and action, with clear separation between session, students, schools, transportations, non-school days, car numbers, and plans. A couple of potential overlaps exist: pup_get_student already includes default dismissal plans and appears close to pup_get_default_plans, and pup_healthcheck overlaps slightly with pup_get_session.
The pup_ prefix is used consistently and nearly every tool follows a verb_noun pattern such as list_students, get_plan, set_default_plans. The main deviation is pup_healthcheck, which is more of a standalone command than a clear verb_noun tool name.
At 14 tools, the surface is well-scoped for the PickUp Patrol parent workflow: discovery, school configuration, plan viewing, plan editing, and default plan management. Each tool has a meaningful role and the count stays comfortably within the ideal range.
The tool set covers the full dismissal-plan lifecycle: reading constraints, listing defaults, viewing per-day plans, setting plans, clearing plans, updating defaults, and marking defaults reviewed. There are no obvious dead ends or missing operations for the apparent domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server providing attendance data queries via the CloudTime API.
The official Planning Center MCP server for interacting with your ministry's data.
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
An MCP server that automatically collects feedback on your MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/pickuppatrol-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
