SkinKnowledgeBase Skincare Question and Answer MCP
Server Details
Skincare Question and Answer with cited products, ingredients, sources, and comparison context.
- 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 10 of 10 tools scored. Lowest: 3.4/5.
Most tools have distinct purposes, but there is slight overlap between fetch and get_entity, and the deprecated get_ranked_product_for_question duplicates get_ranked_products_for_question.
All tools use consistent snake_case naming with a clear verb_noun pattern (e.g., get_entity, list_entities, search_questions). The deprecated alias is the only minor deviation.
10 tools is well-scoped for a read-only knowledge base, covering core operations (fetch, get, list, search) without being excessive.
The tool set provides complete read-only coverage: fetching individual resources, getting entities by type, searching across all content, and listing entities. No obvious gaps for the stated purpose.
Available Tools
10 toolsfetchARead-onlyIdempotentInspect
Fetch one public SkinKnowledgeBase resource. Required input: id, which may be a canonical SKB URL, public comparison URL, entity ULID, slug, or accepted comparison-page identifier. Returns public read-only text and structured data such as title, canonical URL, entity type, evidence sources, product fact sources, updated_at, and public-safe comparison metadata where applicable.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds details on return content and id flexibility, enhancing transparency without contradicting 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?
Single sentence with all relevant info; slightly dense but no fluff. Could be broken into two for readability.
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?
With output schema present, description covers parameter semantics and return overview sufficiently. No missing critical information for a fetch 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 has 0% description coverage; description compensates fully by explaining the 'id' parameter accepts multiple formats (URL, ULID, slug, etc.), adding crucial context 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?
Description clearly states verb 'fetch' and resource 'one public SkinKnowledgeBase resource'. It distinguishes from siblings by indicating it fetches a single resource and lists acceptable id formats.
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?
Description explains context (public resource, id formats) but does not explicitly state when not to use or provide alternative tools. Implied usage from sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityARead-onlyIdempotentInspect
Fetch one public SkinKnowledgeBase entity. Required inputs: type (Question, Concern, Ingredient, Product, SideEffect, or Source) and slug_or_id (entity slug or ULID). Returns public entity details, canonical URL, text, and linked source/context fields where available.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| slug_or_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe read-only behavior. The description adds value by detailing the return fields (public details, canonical URL, text, linked fields) which helps the agent understand what to expect, though it does not cover potential errors or authentication needs.
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 very concise: two sentences, with the action verb first. No extraneous words, and it efficiently conveys the tool's purpose and parameters.
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 fetch operation, the description covers inputs, outputs, and scope. The presence of an output schema reduces the need to detail return values, but the description adds some context. It lacks information on error behaviors, rate limits, or authentication requirements, which could be considered minor 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 coverage is 0%, so the description must explain parameters. It lists the enum values for 'type' and describes 'slug_or_id' as an entity slug or ULID. This adds meaningful clarification beyond the schema's empty 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 'Fetch one public SkinKnowledgeBase entity' and specifies the required inputs and outputs. It differentiates from sibling tools by focusing on fetching a single entity by type and ID, whereas siblings like get_question_bundle or search are for different operations.
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 does not explicitly state when to use this tool versus alternatives. It provides the input requirements but lacks guidelines on context, such as prefer this over search when you have an exact ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_question_bundleARead-onlyIdempotentInspect
Fetch a public SkinKnowledgeBase Question bundle. Required input: slug_or_id, accepting a question slug or ULID. Optional booleans include include_sources, include_products, and include_validation_summary. Returns the public question answer structure and requested linked public context.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | ||
| include_sources | No | ||
| include_products | No | ||
| include_validation_summary | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, indicating a safe read operation. The description adds that the tool returns public question answer structure and optional linked context, satisfying the need for behavioral disclosure 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?
Two sentences, no wasted words. The first sentence states the core purpose, the second describes parameters and returns. It is efficiently 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?
With an output schema present and four parameters fully described, the description covers the essential information. It could mention an example of slug_or_id format, but overall it is complete for the tool's simplicity.
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 0%, so the description must compensate. It lists the required slug_or_id and optional booleans, explaining that they control what linked public context is included. This adds meaningful semantic information beyond the schema's type/defaults.
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 fetches a 'public SkinKnowledgeBase Question bundle,' specifying the resource and action. It distinguishes from siblings like get_entity or get_ranked_product_for_question by being a bundle that includes the question answer structure and linked public context.
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 does not explicitly state when to use this tool versus alternatives. It implies usage for fetching a combined bundle of question data, but offers no guidance on when to use sibling tools for specific sub-resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ranked_product_for_questionARead-onlyIdempotentInspect
Deprecated read-only alias for get_ranked_products_for_question. Required input: slug_or_id, accepting a question slug or ULID. Returns the same public supporting product context, capped at two products, without modifying anything.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds key behavioral details: it is an alias, capped at two products, and without modifying anything. 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 sentences, front-loading the most critical information (deprecation, alias, input requirement, output limit). 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 an output schema exists and only one parameter, the description covers purpose, status, input, and output limitation. It is sufficiently complete for a deprecated 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 0% schema description coverage, the description adds meaning by specifying that slug_or_id accepts a question slug or ULID, which goes beyond the schema's type and length constraints.
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 is a deprecated read-only alias for get_ranked_products_for_question, and specifies it returns public supporting product context capped at two products. This distinguishes it from 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?
It explicitly marks the tool as deprecated, implying users should prefer get_ranked_products_for_question. The description also notes the output limit, but does not elaborate on exact when-to-use scenarios beyond deprecation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ranked_products_for_questionARead-onlyIdempotentInspect
Return public supporting product context for one eligible SkinKnowledgeBase Question. Required input: slug_or_id, accepting a question slug or ULID. Returns at most two relevant products with public fit/caveat context; it does not purchase, recommend as medical advice, or modify anything.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark read-only, idempotent, non-destructive. Description adds that it does not purchase or recommend as medical advice, and confirms it modifies nothing. Also specifies return limit of two products with fit/caveat context. No 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?
Three concise sentences, front-loaded with purpose. No superfluous words. Efficiently conveys 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?
Covers input, output limit (at most two), and behaviors. Output schema exists so return details are handled externally. Slightly vague on what qualifies a question as 'eligible', but sufficient for simple 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 has one parameter (slug_or_id) with no description. The description explains it accepts a question slug or ULID, adding meaning beyond the schema. Covers the 0% schema description 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?
Clearly states it returns public supporting product context for one SkinKnowledgeBase question. Specifies verb (Return), resource (product context), and scope. Distinguishes from sibling 'get_ranked_product_for_question' by indicating multiple products (at most two).
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?
States required input and that it does not purchase or recommend medical advice, implying read-only usage. However, no explicit when-to-use or when-not-to-use guidance relative to siblings like 'get_question_bundle' or 'get_sources_for_question'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sources_for_questionBRead-onlyIdempotentInspect
Return public Source entities cited by one SkinKnowledgeBase Question. Required input: slug_or_id, accepting a question slug or ULID. Returns source records and canonical URLs used to support the public question page.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
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 safety and idempotency. The description adds that the tool returns public Source entities and canonical URLs, which is consistent and provides some behavioral context beyond 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 is two sentences long, front-loading the purpose and then specifying input/output. Every sentence adds value 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 simple tool with one parameter, full annotations, and an output schema, the description adequately covers what the tool does, what input is required, and what output to expect. It is complete for a straight forward read operation.
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 0% schema description coverage, the description compensates by explaining that 'slug_or_id' accepts a question slug or ULID, adding semantic meaning beyond the schema's type and length constraints. This is essential for correct invocation.
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 verb 'Return' and resource 'public Source entities cited by one SkinKnowledgeBase Question.' It distinguishes from sibling tools like get_question_bundle and search_entities by focusing specifically on sources for a single question. However, it does not explicitly contrast with 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?
The description provides no guidance on when to use this tool versus alternatives, such as get_question_bundle or search_entities. It only describes the input format, not the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_entitiesARead-onlyIdempotentInspect
List public SkinKnowledgeBase entities. Optional input: entity_type (Question, Concern, Ingredient, Product, SideEffect, or Source). Returns published MCP-eligible entity identifiers and metadata for discovery; it does not expose drafts or private/internal data.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive; description adds that it doesn't expose drafts/private data, providing extra context 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, front-loaded with purpose, no extraneous 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 annotations, the description covers scope, filtering, and data limitations adequately.
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 0%, but the description lists the optional entity_type parameter and its enum values, adding 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 it lists public SkinKnowledgeBase entities, specifies it's for discovery, and distinguishes from siblings by noting it doesn't expose drafts or private data.
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?
Describes when to use (discovery) and what it excludes, but doesn't explicitly say when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search public SkinKnowledgeBase content. Required input: query string. Optional inputs: entity_type (Question, Concern, Ingredient, Product, SideEffect, Source), deprecated type alias, limit 1-50, and cursor. Returns compact ranked public results with canonical URLs, snippets, matched fields, scores, and public-safe retrieval metadata. Use for skincare questions, ingredient/product lookup, cited source lookup, and comparison-page discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Deprecated alias for entity_type; kept for compatibility. | |
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| entity_type | No | Preferred entity type filter. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, non-destructive hints. The description adds value by detailing the return structure (compact ranked results with URLs, snippets, scores) and constraints (limit 1-50, query max length). This goes beyond 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 is concise (four sentences), front-loads the action, then lists inputs, return, and use cases. No redundant information; every sentence adds value.
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's complexity (5 params, pagination) and presence of output schema, the description covers purpose, inputs, and return. It misses details on pagination (cursor usage) but is otherwise complete for a search tool with read-only 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 low (40%), but the description clarifies that query is required, limit range is 1-50, entity_type is a filter, and type is deprecated. This compensates for missing schema descriptions, though cursor usage is not explained.
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 purpose: 'Search public SkinKnowledgeBase content.' It lists required and optional inputs and provides specific use cases (skincare questions, ingredient lookup, etc.), distinguishing it from sibling tools like search_entities and search_questions which are more narrowly scoped.
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 usage examples (e.g., 'Use for skincare questions, ingredient/product lookup') but does not explicitly contrast when to use this tool versus sibling tools like search_entities or search_questions. It implies general search but lacks clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesBRead-onlyIdempotentInspect
Search public SkinKnowledgeBase entities. Required input: query string. Optional inputs: type (Question, Concern, Ingredient, Product, SideEffect, Source), limit 1-25, and cursor. Returns matching public entities with slugs/IDs and canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | ||
| limit | No | ||
| query | Yes | ||
| cursor | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
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. The description adds context about return format (slugs/IDs and canonical URLs) but lacks details on pagination or ordering. It does not contradict 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 only two sentences, front-loaded with the core purpose, and then provides essential parameter details without extraneous text.
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 description covers the tool's purpose, inputs, and return format. With good annotations and an output schema (not shown), it is mostly complete for a search tool, but missing pagination behavior and explicit usage guidelines reduce completeness slightly.
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 0% schema description coverage, the description compensates by explaining the required query, listing the enum values for type, and stating the limit range. However, it does not explain the cursor parameter (e.g., for pagination) or mention the default limit of 10.
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 public SkinKnowledgeBase entities and lists the supported entity types. However, it does not explicitly differentiate from sibling tools like 'search' or 'search_questions', which could lead to confusion.
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 mentions required and optional inputs but provides no guidance on when to use this tool versus alternatives such as 'search_questions' or 'list_entities'. No exclusions or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_questionsARead-onlyIdempotentInspect
Search published public SkinKnowledgeBase Question pages. Required input: query string. Optional inputs: filters for concern, ingredient, product, or side_effect; limit 1-25; cursor. Returns public question search results with identifiers and canonical URLs for follow-up retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| cursor | No | ||
| filters | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the SKB MCP tool call succeeded. |
| data | No | Tool-specific public SkinKnowledgeBase response data. |
| meta | No | Response metadata for successful calls. |
| error | No | Error details when ok is false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. The description adds context that only 'published public' pages are searched and describes the return format (identifiers and canonical URLs), enhancing transparency 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?
Two sentences: first defines the action and resource, second lists inputs and returns. No extraneous words, front-loaded with essential 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 4 parameters and nested objects, the description covers the primary function and key parameters. It mentions cursor for pagination but lacks detail on pagination mechanics; however, an output schema exists which likely clarifies the return structure.
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 0% schema description coverage, the description compensates by naming all parameters: required query string, optional filters (concern, ingredient, product, side_effect), limit range (1-25), and cursor. It provides meaning beyond the raw schema, though cursor usage is not detailed.
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 'published public SkinKnowledgeBase Question pages', using a specific verb and resource. It distinguishes from siblings like 'search' and 'search_entities' by specifying the question domain and public nature.
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 lists required and optional inputs, but does not explicitly state when to use this tool over alternatives or provide exclusions. The context of searching questions implicitly differentiates it from siblings, but lacks explicit guidance.
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!