Skip to main content
Glama

Look up Rakuten Ichiba Tag Details

ichiba_tag_search
Read-onlyIdempotent

Get tag details by ID from Rakuten Ichiba. Returns tag group, name, and parent tag to identify attributes like size or color from item search results.

Instructions

Look up details for a specific Rakuten Ichiba tag by tag ID. Tags are facet-style attributes (size, color, etc.) attached to items. Returns the tag group this tag belongs to, the tag name, and any parent tag. Tag IDs surface in ichiba_item_search item responses (each item carries an attributeIds array) and in ichiba_genre_search.

[JA] 特定のタグIDの詳細を取得します。タグはファセット属性(サイズ、色など)で商品に紐づいています。タグ名、所属タググループ、親タグを返します。タグIDは ichiba_item_search の各商品 attributeIds や ichiba_genre_search から取得できます。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tag_idYesTag ID to fetch details for. Tag IDs are discoverable from ichiba_item_search responses (each item carries tagIds) and from ichiba_genre_search. タグID。ichiba_item_search のレスポンス内 tagIds や ichiba_genre_search から取得できます。
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds value by specifying return fields and the nature of the lookup. No contradictions. Could mention absence of side effects or error handling, but sufficient given 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?

Concise, front-loaded, each sentence adds value. Includes bilingual text without redundancy. Zero waste.

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?

For a simple lookup tool with one parameter and no output schema, description covers purpose, return structure, and data provenance. No gaps noted.

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 parameter description already explaining tag ID and its source. Description repeats this info but does not add new meaning beyond 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 clearly states it looks up tag details by tag ID, explains what tags are (facet-style attributes), and lists return fields (tag group, name, parent). It distinguishes from siblings by mentioning where tag IDs are found (ichiba_item_search, ichiba_genre_search).

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 provides usage context by stating when to use (to get tag details) and where to get the tag ID. However, it does not explicitly state when not to use or compare to alternatives, leaving room for improvement.

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

Install Server

Other Tools

Latest Blog Posts

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/mrslbt/rakuten-mcp'

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