Skip to main content
Glama
grassyknees

grassyknees-mcp

by grassyknees
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Grassy Knees MCP server

Website: https://grassyknees.com

A small, read-only Model Context Protocol server that lets AI assistants answer questions like "what can I do with my kids in Denver this weekend?" with real listings from Grassy Knees. Grassy Knees is a free directory of kids' and family events, classes and places across 42 US metro areas. Every listing is researched from the organizer's own page and shows the date it was last checked.

Every result includes the listing's grassyknees.com page URL, the organizer's official link and the last-checked date. Each call returns at most 20 listings.

Example prompts

Related MCP server: onthecheap-mcp

Install

Requires Node.js 20 or later. No API key needed.

Claude Desktop

Add this to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "grassyknees": {
      "command": "npx",
      "args": ["-y", "grassyknees-mcp"]
    }
  }
}

Claude Code

claude mcp add grassyknees -- npx -y grassyknees-mcp

Cursor

Add this to ~/.cursor/mcp.json (or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "grassyknees": {
      "command": "npx",
      "args": ["-y", "grassyknees-mcp"]
    }
  }
}

Any other MCP client that runs stdio servers works the same way: the command is npx -y grassyknees-mcp.

Or with Docker: build the image with docker build -t grassyknees-mcp . and use docker run -i --rm grassyknees-mcp as the command.

Tools

Tool

What it does

list_metros

The 42 metro areas covered, with the id to pass to other tools (for example denver, new-york, washington-dc, dallas-fort-worth) and each metro's page URL.

search_activities

Search one metro. Filters: when (today, tomorrow, this-weekend, next-7-days, next-30-days) or start_date/end_date, kind (event, program, place, any), free_only, age, category, query (keywords), limit (1–20, default 10). Soonest first.

get_activity

Full details for one listing from its grassyknees.com URL or id: schedule, upcoming dates, venue, ages, price, registration link, last-checked date.

seasonal_guide

The Halloween, Christmas (lights and holiday events), ice skating or Easter guide for a metro, or the all-metros overview, as Markdown trimmed to max_chars (default 8,000).

Dates are in the metro's local time. this-weekend means Friday to Sunday, the same window as the site's /<metro>/this-weekend page.

Sample transcript

From npm run smoke, run against the live site on 2026-10-28 (trimmed):

tools: list_metros, search_activities, get_activity, seasonal_guide

=== search_activities {"metro":"denver","when":"this-weekend","limit":3}
60 events in Denver for this weekend (2026-10-30 to 2026-11-01); showing the first 3:

1. **[School's Out! Day: Pumpkins & Potions](https://grassyknees.com/denver/activities/school-s-out-day-pumpkins-and-potions--listing-023a33783babb5880fc24e03)**
   Fri, Oct 30 · 8:30 AM–3:30 PM · JCC Denver (Staenberg-Loup Jewish Community Center), 350 S. Dahlia St., Denver, CO 80246
   Ages 5+ · From $100 (...) · Arts & crafts · last checked 2026-10-14

2. **[Rock Creek Farm Pumpkin Patch and Corn Maze](https://grassyknees.com/denver/activities/rock-creek-farm-pumpkin-patch-and-corn-maze--listing-69c7739ea9ac9cfaddb69622)**
   Fri, Oct 30 · 9:30 AM–7:00 PM (also other dates) · Rock Creek Farm, 2005 S 112th St., Broomfield, CO 80020
   Farm admission applies to ages 4 & up · From $10 (...) · Outdoors · last checked 2026-10-28

3. **[JTML Hoppy Halloween Storytime](https://grassyknees.com/denver/activities/jtml-hoppy-halloween-storytime--listing-5ee8642f996422fe0023e407)**
   Fri, Oct 30 · 10:00 AM–11:00 AM · John Tomay Memorial Library, 605 6th Street, Georgetown, CO 80444
   Kids (event category) · Check price · Community · last checked 2026-10-14

More on grassyknees.com: https://grassyknees.com/denver/this-weekend

=== search_activities {"metro":"DC","when":"this-weekend","free_only":true,"limit":3}
20 events, free in Washington, DC for this weekend (2026-10-30 to 2026-11-01); showing the first 3:

1. **[Play Day in the Park at Black Hill Discovery Center](https://grassyknees.com/washington-dc/activities/play-day-in-the-park-at-black-hill-discovery-center--listing-c17ea7ba367fd70feca1648e)**
   Fri, Oct 30 · 11:00 AM–12:00 PM (also other dates) · Black Hill Discovery Center, 20926 Lake Ridge Drive, Boyds, MD 20841
   Ages 6 mos to 3 yrs · Free ($0.00) · Outdoors · last checked 2026-10-24
...

=== get_activity {"url_or_id":"https://grassyknees.com/denver/activities/school-s-out-day-pumpkins-and-potions--listing-023a33783babb5880fc24e03"}
# School's Out! Day: Pumpkins & Potions
- When: Fri, Oct 30 · 8:30 AM–3:30 PM
- Where: JCC Denver (Staenberg-Loup Jewish Community Center), 350 S. Dahlia St., Denver, CO 80246
- Official page: https://www.jccdenver.org/camps/schools-out-camp/
- Last checked: 2026-10-14
...

=== seasonal_guide {"season":"ice-skating","metro":"denver","max_chars":1500}
# Ice skating with kids in Denver
> 9 ice rinks, public skates, holiday skate nights and learn-to-skate classes for kids in the Denver–Aurora–Centennial area this winter, ...
[Trimmed to 1500 of 6484 characters. Full guide: https://grassyknees.com/denver/ice-skating (Markdown: https://grassyknees.com/denver/ice-skating.md)]

How it gets data

Read-only, public endpoints on grassyknees.com, one request at a time:

  • GET /api/activities?city=<metro>&fields=list for searches (one metro's current list, filtered and capped locally to 20 results),

  • GET /api/activities?ids=<id> for get_activity,

  • the site's Markdown pages (/<metro>/<season>.md) for seasonal_guide.

Responses are cached in memory for 10 minutes, so follow-up questions about the same metro don't refetch. Requests send User-Agent: grassyknees-mcp/<version>. Nothing is written to the site and no personal data is sent.

Set GRASSYKNEES_ORIGIN to point the server at another deployment (for testing).

Development

npm install
npm run build
npm run smoke            # calls each tool once against the live site (4 requests)
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list

Credit

Data: Grassy Knees, grassyknees.com. When you show results, link to the listing's grassyknees.com page and mention its last-checked date. Details can change, so confirm on the organizer's official page before you go.

License

MIT for this server's code. Listing data belongs to Grassy Knees and is provided for lookups, not bulk copying.

Available Tools

4 tools
get_activityGet one listingA
Read-only

Full details for one Grassy Knees listing: schedule, venue, ages, price, registration and official links, last-checked date. Pass the grassyknees.com listing URL or the listing id (listing-…) from search_activities.

NameRequiredDescriptionDefault
url_or_idYesA grassyknees.com listing URL such as https://grassyknees.com/denver/activities/<slug>--listing-…, or its id.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower; the description still adds value by disclosing that a 'last-checked date' is returned, which signals data freshness, and that official links are included. It omits error behavior for invalid or unmapped ids, which keeps it from a 5.

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, zero filler, front-loaded with the outcome before the calling instruction. Nothing could be cut without losing information.

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?

With no output schema, the description carries the return-value burden and does so by enumerating the fields returned. For a single-parameter read tool whose annotations already declare the safety profile, nothing an agent needs in order to call it correctly is missing.

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% and the schema itself gives the URL shape and the 'listing-…' id form, so the description's parameter sentence largely restates structured data. The only added meaning is that ids originate from search_activities, which is marginal; 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?

States a specific verb and resource ('Full details for one Grassy Knees listing') and enumerates the payload (schedule, venue, ages, price, registration, official links, last-checked date), which unambiguously separates it from the plural, discovery-oriented sibling search_activities.

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

Usage Guidelines4/5

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

It establishes the call sequence by telling the agent to pass an id 'from search_activities', so the relationship between discovery and detail retrieval is clear. It stops short of explicit exclusions (e.g. what to do when the listing is unknown or the id is stale), so it is clear but not fully rule-bearing.

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

list_metrosList covered metro areasA
Read-only

List the 42 US metro areas Grassy Knees covers, with the metro id to pass to the other tools and each metro's page URLs.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false; the description reinforces the closed, fixed nature of the dataset ('the 42 US metro areas Grassy Knees covers'). It adds useful context about return contents without contradicting the annotations.

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

Conciseness5/5

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

A single front-loaded sentence covering scope, count, and return fields with no filler. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the burden of describing returns; it names the id and page URLs but leaves the response shape (e.g., a list field name) unspecified. For a trivial no-param list tool this is close to sufficient.

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?

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description sensibly spends no words on inputs.

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

Purpose5/5

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

States a specific verb and resource (list the 42 US metro areas) plus exactly what the caller gets back: the metro id and page URLs. The fixed count and scope make it immediately distinguishable from the search/get tools.

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

Usage Guidelines4/5

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

Explicitly frames the output as the id to pass to other tools, which tells the agent this is the entry point for metro-scoped calls. It doesn't name search_activities or seasonal_guide as alternatives or state when this is unnecessary, so it stops short of full routing guidance.

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

search_activitiesSearch kids' activities in a metroA
Read-only

Find kids' and family events, classes/programs and places in one Grassy Knees metro area, filtered by date, price, age, category and keywords. Returns at most 20 listings, soonest first, each with its grassyknees.com page URL, the organizer's official link and the last-checked date. Dates are in the metro's local time.

NameRequiredDescriptionDefault
ageNoChild's age in years; keeps listings whose published age range includes it (listings without an age range are kept).
kindNoevent = dated one-offs (default); program = classes and multi-week series; place = museums, parks, rinks and other places to go; any = all three.
whenNoDate window. Default next-7-days. Ignored when start_date is given.
limitNoHow many listings to return, 1–20 (default 10).
metroYesMetro id from list_metros (e.g. denver, new-york, washington-dc, dallas-fort-worth). Common names like 'NYC' or 'Dallas' also work.
queryNoKeywords matched against title, description, venue, organizer and address (all words must match), e.g. 'pumpkin', 'library storytime', 'Boulder'.
categoryNo
end_dateNoEnd of the custom range, YYYY-MM-DD. Defaults to start_date.
free_onlyNoOnly free listings.
start_dateNoStart of a custom date range, YYYY-MM-DD (metro local time).

TDQS

A4/5.0
Behavior4/5

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

readOnlyHint and openWorldHint already establish the safety profile, and the description adds real context beyond them: result cap of 20, soonest-first ordering, per-listing URL/official-link/last-checked-date payload, and that dates are in metro local time. It stops short of noting pagination absence or any rate limits.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose, then result shape, then time-zone caveat. Every clause carries information an agent would otherwise have to guess.

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?

There is no output schema, and the description compensates by describing the return payload and ordering. What remains unexplained is minor: result-count defaults and the start_date-overrides-when interaction, both of which live only in the 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?

Schema description coverage is 90%, so the schema already carries parameter meaning (enums for kind/when/category, age range semantics, limit bounds). The description only re-summarizes the dimensions as a filter list (date, price, age, category, keywords), adding no syntax or interaction detail such as how start_date overrides when.

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

Purpose5/5

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

The description states a specific verb and resource ('Find kids' and family events, classes/programs and places') plus the scoping constraint 'in one Grassy Knees metro area'. This contrasts sharply with get_activity (single listing) and list_metros (metro ids), so an agent can separate it from its siblings without opening a schema.

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

Usage Guidelines3/5

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

Usage is only implied: the filter list signals 'search in the metro', but the description never says when to prefer get_activity or seasonal_guide, nor that the metro id typically comes from list_metros. A competent agent can infer the flow, but the routing guidance is absent.

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

seasonal_guideSeasonal guideA
Read-only

Grassy Knees' seasonal guide (Halloween events, Christmas lights and holiday events, ice skating rinks, Easter egg hunts) for one metro, or the national overview when metro is omitted. Returns the page's Markdown (quick answers plus listings with links, ages, prices and last-checked dates), trimmed to max_chars.

NameRequiredDescriptionDefault
metroNoMetro id from list_metros. Omit for the all-metros overview.
seasonYes
max_charsNoTrim the Markdown to this many characters (default 8000).

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint and openWorldHint already declared, the description earns credit for disclosing the return payload (Markdown with quick answers, listings, links, ages, prices, last-checked dates) and the trimming behavior governed by max_chars. It says nothing about caching, rate limits, or how the live pages are fetched, which keeps it from a 5.

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?

Two compact sentences: scope first, return shape second, with the season examples kept in a parenthetical rather than a list. Dense but front-loaded; no wasted preamble.

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?

No output schema exists, so describing the Markdown contents and the character-trimming is exactly the missing piece, and it is supplied. For a three-parameter read-only retrieval tool with annotations, an agent has everything it needs to call this correctly.

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 67% and the description largely restates what the schema already documents: metro's omission meaning is already in the field description, and max_chars trimming is likewise documented on the property. Only the season-to-content mapping (which holidays/events each season yields) adds meaning the enum alone doesn't convey.

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?

States a concrete resource (Grassy Knees' seasonal guide), enumerates the seasons it covers, and explains the single-metro vs national-overview scope in the same sentence. An agent can distinguish this from get_activity/search_activities by the resource type, though sibling names are not called out.

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?

Gives a clear selection rule for the metro parameter (omit it to get the national overview) and the season list frames when the tool is appropriate. It stops short of explicitly saying when to prefer this over search_activities for the same events.

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.

  1. 4 tool updatesv0.1.0
    • First observedget_activity
    • First observedlist_metros
    • First observedsearch_activities
    • First observedseasonal_guide
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation4/5

The tools map to mostly distinct stages: metro coverage, filtered search, detail lookup, and a curated seasonal guide. The only meaningful overlap is seasonal_guide versus search_activities for holiday events, but the guide's curated/national role is reasonably clear from its description.

Naming Consistency4/5

Three tools follow a clear verb_noun pattern: list_metros, search_activities, get_activity. seasonal_guide is a noun-phrase outlier, but the set remains predictable and readable overall.

Tool Count5/5

Four tools is compact and well-scoped for a family-activity directory: list coverage, search listings, fetch details, and browse seasonal guides. No tool feels redundant or missing at the count level.

Completeness4/5

The core discovery flow is covered: list metros, search listings, get full activity details, and access seasonal guides. Minor gaps exist, such as no way to enumerate filter categories or browse by venue/organizer, but agents can work around these with keyword search.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Eventflare MCP

    mluckx
    A
    license
    A
    quality
    D
    maintenance
    Search 8,000+ corporate event venues across 40+ cities. Tools for venue search by capacity/category, pricing guides, expert advice articles, and inquiry handoff. Read-only, PII-redacted, UTM-attributed.
    7
    10 npm
    MIT

  • onthecheap-mcp

    chrischall
    A
    license
    A
    quality
    A
    maintenance
    MCP server for the On the Cheap network — local guides to free and cheap things to do across 14 US cities. Provides daily event listings with times, prices and venues, plus a searchable archive of deals and guides.
    8
    307 npm
    MIT

  • br.com.oiair/marketplace

    makeev11
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI assistants to search current public children's activities in Florianópolis, Brazil, read organization profiles and their published groups with schedules and prices, and obtain a canonical link for requesting a visit. All five tools are read-only, publicly accessible over Streamable HTTP with no API key, and never submit a request or confirm a booking.
    MIT