parentsquare-mcp

by tdlm

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: list_schools, get_post, download_file, list_polls, etc. Even the many list_* tools are clearly differentiated by their resource type (feeds, conversations, photos, files, signups, notices, etc.). No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent lowercase_snake_case verb_noun pattern, using list_, get_, download_, or submit_. There is no mixing of naming conventions or vague verbs.
Tool Count4/5
23 tools is on the higher side but justified by the wide domain coverage (authentication, schools, feeds, messages, calendar, media, directory, groups, payments, forms). While it feels slightly heavy, each tool represents a distinct feature area.
Completeness3/5
The tool set is read-focused, covering most informational resources (feeds, posts, conversations, calendar, photos, files, directory, groups, dashboard, signups, notices, polls, links, payments, volunteer hours, forms). However, there are no write operations (e.g., creating posts, responding to signups, submitting forms), and some detail endpoints like individual calendar events are missing, leaving notable gaps.
Average 3.5/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'recent posts' and return fields, but does not explain pagination behavior (despite a 'page' parameter), ordering, authentication requirements, or error handling. This leaves significant behavioral gaps for a list-type 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?
The description is a single, front-loaded sentence with no filler. It efficiently states the primary purpose and the returned fields, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema), the description is incomplete. It omits pagination details, usage context relative to sibling tools, and any behavioral caveats. A simple list tool still needs to mention how the 'page' parameter works and when to use this over similar feed tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning beyond the parameter names. 'school_id' is inferable from the tool name, but 'page' is not mentioned at all. The description fails to explain the optional page parameter or its role in pagination, providing no added semantic value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent posts from a school's feed with titles, authors, dates, and summaries' clearly states the action (get), the resource (posts from a school's feed), and the fields returned. It distinguishes itself from sibling tools like 'get_post' (singular post) and 'get_group_feed' (group feed), as it focuses on the school's feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like 'get_post' and 'get_group_feed' exist, but there is no mention of when to choose this tool over them, nor any exclusions or prerequisites. The description simply states what the tool does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List') but adds no details about pagination, ordering, return format, or potential side effects. The only added context is the school scope, which is minimal.
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, six-word sentence that front-loads the verb and resource. It has no redundant information, fluff, or filler, making it exceptionally concise and easy to parse.
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?
This is a simple read tool with one parameter and no output schema, so the description doesn't need extensive detail. However, it lacks critical context such as what a 'conversation' includes, whether results are paginated, or how this differs from 'get_conversation'. For a minimal viable description, it is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool has one parameter (school_id). The description's phrase 'for a school' merely restates the parameter name without adding meaningful semantics like format, constraints, or how it affects results. It does not compensate for the schema's lack of documentation.
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 states the action ('List') and resource ('message conversations') with a scope ('for a school'), making the purpose clear. However, it does not explicitly distinguish this from sibling tools like 'get_conversation', relying on the generic list/get distinction rather than explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_conversation' or 'list_schools'. The description simply states what it does without giving context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose behavior like return format, ordering, pagination, or permission requirements. The 'list' operation implies read-only but this is not explicitly stated.
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 concise sentence that front-loads the action and resource. It contains no filler and communicates the core purpose efficiently.
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?
Given the low complexity (one parameter, no output schema), the description provides a basic understanding. However, it lacks details about what the response contains or any filtering options, which would be helpful given the list of sibling tools. It is minimally complete but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter, school_id. The description mentions 'for a school' but does not explain the parameter's format, constraints, or meaning beyond its name. The name itself is somewhat self-explanatory, but the description adds minimal value.
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 states the tool lists forms and permission slips for a school, using a specific verb and resource. It distinguishes from sibling list tools by the resource type, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other list_* siblings, nor any contextual cues. The description simply states what it does without clarifying preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('List') but does not disclose return format, pagination, filtering, permissions, or potential side effects, leaving significant behavioral ambiguity.
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, efficient sentence with no wasted words. While it is concise, it might benefit from slightly more context to help prioritize usage, but it remains appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is under-specified. It does not mention return values, any filtering or pagination behavior, or how it relates to sibling tools like get_feeds. This leaves the agent with insufficient information for reliable invocation and result interpretation.
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 has 0% parameter descriptions, but the phrase 'for a school' clarifies that the required school_id parameter refers to the school whose notices are being listed. This adds meaning beyond the bare schema type, though it does not provide any further detail about constraints or formats.
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 uses a specific verb ('List') and resource ('alerts and notices') with a clear scope ('for a school'), making it easy to understand what the tool does. However, it does not explicitly distinguish itself from sibling tools like get_feeds or list_school_features, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where this tool is preferred over sibling list tools, leaving the agent without clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides none. It does not mention read-only intent, pagination, permissions, or result ordering. The action 'List' only weakly implies a safe read operation.
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 with no filler. It is concise and efficient, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema or annotations, the description is incomplete. It omits return value structure, pagination behavior, and scope boundaries. This is minimally viable but leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate. It does not explain the 'page' parameter at all, and 'for a school' only vaguely hints at school_id. The agent gets no meaningful parameter semantics beyond what the raw schema field names suggest.
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 ('List') and resource ('sign-up and RSVP posts') with a clear scope ('for a school'). This distinguishes it from siblings like list_polls and list_notices, even though no alternative is named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or context about which situations call for listing signups specifically. The description only implies usage through its verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the ICS export mechanism but does not disclose output format, time range, pagination, error behavior, or authentication requirements.
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, well-structured sentence with no wasted words. Every word adds meaning, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description leaves significant gaps: no return format, no error cases, and no caveats about the ICS export.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that events are 'for a school', implying school_id identifies the school, but gives no format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get'), the resource ('calendar events'), and the scope ('for a school'), plus the method ('using the ICS calendar export'). This distinguishes it from sibling tools like list_schools or get_feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are there any prerequisites or context hints. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to provide safety context, so the description carries full responsibility. It does not disclose pagination behavior, return format, ordering, or permission requirements. The only behavioral trait is that it 'lists' photos, which is a read operation, but without annotations this is insufficient.
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 that is front-loaded with the action and resource. It contains no filler or redundant information and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is too sparse. It does not explain what the returned photo data looks like (e.g., URLs, metadata), whether results are paginated, or how the page parameter behaves. Without annotations or an output schema, the agent is left with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that school_id refers to the school, but the 'page' parameter is unexplained. The description adds no details about pagination, defaults, or how parameters interact beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'photos' with an explicit scope 'posted for a school.' This distinguishes it from sibling tools like list_files or get_post, which are broader or different in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or compared to list_files or get_post. The intended use is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavioral traits. It implies a read operation via 'Get' but does not specify authentication needs, error behavior for missing student, or whether the operation is safe. This is a minimal 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 sentence, front-loaded with the verb and resource. Every word earns its place with no redundancy.
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 description lists key return contents (school, grade, classes, teachers) but does not describe the response shape, types, or potential errors. Given the simplicity of the tool, it is minimally viable but leaves gaps around usage context and return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate for the student_id parameter. It does not explain the parameter format, how to obtain it, or any constraints beyond the schema's type number. The name is self-explanatory, but no added meaning is provided.
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 'Get' with a clear resource 'student dashboard information' and enumerates the included contents (school, grade, classes, teachers). This clearly distinguishes it from sibling tools like list_schools or get_staff_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when to choose this over list_schools or get_directory, or any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and resource, without mentioning return format, ordering, pagination, or any side effects. The act of listing implies read-only, but this is not articulated.
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 free of irrelevant information. It earns its place with no wasted words.
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?
Given the tool's simple nature (one parameter, no output schema), the description covers the basic purpose but lacks usage guidelines and any behavioral details. It is minimally adequate, but not incomplete to the point of failure.
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 has no property descriptions (0% coverage), so the description must add meaning. It does clarify that the context is 'for a school', which maps to the school_id parameter, but provides no additional semantics beyond the parameter name.
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 the specific verb 'list' and identifies the resource as 'quick-access links' for a school, clearly distinguishing it from sibling tools like list_schools or list_files. The scope is explicit and matches the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites, exclusions, or specific contexts. The description simply states the action without helping the agent decide between this and any other list_* sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It mentions the download action and the ParentSquare URL restriction, but it does not disclose potential side effects like overwriting files, handling invalid URLs, or authentication requirements. This lack of depth for an operation with local disk write effects warrants a low score.
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, clear sentence that is front-loaded with the verb and resource. It contains no fluff and conveys the core purpose efficiently.
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?
For a simple 2-parameter download tool, the description is adequate but not complete. It lacks information about return values (e.g., success/failure or saved path), error behavior, and optional parameters. However, given the tool's simplicity, the missing pieces are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (url and filename) with no descriptions, and the description provides zero parameter-specific details. Although the parameter names are self-explanatory, the description does not explain that filename is optional or how it behaves, leaving the agent to infer from schema structure alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Download a photo, video, or file to local disk from a ParentSquare URL.' It uses a specific verb and resource, and no sibling tool performs the same download function, making it easily distinguishable.
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 usage context (when you need to download a file from ParentSquare), but it does not explicitly compare with alternatives or state when not to use it. The sibling tools are all list/get operations, so the context is somewhat clear, but explicit guidance is missing.
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?
Without annotations, the description is the sole source of behavioral info. It conveys a read-only retrieval via 'Get' and specifies the scope ('from a specific group's feed'), but it does not disclose pagination, ordering, school_id's role, or any special behaviors. This is adequate for a simple read 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get posts from a specific group's feed.' It contains no irrelevant words and clearly states the action and target.
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 description covers the core function but omits important context: the purpose of school_id, whether posts are paginated or ordered, and any relation to sibling tools like get_feeds. With no output schema or annotations, more detail would be needed for full clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), and the description only implies that group_id identifies the group. It does not explain school_id at all, leaving half the required parameters ambiguous.
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 the specific verb 'Get' with a clear resource ('posts from a specific group's feed'), making it distinct from siblings like get_post (single post) and get_feeds (all feeds). It unambiguously states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as get_feeds or list_groups. It does not mention any exclusions, prerequisites, or preferred contexts.
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 provided, the description carries full responsibility for behavioral disclosure. It adds some context by specifying that polls are returned with questions, options, and vote counts, and 'List' implies a read-only operation. However, it does not explicitly state read-only status, authentication needs, pagination, or potential empty results, which would be more 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?
The description is a single, well-structured sentence with no redundant words. It efficiently communicates the core function and output contents without unnecessary detail.
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?
Despite having only one parameter and no output schema, the description provides basic context about what the tool does and returns. However, it lacks important operational context, such as whether results are sorted, restricted by permissions, or require any special setup. Given the absence of annotations, this feels minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema shows only a required school_id number with zero description coverage. The description's phrase 'for a school' hints that school_id identifies a school, but it does not explicitly define the parameter or its expected format. With 0% schema coverage, the description should compensate more thoroughly but only offers a minimal and somewhat implied connection.
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 'List polls for a school with questions, options, and vote counts' uses a specific verb (List) and resource (polls), includes the scope ('for a school'), and details what is returned. This clearly distinguishes it from sibling tools like list_schools or list_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any exclusions. It does not mention that polling-related functions should use this tool over other list_* tools, nor does it reference any prerequisites or alternative approaches.
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 carries the burden of behavioral disclosure. It implies a read-only operation via 'Get' and lists some returned fields, but it does not mention authentication requirements, error conditions, or any potential side effects. This adds some context but is not comprehensive.
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 action and resource, then adds specific output details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters, no annotations, and no output schema, so the description must explain usage, parameter semantics, and return structure. It only partially covers the return content (email, photo, office hours) and omits guidance on when to use it and what the parameters mean.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or relationship of user_id and school_id. The schema only provides names and types, leaving the semantics entirely to inference, so the description fails to compensate for the coverage gap.
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 ('Get') and clearly identifies the resource ('detailed info for a specific staff member'), along with specific data fields (email, photo, office hours). It distinguishes itself from sibling list/directory tools by emphasizing the singular, specific nature of the lookup.
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: use this tool when you need detailed information about a single staff member. However, it does not explicitly name alternatives or exclusion criteria (e.g., 'for listing all staff, use get_directory instead'), so it stops short of the highest rating.
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 provided, the description carries the burden. It states that the operation is a read ('Read') and that the response includes 'all messages,' which provides basic behavioral transparency. However, it does not disclose auth requirements, error handling, or response details beyond message inclusion.
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, concise sentence that gets directly to the point. No unnecessary words or repetition. It front-loads the action and resource.
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 relatively simple (two required parameters, no output schema), and the description covers the essential functionality. However, without an output schema, it would be helpful to describe the response format (e.g., ordering, fields of the messages) or error conditions. The description is minimally sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specific message conversation thread' but does not explain the roles of chat_id and school_id or their relationship. The parameter names are self-explanatory, but the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Read a specific message conversation thread with all messages.' This distinguishes it from sibling tools like list_conversations (which lists, not gets a single thread) and get_post (which gets a post, not a conversation).
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 word 'specific' implies this tool is for retrieving one conversation rather than listing all, but the description does not explicitly state when to use this over alternatives or provide exclusions. Usage is implied but not directly guided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read operation ('List') and specifies the returned content, but it does not disclose any additional behavior such as whether results are limited to active staff, ordering, or pagination. This is adequate but lacks depth.
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 13 words, immediately stating the action and expected content. There is no redundancy or filler; every word contributes to understanding the tool's function.
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 tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers what the tool returns (contact info, staff directory, names, roles, phones). It does not explain the return format or list structure, but for a straightforward directory listing, this level is sufficient. Missing a note about pagination or filtering is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter (school_id). The description does not mention the parameter at all, forcing the agent to infer from the name and tool context. While school_id is reasonably self-explanatory, the description fails to explicitly connect it to the tool's purpose, so it only partially compensates for the schema gap.
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 ('List') and clearly identifies the resource ('school contact info and staff directory') and the content ('names, roles, and phone numbers'). It distinguishes itself from sibling tools like get_staff_member (single staff member) and list_schools (school names only).
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 the tool is used to retrieve directory information for a school, but it does not explicitly state when to use it over alternatives or mention any prerequisites. There is no comparison with get_staff_member or list_schools, so guidance is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and scope, but does not explain whether pagination is used, what permissions are required, what fields are returned, or how this differs from related file tools.
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 concise sentence that states the action and object clearly. There is no redundant information or filler, making it well-structured and easy to parse.
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?
For a simple list operation with one parameter and no output schema, the description provides a minimal level of completeness. However, it lacks details about return values, pagination, or any behavioral nuances, which would be helpful given the absence of annotations and 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 has a single required parameter, school_id, with no description in the schema (0% coverage). The tool description mentions 'for a school,' which weakly ties to the parameter, but the description does not explicitly explain that school_id refers to the school whose files should be listed. The parameter name is fairly self-explanatory, keeping this at an acceptable level.
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 ('List') with a clear resource ('files and documents') and scope ('posted for a school'). This distinguishes it from sibling tools such as download_file or list_photos, making the purpose immediately clear.
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 clearly implies when to use this tool: to retrieve files and documents associated with a school. However, it does not explicitly mention when not to use it or any alternatives, such as download_file for retrieving a specific file.
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 carries the full burden of behavioral disclosure. It implies a read-only operation via 'List' and mentions output contents ('summary stats and item prices'), but it does not explicitly state side effects, permissions, or return format. The description adds some value beyond the schema by hinting at the response, but leaves gaps around pagination and detailed behavior.
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 concise sentence of 11 words. It front-loads the primary action ('List payment items') and follows with scope and output highlights. Every word contributes meaning, with no redundancy or filler.
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?
Given the simple one-parameter schema and no output schema, the description provides the core purpose but lacks detail on return shape, pagination, or what 'summary stats' specifically includes. It is adequate for a basic understanding but leaves gaps for an agent to know exactly what to expect.
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 defines school_id only as a number with no description. The description's phrase 'for a school' clarifies that this parameter identifies the school, which is useful. However, the description does not elaborate on how school_id is used or any constraints, so it partially compensates for the 0% schema explanation but does not fully define the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), resource ('payment items'), and scope ('for a school'). It also mentions 'summary stats and item prices', providing specific output characteristics that distinguish it from sibling list tools such as list_schools or list_notices. The verb+resource+scope pattern is explicit and unambiguous.
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 indicates the tool is for listing payments for a school, which gives context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Since no sibling tool handles payments, the intended usage is implied but not clearly 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?
With no annotations, the description carries the full burden. It discloses that the tool returns member counts and descriptions, which is useful. However, it does not mention pagination, ordering, access scoping, or potential errors. The read-only nature is implied by 'List,' but no deeper behavioral details are provided.
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: 'List groups at a school with member counts and descriptions.' Every word earns its place, and it immediately conveys the primary action and scope. No filler or redundancy.
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, one-parameter list tool with no output schema, the description provides a good overview: it lists groups, scopes by school, and indicates the return fields (member counts, descriptions). It lacks details like pagination or error handling, but these are not critical for a basic list operation. The low complexity and clear parameter make the description fairly complete.
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 schema has 0% description coverage, so the description must compensate. The phrase 'at a school' clarifies that school_id identifies the school whose groups are listed, adding meaning beyond the bare schema type. For a single self-explanatory parameter with clear contextual mapping, this is adequate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('groups'), and the scope ('at a school'). This distinguishes it from siblings like list_schools (different resource) and get_group_feed (retrieves a feed, not a list). The inclusion of 'with member counts and descriptions' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention when not to use it, what to use for group feeds, or any prerequisites. The only implied context is that a school_id is needed, but there is no explicit usage direction.
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 provided, the description carries the full burden of behavioral disclosure. It adds a useful context detail ('parsing its sidebar navigation') that implies a read-only operation and reveals the underlying mechanism. However, it does not explicitly state that the tool is non-destructive, whether authentication is required, or how errors are handled.
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 that leads with the action, specifies the target resource, and explains the method. There is no wasted wording 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 tool with one parameter and no output schema, the description provides sufficient context: it explains what the tool does and how it works. It could further clarify what 'features' means or what the return format looks like, but these are not critical for a basic listing operation.
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 provides 100% coverage for the single required parameter, including a helpful description for school_id that directs users to list_schools. The description itself adds no additional parameter semantics beyond what the schema already contains, so a baseline score 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 states the tool's function: 'List features available for a specific school by parsing its sidebar navigation.' It specifies the verb (List), the resource (features for a school), and the method (parsing sidebar navigation), which distinguishes it from sibling tools like list_schools or get_feeds.
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 implied by the description: it is for listing features for a specific school. However, there is no explicit guidance on when to choose this tool over alternatives, nor any stated exclusions. The schema description does reference list_schools for finding IDs, but the tool description itself lacks direct usage guidance.
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?
No annotations are provided, so the description carries the full burden. The word 'List' implies a read-only operation, and 'your' indicates it returns the caller's own hours. However, it does not disclose other behavioral traits like pagination, ordering, or error behavior. This is acceptable for a simple list tool but not fully detailed.
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 without extra words. Every part contributes: 'List' is the action, 'your logged volunteer hours' is the resource, and 'for a school' adds the scope. This is appropriately concise.
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 low complexity (one parameter, no output schema, no annotations), the description covers the essential aspects: what the tool does and the scope. It could be improved by stating the return format or any prerequisites, but for this simple read-only list operation, it is largely sufficient.
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 has one required parameter (school_id) with no description, and schema coverage is 0%. The description helps by tying 'for a school' to the school_id, giving it meaning. However, it does not explain how to obtain valid school_id values or any format details, leaving partial compensation for the missing schema 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 uses the specific verb 'List' with the resource 'logged volunteer hours' and scope 'for a school.' This clearly distinguishes it from the many sibling list tools (e.g., list_photos, list_files) that serve different data types.
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 usage by stating 'for a school,' which signals the need for a school_id parameter. However, it does not explicitly state when to choose this tool over alternatives or any exclusions. The context is clear enough but lacks direct guidance.
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 carries the burden of explaining behavior. It states that submitting the code completes login and directs the user to check email, covering the basic flow. However, it does not disclose potential issues like code expiration, one-time use, or failure modes, which are relevant for an authentication action.
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, front-loaded with the action and purpose, followed by a clear usage trigger. Every word earns its place with no redundancy or filler.
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 tool is simple, with one parameter fully documented in the schema, and the description provides the trigger condition for use. It is complete for the tool's narrow purpose, though it could mention what happens after successful submission (e.g., session established) or error handling, but this is not critical for a simple code submission action.
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 coverage is 100%, with the 'code' property described as 'The 6-digit verification code from your email'. The tool description reiterates the same information ('6-digit MFA verification code', 'check your email'), adding no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Submit a 6-digit MFA verification code' and its purpose 'to complete ParentSquare login'. This verb+resource+goal structure distinguishes it from sibling tools, which are all data retrieval operations.
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 gives explicit context: 'When a ParentSquare tool returns an MFA error, check your email for the code.' This tells the agent when to use the tool, though it doesn't explicitly discuss exclusions or alternatives, which are unnecessary given the unique authentication purpose.
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?
No annotations are provided, so the description carries the burden. It discloses the return format ('Returns JSON with schools, students, and your user ID') and implies read-only behavior via 'List', adding useful context beyond the tool name. It doesn't cover auth requirements or pagination, but for a simple read-only list this is a solid 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, focused sentence that front-loads the main purpose and adds a brief note on the return format. Every word is informative, with no filler.
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 simplicity (zero params, no output schema), the description covers the core functionality and return contents. It doesn't mention behavior when no schools or students exist, but the tool is simple enough that the description is nearly complete.
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, so the baseline is 4. The description doesn't need to explain parameters, and the input schema is empty, leaving no ambiguity.
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 'List available schools and students in your ParentSquare account' with a specific verb and resource, and it distinguishes from sibling tools like list_school_features and list_conversations by explicitly mentioning schools and 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 description implies usage when you need schools/students in the account, but it provides no exclusions or alternatives. It gives clear context but doesn't explicitly say when to use this vs. other list tools, so it meets only 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?
No annotations exist, so the description carries the burden. It discloses meaningful behavior: image attachments are returned inline, and PDF text extraction is conditional on the pdf-parse package. This gives the agent expectation of attachment handling, though it doesn't cover error cases or response shape.
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 purpose, no wasted words. Efficiently conveys scope and attachment behavior.
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 single-parameter read tool with no output schema, the description sufficiently covers what the agent gets (body, comments, attachments) and special handling of images and PDFs. It is complete for the tool's complexity.
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 coverage is 100% since feed_id is described as 'Post/feed ID from get_feeds results'. The description adds no extra parameter semantics beyond the schema. Baseline 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?
Uses specific verb 'Get' and clearly defines the resource as 'full details of a specific post', listing body, comments, and attachments. This implicitly distinguishes it from list-style siblings like get_feeds or get_group_feed.
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: use when you need full details of one post. It doesn't explicitly name alternatives or state when not to use, but the 'specific post' phrasing implies single-record retrieval. Slight gap in explicit exclusion.
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

Copy to your README.md:

[![parentsquare-mcp MCP server](https://glama.ai/mcp/servers/tdlm/parentsquare-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tdlm/parentsquare-mcp)

Score Badge

Copy to your README.md:

[![parentsquare-mcp MCP server](https://glama.ai/mcp/servers/tdlm/parentsquare-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tdlm/parentsquare-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/tdlm/parentsquare-mcp'

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