This server provides read-only access to free and cheap events, articles, and deals across 14 US cities in the On the Cheap network. No credentials are required, but a site key is needed for each query (no default city).
List events for a specific day: Get everything happening in a city on a given date, including time, price, and venue. Filter to free-only listings. (Not available for the national site.)
Browse a month's event overview: See a day-by-day breakdown of event counts and previews for an entire month. (Not available for the national site.)
Search articles and deals: Search by keyword, category, location, and date range. Expired/retired deals are excluded by default but can be included.
Fetch a full article: Retrieve a complete article by its ID, slug, or URL, in either readable plain text or raw HTML.
List categories: Get all topic categories (kids, music, food, festivals, art, etc.) with IDs for filtering searches.
List locations/neighborhoods: Get geographic sub-areas within a city with IDs for filtering searches.
List all supported cities: See every city in the network and its site key. Coverage includes Charlotte, Denver, Atlanta, Chicago, Columbus, Seattle, Kansas City, Miami, Orlando, Portland, Richmond, Southern Maine, Raleigh/Durham/Chapel Hill, plus a national deals hub.
Health check a site: Verify that a specific city's site is reachable and its API is responding.
Provides tools to access and search event listings, articles, and categories from the On the Cheap network of WordPress-based local guides across 14 US cities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@onthecheap-mcp What's free in Charlotte this weekend?"
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.
MCP server for the On the Cheap network — local guides to free and cheap things to do across 14 US cities. Daily event listings with times, prices and venues, plus a searchable archive of deals and guides.
Developed and maintained by AI (Claude Code). Use at your own discretion.
No credentials required. Every site is public, so the server reads them server-side over plain HTTPS. There is nothing to configure beyond which city you want, and no browser extension involved.
npx onthecheap-mcpOr as a Claude Code plugin:
/plugin marketplace add chrischall/onthecheap-mcp
/plugin install onthecheap-mcpRelated MCP server: valet-parking-directory
One server reads the whole network. Every tool takes a site argument
naming the city to read — there is no default and no configuration step:
Key | Site | Area |
| Charlotte On The Cheap | Charlotte, NC |
| Mile High on the Cheap | Denver, CO |
| Atlanta on the Cheap | Atlanta, GA |
| Chicago on the Cheap | Chicago, IL |
| Columbus on the Cheap | Columbus, OH |
| Greater Seattle on the Cheap | Seattle–Tacoma |
| Kansas City on the Cheap | Kansas City |
| South Florida on the Cheap | Miami / Broward / Palm Beach |
| Orlando on the Cheap | Orlando, FL |
| Portland Living on the Cheap | Portland, OR |
| RVA on the Cheap | Richmond, VA |
| Southern Maine on the Cheap | Southern Maine |
| Triangle on the Cheap | Raleigh / Durham / Chapel Hill |
| Living On The Cheap | US-wide deals (no local events calendar) |
Common aliases work too — milehigh, raleigh, rva, kc, southflorida.
otc_list_sites reports the same list.
site is required rather than defaulted on purpose: a server that quietly fell
back to one city would answer a question about Denver with Charlotte's data and
give no sign anything was wrong. An unknown key is refused with the valid ones
listed.
All tools are read-only. Every tool except otc_list_sites takes a required
site argument. The two event tools reject national, which has no local
events calendar — it is still searchable via the other tools.
Tool | What it does |
| Everything on a given day — time, price, venue. |
| Day-by-day counts for a month, to find the busiest days. Each day's list is a preview; |
| Search articles by text, category, location and date range. Returns slim summaries by default. |
| One article in full, as readable text or raw HTML. Accepts an id, slug, or URL. |
| Category ids and post counts, for filtering searches by topic. |
| Local area ids and post counts, for filtering geographically. |
| The cities in the network and their |
| Confirm one site is reachable. |
What's free in Charlotte this Saturday?
Find kids' events in Lake Norman in August
Compare free things to do in Denver and Portland next weekend
Retired deals are excluded by default. Each site parks expired offers in an
expired category, so searches skip them and you don't get deals that no
longer exist. Pass include_expired: true to search the archive. The category's
id differs on every site, so it's resolved by slug at request time — a
hardcoded id silently disables the filter elsewhere.
Category and location ids are per-site. Each site is a separate WordPress
install, so id 13 is a different category on every one of them. Resolve ids
against the same site you then search — an id borrowed from another city will
filter to something unrelated rather than error.
Month overviews are previews, with honest counts. The calendar shows at
most four listings per day. otc_events_month_overview reports each day's
true total alongside the preview — call otc_list_events with a date for the
complete schedule.
None. The city is a per-call site argument, not an environment variable, so
there is nothing to set up before use.
npm install
npm test
npm run buildSee docs/OTC-API.md for the verified data surface,
including the events calendar's US M-D-YYYY date routing (an ISO date is
silently parsed as 1970), the month-view truncation, and why term ids are never
hardcoded.
MIT
Day-by-day overview of a whole month from an "on the Cheap" city’s events calendar: for each day, the true number of listings and a short preview of them. Pass the site key for the city (see otc_list_sites). The calendar shows at most four listings per day, so events is a preview while total is the real count — call otc_list_events for a specific date to get that day's complete schedule. The national hub has no local calendar and is not a valid site here. Use this to find the busiest days or scan a month at a glance. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. | |
| month | No | Month to summarise, as ISO YYYY-MM. Defaults to the current month. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds that the calendar shows at most four listings per day, so events is a preview while total is real count. Also explicitly states 'Read-only'. No 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?
The description is relatively concise (5 sentences) and front-loads the main purpose. It avoids verbosity but could be slightly more compact. Still, every sentence adds value.
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 the simple parameters, no output schema, and presence of sibling tools, the description fully covers what the tool returns and its limitations. It also references otc_list_sites for site list, providing a complete picture.
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%, so the description doesn't need to cover parameter details, but it adds context: site key from otc_list_sites, month defaults to current, and site is required with no default. This goes beyond the schema's basic descriptions.
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 it provides a day-by-day overview of a month from an 'on the Cheap' city's events calendar. It specifies the tool shows true number of listings and a short preview, distinguishing it from sibling tools like otc_list_events which returns full schedule.
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?
Explicitly says when to use: to find busiest days or scan a month at a glance. Also says when not to use: for a specific date's complete schedule, call otc_list_events. Also notes national hub is not a valid site.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one "on the Cheap" article in full by numeric id, slug, or full URL. Pass the site key for the city the article belongs to — an id or slug from one site will not resolve on another, and a full URL must match the site you name. Returns the article text as readable plain text by default; set format to "html" for the original markup. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| post | Yes | Post id, slug, or full article URL | |
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. | |
| format | No | Body format: readable text (default) or raw HTML |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and open-world. The description adds behavioral details beyond annotations: default plain-text output, optional HTML format, and site-matching constraints. This adds meaningful context.
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, front-loading the primary purpose and then adding critical details. No superfluous text; every sentence adds value.
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 no output schema, the description covers key aspects: input identifiers, site requirement, and output format. It addresses potential cross-site confusion. Could briefly mention additional return fields, but overall sufficient for a read-only fetch 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?
Schema coverage is 100% with descriptions for each parameter. The description adds extra context such as example aliases for sites and the constraint that id/slug/URL must match the specified site, enhancing understanding beyond the schema.
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 explicitly states the tool fetches a single article by id, slug, or URL. The verb 'fetch' and resource 'article' are clear, and the specificity of identifiers distinguishes it from sibling list 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 provides clear context: requires site key, explains cross-site resolution behavior, and directs to otc_list_sites for available cities. It does not explicitly state when not to use this tool, but the guidance is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify one "on the Cheap" site is reachable and its public API is responding. Pass the site key for the city (see otc_list_sites). The sites need no credentials, so this checks connectivity only. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable context that no credentials are required and that it checks the public API, clarifying the nature of the network access. It doesn't contradict annotations and goes slightly beyond them.
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, front-loaded with the core action and includes only essential operational hints (site key reference, no credentials). Every sentence serves a purpose without 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?
This is a simple single-parameter read-only tool with good annotations. The description covers purpose, prerequisites, and a pointer to the site list. While it doesn't specify the return format, the absence of an output schema and the straightforward 'connectivity check' nature make this acceptable for the complexity level.
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 schema description for 'site' is fully comprehensive (100% coverage), including valid values, aliases, and a reference to otc_list_sites. The description only repeats the need to pass the site key and reference the list, adding no meaningful new parameter semantics beyond the schema.
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 ('Verify') and resource ('one On the Cheap site'), clearly stating the function is to check reachability and API responsiveness. It distinguishes from sibling tools (e.g., otc_search_posts, otc_get_post) by focusing on connectivity rather than content retrieval.
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 context: it tells the user to pass the 'site' key for the city and references otc_list_sites for the full list. It also explains that no credentials are needed, implying this is a safe, standalone health check. It does not explicitly state exclusions, but the purpose is distinct enough among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List one "on the Cheap" site's article categories with their ids and post counts (kids, music, food, festivals, art, museums, and so on). Pass the site key for the city (see otc_list_sites). Use an id to filter otc_search_posts by topic — ids are per-site, so use them only against the site they came from. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open world. The description explicitly states 'Read-only' and adds important behavioral context about per-site ids, which is not covered by annotations. No contradictions.
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 three concise sentences, each adding value: purpose, usage instruction, and a caution about ids. It is front-loaded and efficient.
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 the simple nature of the tool (single parameter, no output schema, safe operation), the description is complete. It explains the output (ids and post counts), how to obtain the input, and how to use the output with another tool. However, it does not detail the exact output structure beyond mentioning ids and post counts.
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 a detailed description of the site parameter. The description adds context about requiring the parameter and referencing otc_list_sites for the full list, but does not add significant new meaning beyond the schema.
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 lists article categories for a specific city site, including ids and post counts. It gives examples of categories and distinguishes from sibling tools like otc_list_sites that list available sites.
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 instructs to pass the site key from otc_list_sites, and explains how to use the returned ids to filter otc_search_posts, with a warning that ids are per-site. This provides clear guidance on when to use and how to use the results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List everything happening in an "on the Cheap" city on a given date, from that site’s events calendar — each with its time, price (most are free) and venue. Pass the site key for the city (see otc_list_sites) and an ISO date (YYYY-MM-DD); the date defaults to today. Set free_only to keep just the no-cost listings. The national hub has no local calendar and is not a valid site here. Use otc_get_post on a listing's url for the full write-up. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day to list, as ISO YYYY-MM-DD. Defaults to today. | |
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. | |
| free_only | No | Only listings marked FREE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds that it's read-only and mentions the national hub limitation, but otherwise relies on annotations for behavioral traits.
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?
Concise 4-5 sentences, front-loaded with purpose, no wasted words. Each sentence adds value.
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?
Covers usage, parameters, output details (time, price, venue), filtering, and sibling tools. Complete for a simple list tool with 3 parameters and no output schema.
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, baseline is 3. Description adds context: site key from otc_list_sites, date defaults to today, free_only filters, and explains aliases and invalid national hub.
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 it lists events for a city on a given date with details (time, price, venue). It distinguishes from siblings like otc_get_post (full write-up) and otc_list_sites (list sites).
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?
Explicitly says when to use (list events for a day), provides alternatives (otc_get_post for full write-up, otc_list_sites for sites), and notes that the national hub is invalid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List one "on the Cheap" site's location taxonomy with ids and post counts — the neighbourhoods and surrounding areas it covers. Pass the site key for the city (see otc_list_sites). Use an id to filter otc_search_posts geographically — ids are per-site, so use them only against the site they came from. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds value by noting ids are per-site and that the tool is read-only, which aligns with annotations. No 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?
Three sentences: first defines purpose, second explains parameter usage, third confirms read-only. No wasted words, front-loaded with key 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?
The tool is simple with one parameter and no output schema. Description covers what is returned, how to get input, how to use results, and safety. Fully adequate for its complexity.
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 a well-described site parameter. Description adds context by referencing otc_list_sites for site list and explaining id scoping, going beyond the schema.
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 states a specific verb 'list' and resource 'location taxonomy' with explicit details (ids, post counts, neighborhoods). It clearly distinguishes from siblings like otc_list_sites (list cities) and otc_get_post (single post).
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?
Description explains that the site key comes from otc_list_sites and that returned ids are per-site, usable for filtering otc_search_posts. It provides context on when to use the output but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every city in the "on the Cheap" network with the site key used to select it. This server reads them all — every other tool takes a site argument, and there is no default, so start here when you do not already know which key covers the city the user means. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds that the server reads all sites and clarifies the role of the `site` key, but does not contradict 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?
Three short sentences, each carrying essential information with 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?
Fully explains the tool's purpose and how it fits into the tool suite, with no gaps given the lack of parameters and robust annotations.
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?
No parameters exist (schema coverage 100%). The baseline for 0 parameters is 4, and no additional parameter details are needed.
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 lists every city in the 'on the Cheap' network with the `site` key, distinguishing it from sibling tools that handle posts, events, categories, and locations.
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?
Explicitly says to start here when the site key is unknown, since all other tools require a `site` argument and there is no default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter one "on the Cheap" site's articles — free and cheap things to do in that city, plus deals, festivals, kids activities and local guides. Pass the site key for the city (see otc_list_sites); the national hub is valid here and carries country-wide deals. Filter by full-text query, category or location id (see otc_list_categories / otc_list_locations), and publication date range. Category and location ids are per-site — resolve them against the SAME site you are searching. Retired deals live in an "expired" category and are excluded by default; set include_expired to search them too. Returns slim summaries by default — use otc_get_post for an article's full text. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag id | |
| page | No | 1-based page number | |
| site | Yes | Which "on the Cheap" city to read. Required — there is no default site. One of: charlotte, denver, atlanta, chicago, columbus, seattle, kansascity, miami, orlando, portland, richmond, southernmaine, triangle, national. Common aliases also work (milehigh, raleigh, rva, southflorida, kc, …). Use otc_list_sites for the full list with the area each one covers. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns slim summaries AND asks WordPress for only the fields they use; "full" returns the whole records. | |
| after | No | Only posts published on or after this date | |
| query | No | Full-text search, e.g. "free museum day" | |
| before | No | Only posts published on or before this date | |
| category | No | Category id from otc_list_categories, for this same site | |
| location | No | Location id from otc_list_locations, for this same site | |
| per_page | No | Results per page (max 100) | |
| include_expired | No | Include retired/expired deals (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses the per-site ID scoping trap ("resolve them against the SAME site you are searching"), the default exclusion of retired deals, and the slim-summaries-vs-full-record behavior. The closing "Read-only" is consistent with readOnlyHint=true, so there is no contradiction — the description adds substantial behavioral context annotations alone would not convey.
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?
Roughly 110 words with the purpose front-loaded in the first clause and no filler sentences — each sentence adds a distinct fact (site resolution, filter options, per-site trap, expired default, output routing). It loses a point for being a single dense paragraph where key call-safety warnings (per-site resolution, expired defaults) sit mid-text rather than being prioritized or visually scannable for a tool with 11 parameters.
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 an 11-parameter tool with no output schema, the description is remarkably complete: it covers site selection, all filter dimensions, the per-site ID caveat, the expired-deals default, and the response-shape routing to otc_get_post. The schema's view parameter fills in the compact-vs-full response detail. Nothing an agent needs to call this correctly — beyond what the schema already documents — is missing.
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%, so the baseline is 3 — every parameter already has a meaningful schema description. The description adds value above that baseline by explaining cross-tool resolution semantics (site keys come from otc_list_sites, ids from otc_list_categories/locations), the per-site-id constraint, and the include_expired default behavior, none of which the schema encodes. This pushes it one step above baseline, though the schema still does the heavy lifting for most parameters.
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 first sentence states a specific verb and resource: "Search and filter one 'on the Cheap' site's articles." It distinguishes itself from siblings explicitly, closing with "use otc_get_post for an article's full text," and the reference tools (otc_list_sites/categories/locations) are clearly separate by nature. An agent knows exactly what this 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 explicitly routes the agent: pass `site` resolved via otc_list_sites, resolve category/location ids against the same site, and use otc_get_post when full text is needed. It gives conditional guidance ("set include_expired to search them too") and clarifies scope ("the national hub is valid here"). When-to-use and when-to-use-an-alternative are both stated outright.
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.
v0.4.1otc_search_posts2 fields changedInput schema / properties / compactRemoved value: -{
- "description": "Return slim summaries instead of full records (default true)",
- "type": "boolean"
-}Input schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact returns slim summaries AND asks WordPress for only the fields they use; \"full\" returns the whole records.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}v0.3.3otc_healthcheckotc_search_postsv0.3.0otc_events_month_overviewotc_get_postotc_list_categoriesotc_list_eventsotc_list_locationsotc_list_sitesEach tool targets a distinct purpose: search, full-article retrieval, single-day events, month overview, category/location/site taxonomies, and health checking. Even the two event tools are clearly separated by date granularity. There is no meaningful overlap between tool responsibilities.
Most tools follow a clear otc_verb_noun pattern, such as otc_search_posts, otc_get_post, and otc_list_sites. The outlier is otc_events_month_overview, which places the noun before the descriptor and omits a leading verb, though it remains readable and consistent in style.
Eight tools is well-scoped for a read-only content browsing server covering articles, events, taxonomies, sites, and connectivity. Each tool serves a distinct and useful purpose without unnecessary bloat or obvious redundancy.
The tool surface covers the full read-only workflow: discovering sites, exploring categories and locations, searching and retrieving articles, browsing events by day and month, and verifying connectivity. There are no dead ends for the stated domain, and write operations are clearly out of scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Google Events listings with dates, venues, and ticket links via a hosted MCP server.
MCP gateway for manoforstaterep.com: articles, search and full text. Read-only, no auth.
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
MCP gateway for donhuffines.com: articles, search and full text. Read-only, no auth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/onthecheap-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
