pickuppatrol-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on September 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

pickuppatrol-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![pickuppatrol-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/chrischall/pickuppatrol-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/pickuppatrol-mcp)

Score Badge

Copy to your README.md:

[![pickuppatrol-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/chrischall/pickuppatrol-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/pickuppatrol-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/chrischall/pickuppatrol-mcp'

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