Retrieve a template's content, approval status, and positional variables using its ID to confirm readiness before sending.
Read one template's content, approval status and positional variables before sending it. Use this instead of list_templates when you already have the template ID.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | Superchat template ID, for example one returned by list_templates. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds value by naming the exact fields returned (content, approval status, positional variables) and the intended timing, which is not visible in the schema or annotations. This gives the agent a concrete sense of what the read yields.
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 two sentences with no filler. The purpose and output are front-loaded in the first sentence, and the usage rule is in the second. Every word earns its place.
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 simple one-parameter read tool with rich annotations and no output schema, the description is complete. It states what is read, when to use it, and how it differs from the sibling list_templates. The agent has enough to select and invoke the tool 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 documents template_id with format constraints and an example source (list_templates). The description reinforces the 'known ID' context but does not add new parameter-level detail. Baseline 3 is appropriate because the schema carries the semantic weight.
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 names a specific verb ('Read') and resource ('one template's content, approval status and positional variables'), which precisely states what the tool does. It also distinguishes itself from list_templates by focusing on a single known template. This leaves no ambiguity about the tool's purpose.
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 says to use this tool instead of list_templates when the template ID is already known. This gives an agent a clear decision rule and names the alternative. It also adds practical context ('before sending it') that reinforces why retrieval matters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.