ask
Server Details
Non-diagnostic child-development knowledge by Pinnacle Blooms: search, milestones, ICF crosswalk.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.2/5 across 11 of 11 tools scored. Lowest: 3.5/5.
Each tool targets a distinct action or query type: browsing taxonomy values, comparing topics, fetching full answers, searching, exploring milestones, tracing pathways, identifying red flags, etc. No two tools have overlapping purposes, making it easy for an agent to select the correct one.
All names are lowercase with underscores for multi-word tokens. While the naming pattern is not strictly verb_noun (e.g., 'milestones' is a noun, 'home' is a noun), it is consistent in style and each name clearly conveys the tool's function. The minor inconsistency in part of speech does not hinder readability.
With 11 tools, the API is well-scoped for its domain—a comprehensive child-development knowledge corpus. Each tool covers a distinct aspect (discovery, search, retrieval, comparison, coding, milestones, pathways, red flags, related content, curated hubs), and no tool feels superfluous or missing.
The tool set provides a full lifecycle for interacting with the corpus: discovering taxonomy values (browse, home), searching and fetching answers (search, fetch), comparing topics, looking up by clinical codes, exploring developmental trajectories (milestones, pathway, red_flags), and navigating related content. There are no obvious gaps for the stated purpose.
Available Tools
11 toolsbrowseARead-onlyIdempotentInspect
List the available values for one taxonomy kind across the corpus: persona, route, domain, condition, or age-band. Use this to discover what can be passed to topic.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Taxonomy kind to enumerate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, read-only operation. The description adds that it enumerates one taxonomy kind across the corpus, which is consistent but does not disclose additional behavioral traits (e.g., whether results are sorted, or if the corpus affects values). Given the annotations, the description adds moderate extra value.
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, front-loaded with the action and result. Every sentence adds value: the first states the action and scope, the second provides the use case. No unnecessary words.
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 tool has one parameter with a full enum and an output schema (not shown but present), the description is complete. It explains the tool's purpose, its parameter, and its relationship to another tool, making it fully actionable for an agent.
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 100% coverage with an enum description for `kind`. The description adds meaning beyond the schema by explaining that the values are 'across the corpus' and that the tool helps 'discover what can be passed to `topic`', which gives context for how the parameter value is used.
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 'List the available values for one taxonomy kind across the corpus' with a specific verb and resource, and enumerates the five possible kinds: persona, route, domain, condition, or age-band. It also ties the purpose to the sibling tool `topic`, distinguishing it from other siblings like `search` or `fetch`.
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 'Use this to discover what can be passed to `topic`', providing clear guidance on when to use this tool. It does not mention when not to use it or discuss alternatives, but the context is sufficient for an agent to understand its intended role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compareARead-onlyIdempotentInspect
Compare two developmental topics, conditions, or skills side by side (e.g. 'speech delay' vs 'autism'; 'speech therapy' vs 'occupational therapy'). Returns corpus-grounded points of similarity and difference. Non-diagnostic.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First topic. | |
| b | Yes | Second topic. | |
| limit | No | Max items per side (1–25, default 6). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'Non-diagnostic' and 'corpus-grounded', providing useful but not extensive behavioral context. No contradictions.
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 concise sentences that front-load the core purpose and provide an example, with no unnecessary words.
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 comparison tool with full schema coverage, an output schema exists, and annotations cover safety, the description adequately explains the tool's behavior and output without gaps.
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 schema already documents each parameter. The description adds only the context that parameters are topics/conditions/skills, which is minimal additional meaning beyond the schema.
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 compares two developmental topics, conditions, or skills side by side, provides concrete examples, and distinguishes it from sibling tools (e.g., 'related' returns related topics, not side-by-side comparison).
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 for comparison but does not explicitly state when not to use or suggest alternative tools. The context is clear from the tool name and examples, but no exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchARead-onlyIdempotentInspect
Fetch the full published answer for a Pinnacle Ask result. id accepts a slug from search, an /ask path, or a full pinnacleblooms.org/ask URL. Returns the complete answer document (markdown), Everyday Therapy™ tip, what-to-watch guidance, FAQs, and the canonical URL to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Result id — slug, /ask path, or full URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | No | |
| text | Yes | |
| title | No | |
| metadata | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return content in detail: complete answer document, Everyday Therapy tip, what-to-watch guidance, FAQs, and canonical URL. This adds value beyond the annotations (which already indicate read-only and idempotent). No contradictions.
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 concise with three sentences, each serving a distinct purpose: defining the action, explaining the parameter, and listing the return value. It is well-structured and front-loaded.
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 has an output schema (not shown but referenced in signals), so return values are already documented. The description adds completeness by listing the specific components of the answer, making it fully informative.
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 already documents the parameter 'id' with a description. The description repeats essentially the same information, so no additional meaning is added. Given 100% schema coverage, a 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 'Fetch the full published answer for a Pinnacle Ask result,' specifying the exact action and resource. It distinguishes the tool from siblings like 'search' by explaining that it retrieves a full answer given 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 description explains that 'id accepts a slug from search, an /ask path, or a full URL,' providing context for input. However, it does not explicitly state when to use this tool versus alternatives, nor does it give conditions for disuse, but the connection to 'search' is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
homeARead-onlyIdempotentInspect
Overview of the Pinnacle Ask knowledge layer: featured content, corpus statistics, and entry points. Takes no arguments. Good first call to orient before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is an overview and a first call, complementing the annotations without contradicting them.
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 wasted words, front-loading the purpose ('Overview of the Pinnacle Ask knowledge layer') and ending with clear usage guidance.
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 tool with an output schema, the description completely covers what the tool does (overview, featured content, corpus statistics, entry points) and when to use it (first call before searching).
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 no parameters, and the description explicitly states 'Takes no arguments.' Schema coverage is 100%, so the description adds sufficient meaning for an empty parameter set.
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 it provides an 'Overview of the Pinnacle Ask knowledge layer' with specific elements (featured content, corpus statistics, entry points), and distinguishes it from siblings by calling it a 'good first call to orient before searching'.
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 it takes no arguments and is a 'good first call to orient before searching', indicating when to use it. It implies it is not for searching but does not explicitly list exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_codeARead-onlyIdempotentInspect
Look up Pinnacle Ask content by clinical/standards code — WHO ICF (e.g. 'b167'), ICD-11, ICHI, or SNOMED. Returns corpus entries crosswalked to that code. Useful for clinicians, researchers, and policy teams.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Standards code, e.g. 'b167' (ICF), '6A02' (ICD-11). | |
| limit | No | Max items (1–25, default 8). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering safety and idempotency. The description adds only that it 'returns corpus entries crosswalked to that code', which is minimal extra behavioral context.
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, front-loaded with the core function, and every sentence adds value. No redundancy or irrelevant 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?
Given that the tool has a complete input schema, annotations, and an output schema (not shown but indicated), the description adequately covers the tool's purpose and usage context. It is sufficient for an agent to decide when and how to use it.
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 has 100% description coverage for both parameters. The description adds value by providing examples of code formats (e.g., 'b167', '6A02') and mentioning crosswalking, which clarifies the tool's operation beyond the schema's generic descriptions.
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 looks up Pinnacle Ask content by clinical/standards code, listing specific code systems (WHO ICF, ICD-11, ICHI, SNOMED) and providing examples. It distinguishes from sibling tools like search and browse by focusing on code-based lookup.
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 specifies the context of use (clinicians, researchers, policy teams) and the types of codes accepted, making usage clear. However, it does not explicitly state when not to use this tool or list alternatives, though the sibling tools provide implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
milestonesARead-onlyIdempotentInspect
Developmental milestones from the Pinnacle Ask corpus, optionally filtered by child age in months and developmental domain. Use to answer 'what should my child be doing at N months' style questions. Non-diagnostic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (1–25, default 12). | |
| domain | No | Optional domain filter, e.g. 'speech', 'motor', 'social'. | |
| age_months | No | Child age in months (0–216). Strongly recommended. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe, read-only behavior. The description adds value by stating the data source (Pinnacle Ask corpus) and emphasizing it is non-diagnostic, which provides important context beyond 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 two sentences long, front-loaded with the core function, and includes a use case and a disclaimer. Every sentence is informative 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?
Given the presence of an output schema, the description does not need to explain return values. It covers the source, filters, use case, and limitation. For a simple query tool with comprehensive annotations and schema, this 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?
Schema coverage is 100% with each parameter described. The description adds value by noting that age_months is 'strongly recommended' and domain is optional, and provides an example of typical usage. It does not introduce new parameter details beyond the schema but reinforces the intended use.
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 returns developmental milestones from a specific corpus, with optional filters. It explicitly says it answers 'what should my child be doing at N months' style questions and notes it is non-diagnostic. It distinguishes itself from siblings like 'red_flags' and 'pathway' by its specific 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 gives a clear use case (age-related developmental questions) and a disclaimer (non-diagnostic). However, it does not explicitly mention when not to use it or suggest alternatives among sibling tools, such as using 'red_flags' for concerns about delays.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pathwayARead-onlyIdempotentInspect
Trace how a developmental topic or skill progresses across age stages — a staged pathway view (e.g. how 'speech' develops from babbling to sentences). Returns corpus entries grouped per stage.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic or skill, e.g. 'speech', 'walking', 'social play'. | |
| per_stage | No | Items per stage (1–10, default 5). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is clearly a safe, idempotent read operation. The description adds minimal behavioral context beyond stating that results are grouped per stage, which does not significantly augment the 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 consists of two concise, front-loaded sentences. The first sentence states the purpose with a clear example, and the second explains the output format. No unnecessary words.
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 tool with 2 parameters and an output schema, the description is complete. It explains the input (topic/skill), optional parameter (per_stage), and output (corpus entries grouped per stage). The example clarifies the concept.
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 both 'topic' and 'per_stage' parameters described in the schema. The tool description adds no new parameter semantics beyond what the schema provides; it only reiterates the grouping of results. Baseline 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 action ('Trace how a developmental topic or skill progresses across age stages') and the resource ('staged pathway view'), with an example ('speech' from babbling to sentences). It distinguishes the tool from siblings like 'milestones' or 'red_flags' by focusing on staged progression.
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 (e.g., when to use 'pathway' instead of 'milestones' or 'topic'). It only describes what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
red_flagsARead-onlyIdempotentInspect
Early warning signs ('what to watch') for a developmental topic, domain, and/or age in months — framed as guidance to seek professional evaluation, never as a diagnosis. Use when a caregiver asks whether a behaviour is concerning.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items (1–25, default 12). | |
| topic | No | Optional topic, e.g. 'speech delay', 'autism'. | |
| domain | No | Optional domain filter. | |
| age_months | No | Optional child age in months (0–216). |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds important behavioral context: the tool never provides a diagnosis and frames guidance for professional evaluation. This complements annotations without contradiction.
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 concise sentences: first explains what the tool does, second gives usage scenario. No wasted words, front-loaded with key 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?
Given the presence of an output schema and 100% parameter coverage, the description is complete. It covers purpose, usage context, and behavioral constraints. The tool is straightforward with clear parameters and safe annotations.
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 coverage is 100% with descriptions for all 4 parameters. The tool description mentions topic, domain, and age in months but does not add new parameter-level meaning beyond the schema. Meets the baseline for high schema coverage.
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 returns early warning signs for developmental topics, domains, and age ranges. It distinguishes itself from siblings like milestones and search by specifying a distinct purpose: providing guidance for professional evaluation, not diagnosis.
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 'Use when a caregiver asks whether a behaviour is concerning', providing a clear usage scenario. It does not explicitly mention when not to use, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search the Pinnacle Ask child-development knowledge corpus (pinnacleblooms.org/ask) — real parent questions with clinically grounded, non-diagnostic answers covering speech, motor, social, cognitive, sensory, feeding and behavioural development from birth to 18 years. Returns ranked results with ids; pass a result id to fetch for the full answer. Optionally filter by child age in months and/or developmental domain.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1–25, default 10). | |
| query | Yes | Natural-language question or topic, e.g. 'my 2 year old is not talking'. | |
| domain | No | Optional developmental domain filter, e.g. 'speech', 'motor', 'social'. | |
| age_months | No | Optional child age in months (0–216) to bias results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| query | Yes | |
| total | Yes | |
| source | Yes | |
| results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints. Description adds value by specifying that results are ranked, include IDs, and that answers are clinically grounded and non-diagnostic. No contradiction with 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?
Two sentences convey purpose, scope, output format, and usage flow concisely with no 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?
Given annotations and presence of an output schema, the description is complete. It covers what the tool returns (ranked IDs), how to use filters, and links to the next step (fetch). No gaps for a 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 coverage is 100%, so parameters are well-documented. The description mostly reiterates schema info (e.g., 'natural-language question', 'optional age filter'). Adds little 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 the tool searches a specific child-development knowledge corpus, returns ranked results with IDs, and guides users to use 'fetch' for full answers. This distinguishes it from siblings like 'fetch'.
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?
Provides explicit guidance to use 'fetch' after searching for full answers, and mentions optional filters for age and domain. Lacks explicit when-not-to-use compared to other sibling tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
topicARead-onlyIdempotentInspect
Curated hub of Pinnacle Ask content for one value of a taxonomy: kind ∈ persona | route | domain | condition | age-band, plus the value (e.g. kind='condition', value='autism'). Use browse first to discover valid values.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Taxonomy kind: persona, route, domain, condition, or age-band. | |
| limit | No | Max items (1–25, default 10). | |
| value | Yes | Value within the kind, e.g. 'speech' for domain. |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | No | Sanitised jsonb projection from the locked ask_* RPC layer. |
| tool | Yes | |
| source | Yes | |
| disclaimer | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the concept of a 'curated hub,' which provides a slight behavioral context but does not conflict with 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?
Two sentences, no redundant information, front-loaded with the main purpose. Every sentence adds value without being verbose.
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 presence of an output schema and fully described parameters, the description is complete. It also provides essential guidance ('use browse first') that is not available elsewhere.
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 has 100% coverage with clear descriptions for all three parameters. The description adds semantic value by explaining the 'one value of a taxonomy' relationship and enumerating the allowed kinds, which goes beyond the schema.
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 explicitly states the tool retrieves curated content for a specific taxonomy kind and value, with a clear list of valid kinds and an example. It distinguishes itself from siblings by directing users to 'browse' for valid values.
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 a clear precondition: 'Use `browse` first to discover valid values.' This helps the agent avoid invalid inputs. It does not explicitly state when not to use the tool, but the guidance is sufficient.
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.
Discussions
No comments yet. Be the first to start the discussion!