Skip to main content
Glama

kpop_new_concerts

Concerts in Korea newly registered or updated since a date (YYYYMMDD, default 7 days), optional artist. 10 free calls/day.

Input Schema

NameRequiredDescriptionDefault
qNo
langNoanswer language: en (default), ja or koen
sinceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose one real behavioral trait: the '10 free calls/day' quota. However, it says nothing about return shape, pagination, auth requirements, or what 'updated' means for a previously-listed concert.

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?

A single compact sentence with the resource and recency filter front-loaded and the rate limit appended. Very little waste, though 'optional artist' is a slightly loose gloss for a parameter literally named `q`.

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

Completeness3/5

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

No output schema and no annotations, so the description is the only source of behavior. It covers purpose, the date filter, and quota, but omits result fields, result ordering, and whether the query matches artist name, venue, or free text.

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 only 33% (lang is the sole documented param), so the description must compensate. It supplies the YYYYMMDD format and the 7-day default for `since`, and maps 'optional artist' to `q`, leaving only edge semantics of the free-text query unstated.

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 (Korea concerts) with a meaningful scope qualifier: 'newly registered or updated since a date'. This is distinguishable from kpop_search by the recency framing, though it does not name that sibling explicitly.

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?

No when-to-use, when-not-to-use, or alternative routing is given. An agent must infer that this is for recently-changed concerts rather than general K-pop lookups; nothing points to kpop_search or korea_festivals as the alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.