Clinician-reviewed library on ADHD in teens — accommodations, executive function, evaluations.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: fetching, listing, searching, citing, crisis resources, and site info. No overlap between them.
All tool names follow a consistent verb_noun pattern, using verbs like get, list, search, cite, and clear nouns. No mixed naming conventions.
6 tools is well-scoped for an article library server, covering core operations without redundancy or bloat.
The tool set covers the full read-only lifecycle: retrieve single, list all, search, cite, plus essential auxiliary info. No obvious gaps for the intended domain.
cite_articleCite articleAGet a formatted citation for a ADHD in Teens article. Supports AMA, APA, and Chicago styles.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug. | |
| format | No | Citation style (default ama). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, and the description adds the scoping constraint that the tool only works for 'ADHD in Teens' articles. This is beyond the schema, which lacks this context. It also reinforces the read-only nature with 'Get'.
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 short sentences, front-loaded with the core action, and every word contributes value. It avoids redundancy and is appropriately sized for the tool's complexity.
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 read-only tool with two parameters, the description adequately conveys the purpose and style support. It does not explicitly describe the return format, but the phrase 'formatted citation' is sufficient given the absence of an output schema. It could add error-case context, but this is not critical.
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%, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides; it simply restates the article slug and the style options already enumerated.
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 identifies the verb ('Get'), the resource ('a formatted citation for a ADHD in Teens article'), and distinguishes it from sibling tools that fetch article content or lists. It also mentions supported styles, making the purpose unambiguous.
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 gives no explicit guidance on when to use this tool versus alternatives, and does not mention prerequisites or exclusions. The purpose implies a citation need, but no direct comparison or use-case context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleGet articleAFetch a single article from ADHD in Teens by slug. Returns title, body content, author, clinical reviewer, citations, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description adds value by enumerating the returned fields (title, body content, author, clinical reviewer, citations, metadata). This gives insight into the tool's output behavior without contradicting the annotation.
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, concise sentence that packs in the action, resource, method, and return value. There is no fluff or redundant information.
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 tool with a readOnlyHint annotation, the description covers the essential behavior: what it fetches and what it returns. No output schema exists, so enumerating return fields fills that gap adequately. The simplicity of the tool means this is sufficient contextual completeness.
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 schema already describes the single parameter 'slug' with 'Article slug.' at 100% coverage. The description reinforces that the slug identifies the article to fetch, which is helpful, but it does not add significant extra meaning beyond what the schema provides.
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 a specific action ('Fetch a single article') and resource ('from ADHD in Teens by slug'). It differentiates this tool from siblings like list_articles and search_articles by indicating it retrieves one specific article via an identifier.
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 phrase 'by slug' implies usage when the slug is already known, and that this tool targets a single article rather than listing or searching. However, it does not explicitly name alternatives or state when not to use this tool, leaving the guidance implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_crisis_resourcesGet crisis resourcesAReturn the canonical 988 / 911 / Crisis Text Line payload. Surface this immediately whenever the user signals self-harm or imminent danger.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description is consistent. It adds valuable context beyond the annotation: the payload is 'canonical' and should be surfaced immediately during crisis signals. No description of return format, but that is less critical here.
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 sentences, no wasted words. The first sentence states the function, the second gives the usage trigger. Excellent front-loading and brevity.
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 zero-parameter, read-only tool with no output schema, the description is nearly complete. It explains what the tool returns and when to invoke it. Slight lack of detail about the actual payload contents, but 'canonical' implies a standard set.
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?
There are zero parameters, so the description has nothing to add. The schema already covers everything (100% coverage), and the baseline of 4 applies.
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 uses a specific verb ('Return') and names a clear resource ('canonical 988 / 911 / Crisis Text Line payload'). It is immediately distinguishable from sibling tools, which all focus on articles or microsite info.
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 states when to use the tool: 'whenever the user signals self-harm or imminent danger.' It does not mention when not to use it or alternatives, but the trigger condition is actionable and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_microsite_infoAbout this micrositeAIdentity and links for ADHD in Teens: tagline, audience, focus, publisher, sponsor relationship to Emora Health, and key URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds specific content details (sponsor relationship, URLs) but does not disclose additional behavioral traits such as rate limits, caching, or response size. It is accurate but not particularly insightful beyond the annotation.
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, front-loaded sentence that efficiently lists all the content categories. Every word adds value, and there is no redundancy or 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?
Given the simplicity of the tool (no parameters, no output schema, read-only), the description is sufficiently complete. It enumerates all the key data points that would be returned, so users know what to expect without needing an output schema.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics. The empty schema is fully self-explanatory, and the description clarifies the fixed nature of the returned information.
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 identifies the tool's function: returning identity and links for the ADHD in Teens microsite, and explicitly enumerates the content fields (tagline, audience, focus, publisher, sponsor relationship, key URLs). This distinguishes it from sibling tools like get_article or list_articles, which handle article content rather than microsite metadata.
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?
No guidance is provided for when to use this tool versus alternatives. The description does not mention that it is for microsite metadata, nor does it contrast with sibling tools. Users must infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_articlesList articlesAPaginated list of articles from ADHD in Teens. Returns title, slug, summary, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-indexed). | |
| limit | No | Max results per page (default 30, max 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature. The description adds context by specifying the returned fields (title, slug, summary, URL), but does not disclose behavioral details such as default ordering, pagination errors, or rate limits. With annotations present, this is acceptable but not rich.
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 extremely concise: two short sentences that front-load the purpose and key output information. Every word earns its place, with no filler or 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 simple list tool with two optional parameters and no output schema, the description covers the essential behavior: what it lists, the source, and the returned fields. It does not explain sorting or how to navigate through many pages, but these are not critical for basic usage given the schema's param descriptions. Sibling tool context implies this is the general list tool, which is sufficiently complete.
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 input schema provides complete descriptions for both parameters (page and limit) with defaults and constraints, achieving 100% coverage. The description adds no additional parameter meaning, so it neither compensates nor detracts. The baseline 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 clearly states the tool's function: 'Paginated list of articles from ADHD in Teens' with specific verb 'list' and resource 'articles'. It also names the output fields (title, slug, summary, URL), making the purpose unambiguous. The pagination mention differentiates it from sibling tools like get_article (single article) and search_articles (filtered search).
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 provides no guidance on when to use this tool versus alternatives such as search_articles or get_article. It does not mention scenarios like 'browse all' or 'when you need a list without filters', leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesSearch articlesASearch ADHD in Teens's editorial corpus by query. Returns title, slug, summary, and URL for matching articles.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alternate parameter name for `query`. | |
| limit | No | Max results (default 10, max 50). | |
| query | Yes | Free-text search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation. The description adds the return value details (title, slug, summary, URL), which is valuable because there is no output schema. It does not disclose sorting, pagination, or any edge cases, but the read-only annotation lowers the bar.
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 focused sentence that front-loads the tool's purpose and return values. Every word earns its place, with no redundancy or 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?
The tool is a simple read-only search with a rich schema and few parameters. The description covers the return fields, which is important without an output schema. It lacks details about sorting or pagination, but those are not critical for a straightforward search 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?
Schema description coverage is 100%, with each parameter (q, limit, query) already documented. The description adds no additional meaning beyond the schema, 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 'Search ADHD in Teens's editorial corpus by query', which uses a specific verb and resource, and clearly distinguishes this from siblings like list_articles by highlighting the query-based mechanism. It also lists return fields (title, slug, summary, URL), further clarifying 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 implies usage when a query-based search is needed, but it does not provide explicit when-to-use vs. alternative guidance or exclusions. With siblings like list_articles, the intended differentiation is evident but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!