searchSearch KimchiSushi for source-backed Korea/Japan study, working-holiday, or public community information.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query in Korean, Japanese, or English. |
| Name | Required | Description | Default |
|---|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by emphasizing 'source-backed' results and the specific topical scope (Korea/Japan study, working-holiday, public community), which helps the agent set expectations about result content. It 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?
The description is a single, front-loaded sentence that immediately conveys the action and scope. It is concise with no redundant words, and every phrase earns its place by specifying the resource, the nature of the search ('source-backed'), and the topical coverage.
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 (one parameter), has a rich output schema (not shown but known to exist), and annotations that cover safety and idempotency. The description sufficiently explains what the tool searches and the kind of information it returns, leaving no major gaps for an agent to misuse it. The existence of an output schema means return-value details need not be in the description.
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 covers 100% of the parameter ('query' is described as a natural-language search query in Korean, Japanese, or English). The description does not add parameter-specific details beyond this, but since schema coverage is complete, the baseline of 3 is appropriate.
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 states a specific verb ('Search') and resource ('KimchiSushi') with a clear scope: 'source-backed Korea/Japan study, working-holiday, or public community information.' This distinguishes it well from sibling tools like get_recent_posts or fetch, which clearly are for retrieving specific posts rather than searching across topics.
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 clearly implies when to use this tool: whenever the agent needs to search for the specified types of information. It provides context by listing the information scope, but does not explicitly name alternatives or exclusion cases. Since the sibling tools are distinct (e.g., get_post_with_comments for retrieving a specific post), the usage context is clear enough without 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.
Add one secure layer between your agents and this server.
Most tools are clearly distinct (search, recent posts, health check, routing), but fetch and get_post_with_comments both retrieve posts, differing only by id type and whether comments are included. This overlap could cause misselection, though the descriptions help.
Naming styles are mixed: bare verbs (fetch, search), get_ prefixed names (get_post_with_comments, get_recent_posts), and a long noun-like name (get_kimchisushi_agent_entrypoints). The inconsistent use of verbs and prefixes makes the pattern unpredictable.
With 6 tools, the server is well-scoped for a read-only content access service. Each tool serves a clear purpose without redundancy or excessive sprawl.
The tool surface covers the core lifecycle for the domain: searching, fetching individual items, listing recent items, and routing to relevant areas. No obvious gaps for a read-only information retrieval service.