get_microsite_infoIdentity and links for Psychiatry for Teens: tagline, audience, focus, publisher, sponsor relationship to Emora Health, and key URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's safety profile is covered. The description adds value by enumerating the exact content returned (tagline, audience, etc.), providing behavioral context beyond the annotation. It does not contradict any 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 description is a single sentence, front-loaded with the core purpose ('Identity and links for Psychiatry for Teens') and followed by a concise list of content types. Every phrase earns its place; no waste.
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?
Since there is no output schema, the description is the primary source for what the tool provides. It covers the main content categories adequately. However, it could be slightly more specific about what 'key URLs' entails, but overall it is sufficient for a low-complexity read-only tool.
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?
With zero parameters, the input schema offers nothing to explain. The description compensates by detailing what the tool returns, giving the agent a clear understanding of the output. It is a solid baseline for a parameterless tool.
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 clearly states what the tool returns: identity and links for the Psychiatry for Teens microsite, including specific categories like tagline, audience, focus, publisher, sponsor relationship, and URLs. This differentiates it from sibling tools that handle articles or crisis resources.
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 implies usage (when you need microsite information) but does not explicitly state when to use it versus alternatives. There is no mention of exclusions or that this is the go-to tool for microsite details, though the sibling tool names make the distinction clear.
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.
Each tool has a clearly distinct purpose: article discovery (list, search), retrieval (get), citation (cite), site identity (microsite info), and crisis support. No two tools overlap, and the descriptions reinforce their uniqueness.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., cite_article, list_articles, get_crisis_resources). The naming is uniform and predictable.
Six tools is well-scoped for a read-only article library. It covers discovery, retrieval, citation, site context, and crisis support without unnecessary bloat.
The domain is fully covered: users can search, list, retrieve full articles, generate citations, access site information, and get crisis resources. No critical operations are missing, and the set forms a complete workflow.