Enrichment.Kids Activity Marketplace
Server Details
Find kids enrichment activities: camps, classes, after-school programs, and tutoring near you.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose with no overlap: search_activities finds activities, get_activity_details provides full session-level details, check_availability checks real-time session availability, and get_provider_info retrieves provider information. The descriptions explicitly guide agents on when to use each tool, preventing misselection.
All tool names follow a consistent verb_noun pattern (e.g., search_activities, get_activity_details, check_availability, get_provider_info). The naming is predictable and readable, using clear verbs like 'search', 'get', and 'check' paired with specific nouns.
With 4 tools, this server is well-scoped for its purpose as a kids activity marketplace. Each tool earns its place by covering essential workflows: discovery (search), detail retrieval, availability checking, and provider lookup, without being overly sparse or bloated.
The tool set covers core workflows for activity discovery, registration, and provider information, with clear guidance on sequencing (e.g., search then get details). A minor gap exists in lacking explicit tools for user account management or booking actions, but agents can work around this using the provided share_url links for checkout.
Available Tools
3 toolsget_activity_detailsGet activity detailsARead-onlyIdempotentInspect
Returns the activity's listing-page "url" plus a "share_url" per session that goes directly to checkout — always use a session-level share_url when helping a user register or purchase. Get full details for a specific enrichment activity including description, sessions with pricing and availability, provider info, and location.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Activity URL slug returned by search_activities (e.g., 'summer-coding-camp-petaluma'). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint) are already present. The description adds value by detailing returned fields (url, share_url, description, sessions, etc.) and the share_url's checkout purpose, enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently front-load the most important outputs (url, share_url) and usage tip, then list full details. No wasted words.
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?
Despite no output schema, the description enumerates key return fields (url, share_url, description, sessions, pricing, availability, provider info, location). This is comprehensive for a read-only, single-parameter tool.
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 single parameter 'slug' is fully described in the input schema (100% coverage). The description does not add additional meaning beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns activity details including URL, share URL, description, sessions, provider info, and location. It distinguishes itself from siblings like search_activities and get_provider_info by focusing on full details for a specific activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'always use a session-level share_url when helping a user register or purchase,' providing clear context-specific guidance. While it doesn't list alternatives, the differentiation from sibling tools is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_provider_infoGet provider infoARead-onlyIdempotentInspect
Get profile and active listings for an enrichment activity provider (organization). Returns provider details and all their public activities.
| Name | Required | Description | Default |
|---|---|---|---|
| organization_id | Yes | Provider organization ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by specifying that the tool returns provider details and public activities, clarifying the output scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the purpose and then specifying the output. Every sentence is informative and there is no redundancy.
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 with one required parameter and no output schema. The description explains the output (provider details and active listings) sufficiently for a read-only operation, though it could mention pagination or error cases.
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% for the single parameter 'organization_id'. The tool description does not add any further information about the parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('profile and active listings for an enrichment activity provider'). It clearly distinguishes from sibling tools 'get_activity_details' and 'search_activities' by focusing on the provider entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('Get profile and active listings for an enrichment activity provider'), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives, resulting in a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_activitiesSearch activitiesARead-onlyIdempotentInspect
To help a user register or purchase, call get_activity_details after this — it returns session-level "share_url" links that go directly to checkout. Search children's enrichment activities (camps, classes, after-school programs) by location, age range, date, or keyword. Returns a paginated list with listing-page "url" fields; pass each result's "slug" to get_activity_details for full details.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (e.g., 'Petaluma', 'San Francisco') | |
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 50) | |
| query | No | Keyword search (e.g., 'coding camp', 'ballet', 'science') | |
| state | No | Two-letter US state code (e.g., 'CA', 'OR', 'WA') | |
| age_to | No | Maximum participant age (4–19) | |
| date_to | No | Latest session end date (YYYY-MM-DD) | |
| age_from | No | Minimum participant age (4–19) | |
| latitude | No | Latitude for proximity search | |
| date_from | No | Earliest session start date (YYYY-MM-DD) | |
| longitude | No | Longitude for proximity search | |
| categories | No | Comma-separated category IDs | |
| distance_miles | No | Search radius in miles (default: 25, max: 100) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, so the description adds value by disclosing the paginated list output with 'url' fields and the need to pass 'slug' to another tool. It does not contradict annotations and provides additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a brief workflow tip. It is front-loaded with the most important guidance (workflow) and contains no unnecessary words.
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 13 parameters and no output schema, the description explains the overall purpose and workflow but lacks detail on how filters combine and the full output structure (only mentions url and slug). It could be more complete for a search tool with many filters.
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 parameter described. The description groups parameters by search type (location, age, date, keyword) but does not add new meaning beyond the schema. Baseline score is appropriate as the description does not significantly enhance parameter understanding.
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 searches for children's enrichment activities by various criteria (location, age, date, keyword). It distinguishes itself from siblings by explicitly suggesting calling get_activity_details afterwards, implying that search_activities provides slugs for detailed information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: use search_activities first, then get_activity_details for registration/purchase. It does not discuss when not to use this tool or alternatives like get_provider_info, but the workflow guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!