公開テンプレートギャラリーのテンプレート詳細を slug で取得します（認証不要）。説明全文・カテゴリ・タグ・サムネイルURL・テンプレート版・複製実績数・作成者名を返します。slug は search_gallery_templates の結果から取得してください。重要: ギャラリーのテンプレートはまだワークスペースにありません。この slug では PDF を出力できないため、使う場合は copy_gallery_template で複製し、返された designId を get_design_parameters / generate_pdf_sync に渡してください。
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | テンプレートの slug（search_gallery_templates の結果に含まれる識別子） |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: no authentication is required, the returned fields are enumerated, and critically, the slug cannot be used directly for PDF generation because the template is not yet in the workspace.
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 well-structured and front-loaded: purpose first, then return fields, then slug source, then the important workflow caveat. Every sentence contributes actionable information without redundancy.
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?
For a single-parameter read-only lookup tool with no output schema, the description is complete: it enumerates return fields, explains where the slug comes from, and warns about the PDF limitation with the correct follow-up path. An agent has everything needed to invoke and use the result correctly.
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?
Schema description coverage is 100%, and the schema already explains that slug is the identifier from search_gallery_templates. The description repeats this same information without adding new parameter-level semantics, so the baseline score 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 ('取得します') and resource ('公開テンプレートギャラリーのテンプレート詳細'), and clarifies it is fetched by slug. It also lists the exact returned fields, making the tool's purpose unambiguous and distinct from the sibling search tool.
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 explicitly tells the agent to obtain the slug from search_gallery_templates, and provides a clear conditional workflow: if PDF output is needed, use copy_gallery_template and pass the designId to get_design_parameters / generate_pdf_sync. This is strong when-to-use and 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.