fetchFetch one KimchiSushi citation source or public community post by its opaque search result id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Opaque id returned by search. |
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| url | Yes | ||
| text | Yes | ||
| title | Yes | ||
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description need not repeat those. The description adds no additional behavioral context beyond the fetch-by-id semantics, which is already clear from the schema and 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 entire description is one sentence, front-loaded with the action and object, with no filler or repetition of annotations/schema. It earns a 5.
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 fetch-by-id tool with one documented parameter, strong annotations, and an output schema. The description covers what the tool retrieves and how to identify the item, so nothing critical 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?
The single parameter 'id' is fully described in the schema as an opaque id returned by search, and the description confirms this by saying 'opaque search result id.' Since schema coverage is 100%, the description adds little beyond the schema, so a baseline 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 uses the specific verb 'Fetch' and identifies the resource ('one KimchiSushi citation source or public community post') plus the method of selection ('by its opaque search result id'). This clearly distinguishes it from sibling listing/search tools and from get_post_with_comments, which targets posts with comments.
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?
It implicitly states the tool should be used with an opaque search result id, which strongly suggests a search-first workflow. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it falls just short of a 5.
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.