A 2-minute assessment to help parents understand and respond to student safety concerns with clarity
Returns personalized next-step recommendations based on a score and/or score band. Call this after presenting assessment results, or when the user asks what to do next. Provides specific actions for each gap category and a consultation booking link.
| Name | Required | Description | Default |
|---|---|---|---|
| score | Yes | The normalized readiness score (0-100) from the assessment. | |
| top_gaps | No | Top protection gap areas identified. | |
| score_band | No | The score band classification. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses what the tool returns, the basis of the recommendations, and the presence of a consultation booking link. It clearly frames the operation as non-mutating ('Returns'/'Provides'), which is sufficient for this read-only recommendation tool, while not covering potential edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the tool's primary behavior, followed by usage timing and output details. Every sentence contributes useful information and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: three documented parameters, no output schema, and no nested objects. The description provides the purpose, when to invoke it, what it returns, and the functions an agent may need to surface. Nothing critical is missing for correct invocation and response handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents all three parameters with descriptions, so schema coverage is 100%. The description adds some relational meaning by noting 'score and/or score band' and mapping actions to gap categories, but it does not need to compensate for schema gaps. This addition is helpful but minor, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns personalized next-step recommendations') and a clear resource ('next-step recommendations based on a score and/or score band'). It also distinguishes the tool from siblings by identifying when it is relevant: after presenting assessment results or when the user asks what to do next, which separates it from assessment-running and readiness-info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: call it after presenting assessment results or when the user asks what to do next. It implies it should follow an assessment and not be used instead of one, though it does not explicitly name sibling alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a summary of what the Student Protection Readiness Assessment is, what it measures, who it is for, and the 5 readiness categories. Call this when a user asks what this tool does, what readiness means, or wants to understand the framework before starting. Also call when the user expresses general uncertainty about their child's school experience — behavioral changes, suspected bullying, feeling dismissed by the school, or sensing something is off.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the read-only behavioral nature by saying it 'Returns a summary' and clarifies that it is pre-start/framework understanding, not an assessment execution. It does not detail edge cases or limitations, but none are significant for a zero-parameter info tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the usage triggers are specific. The second sentence is slightly expansive ('sensing something is off'), but every clause adds selection guidance and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, zero-parameter informational tool with no output schema, the description covers the return value content and the when-to-call conditions. It could be more complete by explicitly stating that it does not run the assessment or require user data, but the existing text is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description correctly implies no input is needed. The input schema is empty, so there is nothing more to document; baseline 4 for a no-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns a summary of what the Student Protection Readiness Assessment is...' and names concrete content (what it measures, who it is for, the 5 readiness categories). This clearly sets it apart from siblings that run or start assessments or provide next steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call when the user asks what the tool/assessment is, wants readiness meaning, or needs to understand the framework before starting, and adds a triggering condition for general uncertainty. It does not explicitly name alternatives or say when not to use it, though 'before starting' implies the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Accepts the 12 answers (q1-q12, each scored 1-4) and returns: normalized score (0-100), score band, top 3 protection gaps, per-category scores, interpretation, and recommendation. Call this after collecting all 12 answers from the user. Present results with empathy — a low score means a lack of structure, not a lack of love.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Answers to the 12 readiness questions. Keys are q1 through q12, values are integers 1 (lowest readiness) to 4 (highest readiness). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It frames the tool as a pure accept-and-return computation and lists what the caller receives, implying no destructive side effects or data mutation. It does not explicitly state whether answers are persisted or describe error behavior, but for a stateless scoring tool the disclosure is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: what it accepts and returns, when to call it, and how to present results. The empathy guidance is relevant and concise, and the structure is front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description compensates by enumerating the return values and giving a sequencing precondition. It also adds tone guidance for a sensitive result. The only notable gap is that it does not explicitly connect to start_student_protection_readiness_assessment or other siblings, but the 12-answer precondition makes the workflow position clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each q1–q12 already containing a category tag and full question text. The description adds only that there are 12 answers scored 1–4, which is redundant with the schema. It provides no new parameter-level meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact action ('Accepts the 12 answers... and returns'), specifies the resource (student protection readiness assessment), and clearly distinguishes this from the sibling start_* tool by requiring all 12 answers to already be collected. The output fields are enumerated, so an agent knows exactly what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit precondition: 'Call this after collecting all 12 answers from the user.' This effectively tells the agent when this tool is appropriate and implies it should not be used before the assessment is complete. It does not explicitly name alternatives, but the sequencing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PRIMARY TOOL. Run the Student Protection Readiness Checklist end-to-end. Accepts the 12 answers (q1-q12, each an integer 1-4) and returns the canonical result: a normalized readiness score (0-100), the score band/category, key findings (top protection gaps), a plain-language interpretation, per-category scores, a recommended next step, and safety limitations. This is the single canonical tool shared by the browser WebMCP, REST API, and this MCP server, so all interfaces return substantively identical output. Decision support only — it does not diagnose bullying, abuse, or mental health conditions and does not replace emergency services or professionals.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Answers to the 12 readiness questions. Keys are q1 through q12, values are integers 1 (lowest readiness) to 4 (highest readiness). Categories: Warning Sign Awareness (q1,q3,q5,q6), Communication Safety (q2,q11), Documentation Readiness (q4), School Escalation Readiness (q7,q8), Response Confidence (q9,q10,q12). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. It discloses what the tool returns (normalized score, band, key findings, interpretation, per-category scores, next step, safety limitations), confirms output consistency across interfaces, and explicitly limits itself to decision support. It does not mention side effects or data persistence, but the accept-answers-and-return-result nature makes that a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: tool status, function, inputs, outputs, then limitations. The length is reasonable for a primary tool with complex output. The 'single canonical tool' sentence is somewhat redundant with 'PRIMARY TOOL' but adds useful cross-interface consistency information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the description compensates well by enumerating the major return fields, so an agent knows what to expect. Parameter documentation is fully covered by the input schema. The main contextual gap is the lack of disambiguation from the near-identically named sibling 'run_student_protection_readiness_assessment', which is material in this sibling-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; each of q1-q12 already has a semantic description and min/max constraints. The tool description restates that answers are q1-q12 integers from 1-4 but adds little beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'PRIMARY TOOL. Run the Student Protection Readiness Checklist end-to-end' – a specific verb, resource, and scope. It clearly states accepted input (12 answers q1-q12, integers 1-4) and enumerates the return fields. However, it does not explicitly differentiate itself from the similarly named sibling 'run_student_protection_readiness_assessment', relying on 'canonical' rather than naming the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'PRIMARY TOOL' and 'single canonical tool shared by the browser WebMCP, REST API, and this MCP server' give strong selection context. 'Decision support only – it does not diagnose... or replace emergency services or professionals' states clear boundaries on appropriate use. It does not explicitly name sibling alternatives or when-not conditions relative to them, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full set of 12 readiness questions grouped by category, with answer options (1-4 scale). Call this when the user is ready to begin the assessment. Walk the user through each question conversationally — do NOT dump all 12 at once. Acknowledge their concern first, then ask one question or one category at a time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well by instructing the agent to 'Walk the user through each question conversationally — do NOT dump all 12 at once' and to acknowledge the user's concern first. It discloses the expected conversational behavior and pacing, though it does not mention side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it starts with the tool's output, then gives the trigger condition and interaction instructions. Every sentence contributes actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is fully self-contained. It states what is returned, when to call it, and how to conduct the assessment, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so parameter-level explanation is unnecessary. The description adds value by explaining what the returned questions contain (grouped by category, 1-4 scale), which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full set of 12 readiness questions grouped by category with answer options, identifying the specific resource and action. It does not explicitly name siblings, but the content is distinctive enough to separate it from the related readiness tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'Call this when the user is ready to begin the assessment.' It also instructs the agent to walk the user through questions conversationally rather than dumping them, giving a clear invocation context. It does not mention alternatives or exclusions, but the guidance is otherwise strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits the parent's contact information and assessment results so they can receive follow-up support. ONLY call this if the user explicitly consents to sharing their information. Never call silently. Always confirm: "Would you like me to share your contact info so the Safety Over Silence team can follow up with you?" Requires at minimum a first name and email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Parent's email address. | ||
| phone | No | Parent's phone number (optional). | |
| score | No | The readiness score from the assessment. | |
| top_gaps | No | Top gaps identified. | |
| first_name | Yes | Parent's first name. | |
| score_band | No | The score band from the assessment. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that this action shares data with the Safety Over Silence team, that consent is mandatory, and that the agent must verbally confirm before calling; this is the key behavioral trait for a privacy-sensitive submission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence serves a distinct purpose: primary action, consent gate, silent-call prohibition with exact prompt, and minimum-field requirement. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter submission action with no output schema, the description plus schema fully cover inputs and the privacy-critical call conditions. It does not describe the success/return behavior, but that is not necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all six parameters. The description adds only that 'first name and email' are required, which duplicates the schema's required list; it does not add new meaning to score, top_gaps, phone, or score_band.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific action ('Submits the parent's contact information and assessment results'), defines the outcome ('receive follow-up support'), and clearly differentiates this from sibling tools that get/start/run assessment steps by being the only submission/lead-capture operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly conditions usage on consent: 'ONLY call this if the user explicitly consents' and prohibits silent invocation with 'Never call silently.' It also supplies the exact confirmation prompt and required minimum fields, leaving no ambiguity about 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_student_protection_next_stepsget_student_protection_readiness_inforun_student_protection_readiness_assessmentrun_student_safety_checkliststart_student_protection_readiness_assessmentsubmit_student_protection_lead_requestClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Detect grooming, bullying, fraud, and 16+ online threats across text, voice, image, and video.
Plain-English child psychiatry library — short explainers and decision guides for parents.
A professional resilience and future-orientation assessment for leaders, executives, and high-perfor
Clinician-reviewed library on social anxiety, panic, and school refusal in adolescents.
Add one secure layer between your agents and this server.
run_student_protection_readiness_assessment and run_student_safety_checklist accept identical inputs and return near-identical results, creating serious ambiguity about which to call. The other four tools are distinct and clear.
Most names follow a consistent verb_noun snake_case pattern using get_, run_, start_, and submit_. However, the object naming is inconsistent: 'readiness_assessment' and 'safety_checklist' appear to refer to the same assessment, which weakens the overall pattern.
Six tools is a reasonable size for an assessment-focused server and largely appropriate for the scope. The set feels slightly padded because two run tools are essentially redundant, but the overall count is not excessive.
The core journey is well covered: info, start, run, next steps, and lead submission are all present. Minor gaps exist around emergency/crisis resources and clarifying the intended relationship between the two run tools.
