Littles Weekly

Find dated outings

get_events

Read-onlyIdempotent

Dated outings for kids 0–6 in one city: this week’s list plus dated listings from the seasonal and free pages (Santa visits, light displays, Thanksgiving, Noon Year’s Eve, free museum days). Each has dates, time, venue, address, price, free flag, soldOut flag (sold-out events stay listed, after the available ones), ages, description, the official link we checked, the date we checked it, the littlesweekly.com page URL and eventUrl (the event’s own shareable page; hand this link out when someone wants to send or save it). Defaults to everything from today on.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>"
    },
    "name": "get_events"
  }
}

Input Schema

Name	Required	Description
`age`	No	Child’s age in years; keeps outings whose age range includes it
`city`	Yes	City slug from list_cities (e.g. "omaha", "kansas-city", "twin-cities"). A plain city name like "Kansas City" also works.
`page`	No	Limit to one page, e.g. "santa" or "this-week"
`limit`	No	Max results (default 40)
`end_date`	No	Last day, YYYY-MM-DD
`free_only`	No	Only outings a family can do without paying
`start_date`	No	First day, YYYY-MM-DD (defaults to today in the city)
`indoor_only`	No	Only outings marked indoor (weekly list only)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, and the description adds meaningful behavior beyond that: sold-out events stay listed but are ordered after available ones, the default window starts today, and it discloses provenance fields (official link, date checked, eventUrl). It stops short of pagination or result-cap behavior.

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?

Purpose is front-loaded in the opening clause and the single paragraph stays on one topic. The long parenthetical enumeration of returned fields is dense but justified given there is no output schema to carry that information.

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

Completeness4/5

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

With no output schema, the description compensates by listing the returned fields and ordering rules, and all parameters are documented in the schema. Missing only cross-tool routing guidance, which leaves the agent to infer when to prefer this over search or get_page.

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 8 parameters with formats, bounds, and defaults. The description largely restates those (today default, free flag) without adding syntax or interaction detail, so the baseline 3 applies.

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 specific resource (dated outings for kids 0–6 in one city) and what it draws from (this week's list plus seasonal/free pages). An agent can tell what it returns, but the description never distinguishes it from siblings like get_page or search, so sibling differentiation is missing.

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

Usage Guidelines2/5

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

The description gives default behavior (today onward) but no when-to-use or when-not-to-use guidance, and never mentions the alternative siblings (get_page, search). The 'hand this link out' note is advice about a returned field, not about selecting this tool.

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

All Littles Weekly tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?