Which integrations are available for this server?

Sends notifications to the parent's phone via iMessage (macOS only). Sends parental alerts and allows approve/deny actions on held messages via Telegram bot commands. Enables WhatsApp notifications through Twilio's API. Sends notifications to the parent's WhatsApp number via Twilio.

How do I use parental-control?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@parental-control review my child's message for harmful content" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

parental-control

by Gonzih

Overview Schema Related Servers Score Discussions

TypeScript

Local

parental-control

An open-source MCP (Model Context Protocol) server that gives parents real-time oversight and guardrails over their children's AI agent interactions — without taking away the benefits of AI for learning and creativity.

The Problem

AI assistants are increasingly used by children and teenagers. Unlike parental controls for websites or games, there are no native guardrails for AI conversations. A child could:

Explore self-harm or suicidal ideation with an AI that responds helpfully
Get pulled into echo chambers where the AI reinforces extreme views
Encounter explicit or age-inappropriate content through creative writing prompts
Develop an unhealthy emotional dependency on an AI companion

Parents have no visibility into these interactions — until now.

Related MCP server: gov-mcp

Architecture

Child's Claude session
        │
        ▼
┌──────────────────────────────────────┐
│  parental-control  (MCP Server)      │
│  ────────────────────────────────    │
│  policy.ts         ← YAML policy, hot-reload via chokidar
│  classifier.ts     ← Regex-first, LLM second-pass
│  privacy-router.ts ← PII detection, local/cloud routing
│  audit.ts          ← JSON Lines audit log
│  session-tracker.ts← Daily limits, curfew enforcement
│  memory.ts         ← SQLite conversation history
│  approval.ts       ← Hold-for-approval flow
│  notifier.ts       ← Telegram / iMessage / WhatsApp / Email
│  profiles.ts       ← Age-based restriction profiles
└──────────────────────────────────────┘
        │
        ▼
  Parent's phone                  Local Ollama (optional)
(Telegram / iMessage / ...)     http://localhost:11434

The server runs alongside Claude Desktop (or any MCP-compatible agent) and intercepts every message using the check_message tool. When something is flagged, the parent gets an alert — and for critical content, the message is held until the parent responds.

Quick Start

1. Install

npx @gonzih/parental-control

2. Configure Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "parental-control": {
      "command": "npx",
      "args": ["-y", "@gonzih/parental-control"],
      "env": {
        "PARENTAL_CONTROL_CHILD_NAME": "Alex",
        "PARENTAL_CONTROL_CHILD_AGE": "14",
        "NOTIFICATION_CHANNEL": "telegram",
        "TELEGRAM_BOT_TOKEN": "your-bot-token-here",
        "TELEGRAM_PARENT_CHAT_ID": "your-chat-id-here"
      }
    }
  }
}

3. Get a Telegram Bot

Message @BotFather on Telegram
Run /newbot and follow the prompts
Copy the bot token into TELEGRAM_BOT_TOKEN
Start a chat with your bot, then visit https://api.telegram.org/bot<TOKEN>/getUpdates to find your chat ID

4. Instruct Claude

Add a system prompt to Claude (or your child's agent) that instructs it to use the MCP tools:

You have access to a parental-control MCP server. Before responding to any message:
1. Call check_message with the user's message (role: "user")
2. If the decision is "block", do not respond to that topic
3. If the decision is "hold_for_approval", wait for the approval result
4. Before sending your response, call check_message with your response (role: "assistant")
5. Proceed based on the decision

Configuration

Notification Channels

Telegram (recommended)

NOTIFICATION_CHANNEL=telegram
TELEGRAM_BOT_TOKEN=1234567890:ABCdef...
TELEGRAM_PARENT_CHAT_ID=987654321

iMessage (macOS only)

NOTIFICATION_CHANNEL=imessage
IMESSAGE_PARENT_PHONE=+15555555555

Requires macOS with Messages app configured.

WhatsApp (via Twilio)

NOTIFICATION_CHANNEL=whatsapp
TWILIO_ACCOUNT_SID=ACxxxxxxxx
TWILIO_AUTH_TOKEN=your-auth-token
TWILIO_WHATSAPP_FROM=whatsapp:+14155238886
TWILIO_WHATSAPP_TO=whatsapp:+15555555555

Email (SMTP)

NOTIFICATION_CHANNEL=email
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USER=you@gmail.com
SMTP_PASS=your-app-password
SMTP_PARENT_EMAIL=you@gmail.com

Policy File (recommended)

The easiest way to configure the server is with a YAML policy file at ~/.parental-control/policy.yaml. Copy the example to get started:

cp policy.yaml.example ~/.parental-control/policy.yaml

The server watches this file and hot-reloads it without a restart. You can also force a reload:

npx @gonzih/parental-control --reload-policy

See policy.yaml.example for all options.

All Environment Variables

Variable	Default	Description
`PARENTAL_CONTROL_CHILD_NAME`	`Child`	Child's display name in alerts
`PARENTAL_CONTROL_CHILD_AGE`	`14`	Child's age (sets default restrictions)
`PARENTAL_CONTROL_PROFILE_ID`	`default`	Profile identifier
`NOTIFICATION_CHANNEL`	`telegram`	One of: `telegram`, `imessage`, `whatsapp`, `email`
`TELEGRAM_BOT_TOKEN`	—	Telegram bot token from BotFather
`TELEGRAM_PARENT_CHAT_ID`	—	Parent's Telegram chat ID
`IMESSAGE_PARENT_PHONE`	—	Phone number for iMessage alerts
`TWILIO_ACCOUNT_SID`	—	Twilio account SID
`TWILIO_AUTH_TOKEN`	—	Twilio auth token
`TWILIO_WHATSAPP_FROM`	`whatsapp:+14155238886`	Twilio sandbox number
`TWILIO_WHATSAPP_TO`	—	Parent's WhatsApp number
`SMTP_HOST`	—	SMTP server host
`SMTP_PORT`	`587`	SMTP server port
`SMTP_USER`	—	SMTP username
`SMTP_PASS`	—	SMTP password
`SMTP_PARENT_EMAIL`	—	Parent's email address
`PARENTAL_CONTROL_DB`	`~/.parental-control/db.sqlite`	Database file path
`APPROVAL_TIMEOUT_MINUTES`	`30`	Auto-deny timeout for held messages
`SPIRAL_WINDOW_MESSAGES`	`20`	Message history window for spiral detection
`ANTHROPIC_API_KEY`	—	API key for LLM second-pass classification (cloud)
`LOCAL_MODEL`	`llama3.2`	Ollama model name for local LLM classification

MCP Tools

`check_message`

The primary tool. Call this before processing any message.

Input:

{
  "content": "the message text",
  "role": "user",
  "profileId": "optional-profile-id"
}

Output:

{
  "decision": "allow",
  "category": "safe",
  "confidence": 1.0,
  "reason": "No concerning content detected"
}

When held for approval:

{
  "decision": "hold_for_approval",
  "category": "self_harm",
  "confidence": 0.95,
  "reason": "Self-harm content detected: \"hurt myself\"",
  "held": true,
  "approved": false,
  "safeDeflection": "I'd like to pause on this topic..."
}

`log_interaction`

Log messages to conversation history without classification (for audit trails).

`resolve_approval`

Approve or deny a held message programmatically (parents can also use Telegram bot commands).

`list_pending`

Get all messages currently waiting for parent approval.

`update_profile`

Modify child profile settings at runtime.

`get_risk_summary`

Get the current spiral risk score and conversation flags.

Decision Types

Decision	What Happens
`allow`	Message passes through normally
`notify`	Message passes, parent receives background alert
`block`	Message is stopped; AI should not engage with the topic
`hold_for_approval`	Message is held; AI waits for parent's approve/deny

Content Categories

Safety-Critical (always held or blocked)

suicide — Suicidal ideation, crisis content
self_harm — Self-injury content
explicit_sexual — Pornography, explicit sexual content
extremist_content — Radicalization, hate groups, terrorism

Age-Gated (vary by profile)

violence — Instructions for harm, weapons
substance_abuse — Drug use, drug acquisition
age_restricted — Alcohol, gambling sites, fake IDs
gambling — Casino, betting, lottery content

Behavioral Patterns (notify by default)

spiral_detected — Repeated hopelessness, worthlessness, isolation themes
echo_chamber — AI reinforcing extreme or one-sided beliefs
sycophantic_amplification — AI escalating negative emotions
emotional_manipulation — Urgency, fear, dependency patterns
identity_crisis — Intense identity struggle signals
minor_inappropriate — Mildly age-inappropriate content

Age-Based Default Profiles

The server automatically applies age-appropriate defaults:

Under 13

Blocked: explicit sexual, violence, extremist content, substance abuse, gambling
Held: self-harm, suicide, age-restricted
Notify: spiral detected, echo chamber, emotional manipulation, identity crisis

Ages 13–15

Blocked: explicit sexual, extremist content, gambling
Held: self-harm, suicide, violence, substance abuse
Notify: spiral detected, echo chamber, age-restricted, emotional manipulation

Ages 16–17

Blocked: explicit sexual, extremist content
Held: self-harm, suicide
Notify: spiral detected, echo chamber, violence, substance abuse, gambling

Spiral Detection

Spiral detection is a stateful feature that analyzes conversation history for sustained negative thought patterns — not just individual flagged messages.

How it works:

Every message is stored in SQLite with a timestamp
When check_message is called, the server looks back at the last N messages (default: 20)
Pattern matching scores each message for hopelessness, worthlessness, isolation themes
If the cumulative score exceeds the threshold, a spiral_detected alert is sent

Patterns detected:

"nobody loves/likes me"
"I'm worthless/hopeless/a failure"
"nothing will ever change"
"I give up"
"life is pointless"
And more (see src/keywords.ts)

Approval Flow

When a message is held for approval:

Parent receives notification via their configured channel
For Telegram: notification includes /approve <id> and /deny <id> commands
Server polls Telegram for responses (30-second long-polling)
If no response within timeout (default: 30 min), message is auto-denied
Child's AI receives the decision and either:
- Proceeds normally (approved)
- Responds with a safe deflection message (denied)

Parent Guidance

Every alert includes actionable guidance tailored to the category. Examples:

For spiral detection:

Find a calm, private moment. Start with: "I've noticed you seem a bit heavy lately — I'm here if you want to talk." Don't ask yes/no questions. Listen first, problem-solve second.

For self-harm:

Call or text 988 (Suicide & Crisis Lifeline) for guidance on how to help. Remove obvious means of self-harm from the home temporarily. Stay connected — check in frequently.

For explicit content:

Stay calm — panic may shut down communication. This is an opportunity, not a crisis. Frame it around safety and healthy relationships, not punishment.

Out-of-Process Enforcement

Classification runs entirely outside the child model's context. Even if the child's AI session is jailbroken or manipulated, it cannot influence the safety decision:

First pass — regex + keyword matching (fast, zero cost, prompt-injection-proof)
- Confidence > 0.8 → use result directly, no LLM needed
- Confidence 0.4–0.8 → escalate to second pass
- Confidence < 0.4 → allow but log
Second pass — LLM classifier (only for edge cases)
- Routed to local Ollama or Anthropic API based on inference_router setting
- A separate model from the child's conversation model

Privacy Router

Control where LLM inference happens via inference_router in policy.yaml:

Value	Behavior
`local`	All inference → Ollama at `http://localhost:11434`
`cloud`	All inference → Anthropic API
`auto`	PII/sensitive content → local, general → cloud

PII detection (regex-based, never LLM-based) catches:

Social Security numbers (XXX-XX-XXXX)
Credit card numbers
Phone numbers
Email addresses
Street addresses

Audit Log

Every classification decision is written to ~/.parental-control/audit.log in JSON Lines format:

{"ts":"2026-03-21T10:00:00Z","category":"violence","action":"block","content_snippet":"first 100 chars...","tool":"check_message","session_id":"abc123"}

Generate a daily summary:

npx @gonzih/parental-control --audit-report
# or for a specific date:
npx @gonzih/parental-control --audit-report 2026-03-20

Output:

=== Audit Report for 2026-03-21 ===

Total events: 47

Actions:
  allow: 40
  notify: 4
  block: 2
  hold_for_approval: 1

Categories:
  safe: 40
  spiral_detected: 4
  violence: 2
  self_harm: 1

Session Time Limits

Track daily usage in ~/.parental-control/usage.json. When the daily limit is reached, all tool calls are blocked and the parent receives a notification:

"Daily limit reached: Alex has used 120 minutes today."

Curfew hours are also enforced — no AI access between curfew_start and curfew_end (supports overnight curfews like 21:00–08:00).

Privacy & Data

All conversation history is stored locally in SQLite (~/.parental-control/db.sqlite)
Audit log at ~/.parental-control/audit.log (JSON Lines, parent-readable)
Usage tracking at ~/.parental-control/usage.json
No data is sent to any third-party service except your chosen notification channel
The database path is configurable via PARENTAL_CONTROL_DB
With inference_router: local, all AI classification stays on-device via Ollama

Development

git clone https://github.com/gonzih/parental-control
cd parental-control
npm install
npm run build
npm start

Project Structure

src/
  index.ts            — MCP server entry point, CLI flags, tool handlers
  policy.ts           — YAML policy loader with chokidar file watcher
  classifier.ts       — Two-pass: regex-first, LLM second-pass with confidence tiers
  privacy-router.ts   — PII detection (regex), local/cloud inference routing
  audit.ts            — JSON Lines audit log, daily report generator
  session-tracker.ts  — Daily usage tracking, curfew enforcement
  keywords.ts         — Keyword lists and regex patterns
  guidance.ts         — Parent guidance templates
  profiles.ts         — Age-based restriction profiles
  memory.ts           — SQLite persistence layer
  notifier.ts         — Notification dispatch (Telegram/iMessage/WhatsApp/email)
  approval.ts         — Hold-for-approval state machine
policy.yaml.example   — Annotated policy file template

Adding New Categories

Add keywords to src/keywords.ts
Add the category to the Category union in src/classifier.ts
Add classification logic in classifyWithRegex()
Add a categoryToDecision() mapping entry
Add a guidance template in src/guidance.ts
Update default profiles in src/profiles.ts
Add the category key to policy.yaml.example

Contributing

Contributions welcome. Please open an issue before submitting a large PR.

Areas that need work:

LLM-based classification (beyond keyword matching)
Multi-child profile management UI
Dashboard for conversation history review
iOS/Android companion app for parent notifications
Time-of-day and screen-time limits

License

MIT — see LICENSE file.

Crisis Resources

If you discover your child is in crisis:

988 Suicide & Crisis Lifeline: Call or text 988 (US)
Crisis Text Line: Text HOME to 741741
International Association for Suicide Prevention: https://www.iasp.info/resources/Crisis_Centres/

Available Tools

6 tools

check_messageA

Classify a message for safety before it reaches or comes from the child. Returns classification result with decision (allow/notify/block/hold_for_approval).

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Who sent the message
`content`	Yes	The message content to classify
`profileId`	No	Child profile ID (uses default if omitted)

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description bears the burden of behavioral disclosure. It discloses that it returns a classification decision with specific values, but it does not clarify whether the tool enforces the decision or merely recommends it, nor does it mention side effects like persistence or triggering approval workflows. This leaves ambiguity about what happens after classification.

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 tight sentences, front-loaded with the primary action and output. Every word is purposeful, with no redundant explanation 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 description is concise and explains the main behavior and return decision values. Given the tool's role in a safety pipeline and the absence of an output schema, it could be more explicit about whether the decision is a recommendation or an enforced action, and how it ties into approval workflows. However, the core semantics are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all parameter meanings with 100% coverage, including role, content, and profileId defaults. The description does not add parameter-level detail beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Classify' and resource 'a message for safety', and specifies the return decision categories (allow/notify/block/hold_for_approval), which clearly distinguishes it from sibling tools that handle logging, approvals, and profile updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before it reaches or comes from the child' provides clear context for when to invoke the tool. It does not explicitly name alternatives or exclusion criteria, but the context implies it is the classification gate for message safety, which is sufficient for basic usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_risk_summaryC

Get a conversation risk summary and spiral detection score for a child profile.

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No	Look back N hours (default: 24)
`profileId`	No	Child profile ID

TDQS

C2.9/5.0

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 disclosing behavior. It only says 'Get', which implies a read-only operation, but does not clarify side effects, permissions, response format, or any potential failures. No behavioral traits beyond the basic action are disclosed.

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, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though it lacks structured information about the output or usage details.

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 no output schema, so the description should explain what the return value contains. It mentions 'risk summary and spiral detection score' but does not elaborate on the structure, range, or meaning. Usage guidance and parameter context are also missing, leaving the description incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full coverage for both parameters (hours and profileId), so the baseline is 3. The description does not add any additional meaning beyond what the schema specifies, such as units, defaults, or how 'hours' and 'profileId' affect the result.

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 the specific verb 'Get' and clearly identifies the resource as 'conversation risk summary and spiral detection score' for a child profile. This distinguishes it from sibling tools like check_message or log_interaction, though it does not explicitly contrast with them.

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 such as check_message or list_pending. The phrase 'for a child profile' provides minimal context but does not state any conditions, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_pendingA

List all messages currently held for parent approval.

ParametersJSON Schema

Name	Required	Description	Default
`profileId`	No	Filter by child profile ID (optional)

TDQS

A3.8/5.0

Behavior3/5

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

The verb 'list' suggests a read-only operation, but because no annotations are provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that no modifications occur, nor does it mention pagination, sorting, or output format. The transparency is adequate 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 concise sentence that immediately states the action and resource. It is front-loaded, with no filler, repetition, or unnecessary details.

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 tool with one optional parameter and no output schema, the description adequately covers the core purpose. However, it leaves minor gaps such as what the returned list contains and the exact criteria for 'pending'. These are not critical for basic usage, so a score of 4 is justified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has a single optional parameter (profileId) with a clear description, giving 100% schema coverage. The description does not add any parameter-specific details, which is acceptable given the schema's completeness. The 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 uses the specific verb 'List' and clearly identifies the resource ('messages currently held for parent approval'). This distinguishes it from sibling tools like check_message and resolve_approval, which operate on individual messages or perform approvals.

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 for retrieving messages that are pending approval, but it does not explicitly instruct when to use this tool versus alternatives such as resolve_approval or check_message. There are no exclusions or alternative pointers, so the usage context is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

log_interactionA

Log an interaction to the conversation history for pattern analysis.

ParametersJSON Schema

Name	Required	Description
`role`	Yes	Message role (user/assistant)
`content`	Yes	Message content
`profileId`	No	Child profile ID

TDQS

A3.7/5.0

Behavior3/5

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

The description states the tool logs data, which implies a write operation, and adds context ('for pattern analysis') but does not disclose side effects, persistence behavior, or whether it appends to existing history. With no annotations provided, the description carries the full burden but provides only minimal behavioral insight.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that is concise and contains no wasted words. It efficiently states the action and purpose.

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 tool with three parameters, no annotations, and no output schema, the description gives the core action and rationale but does not explain return values, side effects, or any prerequisites. Given the overall simplicity, it is minimally adequate but leaves several contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add additional meaning beyond what is in the schema; it only mentions 'interaction' and 'conversation history' which loosely map to the parameters but add no new details.

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 logs an interaction to conversation history for pattern analysis, using a specific verb ('log') and resource ('interaction to conversation history'). It is distinct from sibling tools which focus on checking messages, resolving approvals, listing pending items, updating profiles, or getting risk summaries.

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 purpose implies usage when an interaction needs to be recorded for later analysis, but there is no explicit guidance on when to use this tool vs. alternatives, nor any exclusions or prerequisites. It is only minimally implied by the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_approvalB

Approve or deny a held message. Called by parent (or via bot command).

ParametersJSON Schema

Name	Required	Description
`decision`	Yes	Parent decision
`approvalId`	Yes	The approval ID to resolve
`parentNote`	No	Optional note from parent

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations available, the description must fully disclose behavior. It identifies the action as approving or denying a held message, but omits critical details such as required permissions, side effects, reversibility, error behavior, or what happens after resolution. This is insufficient for a state-changing 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 extremely concise with two short sentences, each adding value: the first states the tool's purpose and the second gives invocation context. No wasted words or 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?

The tool has no output schema and no annotations, so the description must cover outcomes and prerequisites. It does not mention what happens on success or failure, nor any return values or post-resolution effects. The minimal text is not enough for a mutation tool in a workflow context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full descriptions for all three parameters, including the enum for decision, so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

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 action (approve/deny) on a specific resource (a held message). It distinguishes the tool from siblings like list_pending by indicating this resolves an approval rather than listing them.

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 mentions it is called by a parent or via bot command, implying usage in an approval workflow, but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tool references are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_profileA

Update child profile settings (age, restrictions, notification channel).

ParametersJSON Schema

Name	Required	Description	Default
`settings`	Yes	Partial profile settings to update
`profileId`	Yes	Profile ID to update

TDQS

A3.7/5.0

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. It states 'Update child profile settings' but does not disclose behavioral traits such as whether the update is a merge or overwrite, any permission requirements, side effects, or what the response looks like. This is a mutation tool with minimal transparency.

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 redundant words. It efficiently conveys the purpose and key scope without waste.

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 is adequate for a simple update tool, but it lacks information about return values, preconditions (e.g., profile existence), and behavior when partial settings are provided. Given the lack of annotations and output schema, additional context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both profileId and settings have descriptions), but those descriptions are generic. The tool description adds meaning by listing example fields ('age, restrictions, notification channel'), which helps the agent understand what to place in the nested `settings` object.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's action: 'Update child profile settings' with specific fields (age, restrictions, notification channel). This distinguishes it from sibling tools like check_message, log_interaction, resolve_approval, list_pending, and get_risk_summary, which serve different purposes.

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 that this tool is for updating child profile settings, but it does not explicitly state when to use it over alternatives or provide exclusions. The context is clear, but no specific usage guidance is given beyond the basic action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.2.0Aug 2, 2026
- First observedcheck_message
- First observedget_risk_summary
- First observedlist_pending
- First observedlog_interaction
- First observedresolve_approval
- First observedupdate_profile

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool addresses a distinct concern: message safety classification, interaction logging, approval resolution, pending list retrieval, profile updates, and risk summaries. There is no functional overlap or ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_message, log_interaction, resolve_approval). Naming is uniform and predictable.

Tool Count5/5

Six tools cover the core parental control workflows (monitoring, approvals, risk, profile configuration) without bloat or missing essential functions.

Completeness4/5

The set covers the main lifecycle: message checking, interaction logging, approval actions, pending queue, profile updates, and risk reports. A minor gap is the lack of a direct tool to fetch a full message or interaction history beyond the risk summary, but this is a workable limitation.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
agentguard A
io.tooloracle
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Security Monitoring
2
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
StackResolve C
dev.stackresolve
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Developer Tools
151

Related MCP Servers

Waymarkofficial
File Systems Shell Access Developer Tools
waymarks
F
license
Not graded
quality
A
maintenance
MCP server that intercepts and controls AI agent actions in your codebase by enforcing policies on file operations and commands, with logging, approval workflows, and rollback capabilities.
Updated 5 hours ago (2026-09-06 02:34 UTC)
-
gov-mcp
Security Autonomous Agents
liuhaotian2024-prog
A
license
Not graded
quality
C
maintenance
An MCP server that enforces runtime governance on AI agent actions — file access, command execution, delegation chains, and permission escalation.
Updated 4 months ago (2026-05-08 00:25 UTC)
MIT
continuityos
Knowledge & Memory Shell Access
bitmaster162
A
license
C
quality
B
maintenance
An MCP server offering hybrid memory recall and continuity tools for AI agents. It also provides a governance gateway that pre-approves risky shell/file/git actions before execution.
Updated 2 days ago (2026-09-04 05:26 UTC)
19
Apache 2.0
AISentinel
Security Observability
Kabzhanov
A
license
Not graded
quality
A
maintenance
An open-source MCP server that protects AI agents at runtime by evaluating every tool call against YAML policies and generating audit trails.
Updated 2 months ago (2026-07-10 07:29 UTC)
1
Apache 2.0

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/Gonzih/parental-control'

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

parental-control

The Problem

Architecture

Quick Start

1. Install

2. Configure Claude Desktop

3. Get a Telegram Bot

4. Instruct Claude

Configuration

Notification Channels

Telegram (recommended)

iMessage (macOS only)

WhatsApp (via Twilio)

Email (SMTP)

Policy File (recommended)

All Environment Variables

MCP Tools

check_message

log_interaction

resolve_approval

list_pending

update_profile

get_risk_summary

Decision Types

Content Categories

Safety-Critical (always held or blocked)

Age-Gated (vary by profile)

Behavioral Patterns (notify by default)

Age-Based Default Profiles

Under 13

Ages 13–15

Ages 16–17

Spiral Detection

Approval Flow

Parent Guidance

Out-of-Process Enforcement

Privacy Router

Audit Log

Session Time Limits

Privacy & Data

Development

Project Structure

Adding New Categories

Contributing

License

Crisis Resources

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Waymarkofficial

Latest Blog Posts

MCP directory API

`check_message`

`log_interaction`

`resolve_approval`

`list_pending`

`update_profile`

`get_risk_summary`