onthecheap-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.3
Disambiguation5/5
Each tool maps to a unique resource/action: article search, article fetch, daily events, monthly events overview, category taxonomy, location taxonomy, site listing, and health check. No two tools overlap in purpose.
Naming Consistency4/5
Most tools follow the verb_noun pattern after the otc_ prefix (search_posts, get_post, list_events, list_categories, list_locations, list_sites). Two deviations: 'events_month_overview' is a noun phrase and 'healthcheck' is a compound noun, but the prefix and overall readability keep it coherent.
Tool Count5/5
8 tools is well-suited to the server's scope: a read-only content and events API for multiple city sites. Each tool provides a distinct necessary operation without bloat or thinness.
Completeness5/5
The tool set fully covers the stated purpose: discovering sites, browsing taxonomies, searching and reading articles, and listing events at daily and monthly granularity. Healthcheck wraps up operational needs. No obvious read-only gaps.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 7 community issues answered or closed in the last 6 months
- 43 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context such as 'Returns slim summaries by default', 'Retired deals live in an expired category and are excluded by default', and the national hub's country-wide coverage. It does not mention pagination behavior or the 'tag' parameter, but this is partially covered by the schema. No contradiction with 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?
The description is a single focused paragraph that front-loads the core purpose, then incrementally covers site selection, filters, per-site ID caveats, expired deals, and return format/alternative tool. Every sentence contributes operational knowledge without repetition or padding.
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?
Given the tool's complexity (11 parameters, cross-tool ID dependencies, default behaviors) and lack of an output schema, the description covers most key aspects: site selection, filter options, per-site constraints, expired handling, and return type. It omits a clear explanation of the 'tag' parameter and the exact structure of slim summaries, but these are partially inferable from the schema.
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 description coverage is 100%, so baseline is 3. The description adds value by explaining how to resolve category/location IDs against the same site, clarifying the 'expired' category context for include_expired, and noting that the national hub is valid for the site parameter. However, it does not elaborate on the 'tag' parameter or pagination, leaving those details to the already descriptive schema.
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 searches and filters a specific city's On the Cheap articles, explicitly listing content types (deals, festivals, kids activities, local guides). It distinguishes itself from siblings by referencing otc_get_post for full-text retrieval and implicitly from otc_list_* tools by focusing on articles rather than metadata/events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: requires the 'site' key, references otc_list_sites for valid sites, mentions the national hub scope, directs users to otc_list_categories/locations for ID resolution, warns that IDs are per-site, and points to otc_get_post for full text. It also explains the 'include_expired' parameter for retrieving expired deals, giving clear when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![onthecheap-mcp MCP server](https://glama.ai/mcp/servers/chrischall/onthecheap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/onthecheap-mcp)

Score Badge

Copy to your README.md:

[![onthecheap-mcp MCP server](https://glama.ai/mcp/servers/chrischall/onthecheap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/onthecheap-mcp)

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/chrischall/onthecheap-mcp'

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