get_glp1_side_effects
台灣核准的 GLP-1 減重藥(猛健樂 tirzepatide、週纖達 semaglutide、善纖達 liraglutide)副作用發生率、嚴重警訊、何時就醫、食藥署提醒。不提供劑量建議。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
台灣核准的 GLP-1 減重藥(猛健樂 tirzepatide、週纖達 semaglutide、善纖達 liraglutide)副作用發生率、嚴重警訊、何時就醫、食藥署提醒。不提供劑量建議。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the geographic/regulatory scope (Taiwan-approved drugs), the safety-oriented nature of the content, and an explicit out-of-scope boundary (no dosage advice). It stops short of stating that the tool is read-only and takes no parameters or what the output shape is.
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?
Two tightly packed sentences with the resource front-loaded, followed by a short scope-limiting clause. Every element (drug names, content categories, disclaimer) earns its place; no filler.
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 parameterless knowledge-retrieval tool with no output schema and no annotations, the description covers the essential ground: what topic, which drugs, and what categories of information are returned. The absence of any return-format note is a minor gap given this tool type.
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 tool takes zero parameters and the schema is an empty object, so there is nothing for the description to clarify; baseline 4 applies. The mention of specific drug names implicitly maps the query domain but is not parameter-level guidance.
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?
States a precise resource (side-effect profile of Taiwan-approved GLP-1 weight-loss drugs) and enumerates the exact content returned: incidence rates, serious warning signs, when to seek care, and TFDA reminders. Naming the three specific drugs (tirzepatide, semaglutide, liraglutide) makes the scope unmistakable and clearly separates it from the screening/counseling siblings.
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?
Usage is implied by the content scope (a user asking about GLP-1 side effects), and the closing exclusion '不提供劑量建議' draws one boundary. However, it never names an alternative sibling or states an explicit when/when-not condition, so routing still relies on inference.
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.