Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cdisc-library-mcp-server search for biomedical concepts about diabetes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This MCP server provides a compact, task‑oriented wrapper around the CDISC Library. It covers discovery (suggest + search), Biomedical Concepts (latest + versioned packages), and SDTM Dataset Specializations (latest + packages). Use it to search, fetch a concept or specialization with one call, then follow _links for deeper context. For reproducible results tied to an effective date, use package routes; for exploration, use latest routes.
CDISC: A global, non‑profit that develops data standards to streamline clinical research and enable interoperability. See the CDISC website.
CDISC Library: Programmatic access to CDISC standards and artifacts (e.g., SDTM, CDASH, ADaM, Controlled Terminology), including Biomedical Concepts and SDTM Dataset Specializations. Browse via the Library Browser and obtain API access from the Developer Portal.
Node.js: >= 18
CDISC Library API key: subscription key from the Developer Portal
Create/sign in to a CDISC Library account.
Browser login: library.cdisc.org
Open the API Management Developer Portal and sign in with the same credentials.
Developer Portal: api.developer.library.cdisc.org
Retrieve your subscription key (API key) on the portal.
Use the key as api-key in a header (recommended) or query string.
export CDISC_API_KEY=your_key_here
npm startbash/zsh:
export CDISC_API_KEY=your_key
export CDISC_AUTH_LOCATION=header # or: query
npm startfish:
set -x CDISC_API_KEY your_key
set -x CDISC_AUTH_LOCATION header # or: query
npm startPowerShell:
$env:CDISC_API_KEY = "your_key"
$env:CDISC_AUTH_LOCATION = "header" # or: "query"
npm startCDISC_API_KEY (required): your subscription key
CDISC_AUTH_LOCATION (optional): header (default) or query
CDISC_AUTH_HEADER (optional): header name when using header auth, default api-key
CDISC_AUTH_QUERY (optional): query param name when using query auth, default api-key
CDISC_API_BASE_URL (optional): override server base URL, default https://api.library.cdisc.org
CDISC_OPENAPI_DIR (optional): directory for OpenAPI YAML; defaults to server/openapi. The manifest.json sets this to ${DXT_DIR}/server/openapi when packaged as DXT so the extension is self‑contained.
CDISC_CACHE_ENABLED (optional): set to 0 to disable caching. Default: enabled.
CDISC_CACHE_TTL_MS (optional): TTL for GET responses in milliseconds. Default: 60000.
CDISC_CACHE_MAX_ENTRIES (optional): max cache entries (LRU). Default: 500.
CDISC_RETRY_COUNT (optional): number of retries for transient 5xx/network errors. Default: 2.
CDISC_RETRY_BACKOFF_MS (optional): base backoff per attempt in ms. Default: 300.
CDISC_CACHE_DEBUG (optional): set to 1 to log cache/retry activity to stderr.
CDISC_CACHE_PERSIST_PATH (optional): file path to persist cache to disk (JSON). Default: disabled.
CDISC_CACHE_EXCLUDE_REGEX (optional): regex to exclude cache matches; defaults also exclude search/suggest.
CDISC_CACHE_INCLUDE_REGEX (optional): regex to force-include cache matches.
Spec: DXT MANIFEST.md
CLI: DXT CLI.md
# Option A: one‑off
npm install -g @anthropic-ai/dxt
dxt pack # creates cdisc-library-mcp.dxt in the project directory
# Option B: via npm script
npm run pack:dxtClaude Desktop: open the generated .dxt file to install the local MCP server.
Any DXT‑compatible app can load this extension per its instructions. See the DXT repo: https://github.com/anthropics/dxt.
Generic:
list_operations(filter?)
call_operation(operationId, pathParams?, query?, body?, headers?, timeoutMs?)
Cache management:
cache.clear() — clear all in-memory cache entries
cache.invalidate(contains?, regex?) — invalidate entries by substring or regex match
Discovery:
search.suggest(q, top?, select?)
search.query(q, start?, pageSize?, facets?, filters?)
Biomedical Concepts (latest):
bc.list(category?), bc.get(conceptId), bc.categories()
Biomedical Concepts (packages):
bc.packages.list(), bc.packages.listConcepts(package), bc.packages.getConcept(package, conceptId)
SDTM Specializations (latest):
sdtm.list(domain?), sdtm.get(datasetSpecializationId), sdtm.domains(), sdtm.byBiomedicalConcept(conceptId)
SDTM Specializations (packages):
sdtm.packages.list(), sdtm.packages.listSpecializations(package), sdtm.packages.getSpecialization(package, datasetSpecialization)
Auth & bases:
API key (header or query): api-key: <YOUR_KEY>
Library base: https://api.library.cdisc.org/api
Cosmos BC base: https://api.library.cdisc.org/api/cosmos/v2/mdr/bc
Cosmos SDTM Specializations base: https://api.library.cdisc.org/api/cosmos/v2/mdr/specializations
Discovery:
GET /mdr/suggest — params: q, top, select
GET /mdr/search — params: q (req), start, pageSize, facets, filters domain|codelist|conceptId|product|version|dataset|variable|standard
Biomedical Concepts:
Latest: /biomedicalconcepts, /biomedicalconcepts/{biomedicalconcept}, /categories
Version‑locked: /packages, /packages/{package}/biomedicalconcepts, /packages/{package}/biomedicalconcepts/{biomedicalconcept}
Key fields: _links, conceptId, href, categories, shortName, synonyms, resultScales, definition, coding, dataElementConcepts, ncitCode
SDTM Dataset Specializations:
Latest: /sdtm/datasetspecializations?domain=VS|LB|…, /sdtm/datasetspecializations/{dataset_specialization_id}, /sdtm/domains, by BC: /datasetspecializations?biomedicalconcept={conceptId}
Version‑locked: /sdtm/packages, /sdtm/packages/{package}/datasetspecializations, /sdtm/packages/{package}/datasetspecializations/{datasetspecialization}
Key fields: _links, datasetSpecializationId, domain, shortName, source, sdtmigStartVersion, sdtmigEndVersion, variables[]
variables[] keys: name, dataElementConceptId, isNonStandard, codelist, subsetCodelist, valueList, assignedTerm, role, dataType, length, format, significantDigits, relationship{subject,linkingPhrase,predicateTerm,object}, mandatoryVariable, mandatoryValue, originType, originSource, comparator, vlmTarget
Behavior:
Pagination on /mdr/search: start, pageSize
Errors surfaced as‑is: 401, 422, 404/406/5xx
Links: follow _links.self, _links.parentPackage, _links.parentBiomedicalConcept
Scripts in package.json:
npm run test:mcp — smoke tests via a minimal MCP stdio client (scripts/test_mcp.js). Requires CDISC_API_KEY.
npm run test:plan — broader happy‑path + error scenarios (scripts/test_plan.js). Requires CDISC_API_KEY.
401 Unauthorized: ensure CDISC_API_KEY is set; switch CDISC_AUTH_LOCATION between header and query if needed.
Timeouts/network errors: check connectivity to https://api.library.cdisc.org; set timeoutMs when using call_operation.
API changes: update the YAML specs under server/openapi, then restart. You can override the base via CDISC_API_BASE_URL.
Corporate proxies: configure your environment (e.g., HTTPS_PROXY, HTTP_PROXY).
License: MIT (see LICENSE.md).
Code of Conduct: see CODE_OF_CONDUCT.md.
List Biomedical Concept categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'List', implying a read-only operation, but provides no details on what is returned (e.g., format, structure). Since no annotations exist, the description carries full burden for behavioral disclosure, which it fails to meet.
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 with no unnecessary words. It is optimally concise for the simplicity of the tool.
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 adequately covers the basic purpose for a tool with no parameters and no output schema, but it lacks any mention of output format or additional context, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds value by specifying the purpose ('Biomedical Concept categories'). This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('Biomedical Concept categories'), making the tool's purpose immediately clear. It distinguishes itself from siblings like bc.list (list concepts) and bc.get (retrieve a concept).
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 on when to use this tool versus alternatives (e.g., bc.list, bc.get). The description is purely declarative without any contextual advice for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest Biomedical Concept by conceptId.
| Name | Required | Description | Default |
|---|---|---|---|
| conceptId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'Get latest Biomedical Concept' without disclosing what 'latest' means, whether the conceptId must exist, what the return format is, or any error conditions. This is insufficient for a mutation-free lookup.
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 with a single efficient sentence front-loading the key action. However, some additional context (like expected format of conceptId) could be added without making it 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 that there is only one parameter, no output schema, and no annotations, the description is too sparse. It omits necessary details such as what 'latest' means in context, whether the tool handles missing conceptIds, and what the response contains.
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 has 0% description coverage, and the description only adds that the parameter is the 'conceptId' used to identify the concept. No format, constraints, or examples are provided, leaving the parameter's semantics largely underspecified.
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 'Get', the resource 'Biomedical Concept', and the selection mechanism 'by conceptId'. This provides a specific and unambiguous purpose that distinguishes it from sibling tools like 'bc.list' (likely lists all concepts) and 'bc.categories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the latest version of a specific concept by its ID, but it does not explicitly state when to use this tool versus alternatives (e.g., when to use 'bc.list' versus 'bc.get') or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List latest Biomedical Concepts (optional category).
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'latest' but no details on ordering, pagination, limits, or effect of missing category. Minimal behavioral disclosure.
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, front-loaded, no wasted words. However, it may be too brief, sacrificing completeness for conciseness.
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 no output schema and no annotations, the description should provide more context (e.g., return format, pagination, meaning of 'latest'). Currently inadequate for a list 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 0%, but description adds minimal value: indicates category is optional. No details on valid values, format, or behavior when omitted.
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 (list) and resource (Biomedical Concepts) with an optional filter (category). It distinguishes from siblings like bc.get and bc.categories implicitly, though not explicitly.
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 on when to use this tool versus siblings (e.g., bc.get for a specific concept, bc.categories for category list). The description only states what it does, not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BC within a package.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| conceptId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states a generic retrieval action, omitting details on side effects, authorization needs, or return format. This is insufficient for safe and accurate use.
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 short but underspecified. It fails to earn its place by omitting critical information, making it more of a placeholder than a useful explanation.
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 simplicity (2 params, no output schema), the description should at least explain the parameters and return value. It does not, leaving significant gaps for an AI 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 has 0% description coverage for parameters, and the description does not clarify what 'package' and 'conceptId' represent or their expected formats. The description adds no 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 'Get BC within a package' specifies a verb and resource, but 'BC' is ambiguous and does not differentiate from sibling tools like 'bc.packages.listConcepts'. The purpose is somewhat clear but lacks specificity.
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 on when to use this tool versus alternatives (e.g., bc.packages.listConcepts). There is no mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List BC packages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and description lacks behavioral details like pagination, limits, or output nature. Simple tool but still misses transparency.
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, concise but minimal. Front-loaded, yet lacks substance.
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 list tool, expected to mention return format or pagination. Missing output details, especially with no 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?
No parameters exist, and schema coverage is 100%. Description adds no param info, but baseline 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 it lists BC packages, using a specific verb and resource. It distinguishes from sibling tools that have different namespaces or actions, though 'BC packages' could benefit from brief explanation.
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 on when to use this tool versus alternatives (e.g., bc.packages.listConcepts, sdtm.packages.list). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List BCs within a package.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read-only list operation but lacks details on pagination, rate limits, or any side effects. Minimal disclosure.
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 single sentence is concise but overly brief. While no words are wasted, the description lacks necessary detail, so it's not optimally structured for utility.
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 one required parameter and no output schema, the description is incomplete. It omits what BCs are, expected output format, and any constraints on the package parameter, leaving the agent uninformed.
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%; the description does not explain the 'package' parameter (e.g., format, allowed values). It adds no meaning beyond the empty 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 'List BCs within a package' clearly states the action and resource, and distinguishes from siblings like bc.packages.getConcept (which retrieves a single concept) and bc.packages.list (which likely lists packages). However, it doesn't define 'BCs', relying on 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?
No guidance on when to use this tool versus alternatives. Only states what it does, with no mention of prerequisites, limitations, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all in-memory cache entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'clear all' implying destructive action, but does not disclose irreversibility, impact on other users, or side effects. Adequate but not thorough.
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 with no fluff. Every word adds value, and it is perfectly concise for the tool's simplicity.
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 zero parameters and low complexity, the description is mostly complete. However, for a destructive operation like clearing all cache, some behavioral context (e.g., impact, dependencies) would improve 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?
No parameters exist (param count 0), so the baseline is 4. The description does not need to add parameter information, and it is appropriately silent on the matter.
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 'clear' and the resource 'all in-memory cache entries', which is specific and distinguishes from siblings like cache.invalidate that likely target specific entries.
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 on when to use this tool versus alternatives (e.g., cache.invalidate), nor any caution about the destructive nature of clearing all cache. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invalidate cache entries whose URL matches a substring or regex.
| Name | Required | Description | Default |
|---|---|---|---|
| contains | No | Substring to match against cached keys | |
| regex | No | JavaScript regex string to match against cached keys |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'Invalidate' (mutating) but gives no detail on side effects, safety, or scope (e.g., whether multiple entries can be invalidated). Minimal disclosure.
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, no redundancy. Front-loads the core purpose efficiently.
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 tool with 2 optional params and no output schema, description covers key usage but lacks details like behavior when no match or multiple matches. Adequate but not fully 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 description coverage is 100%, so baseline is 3. Description adds context about matching URLs, but parameters are already described in schema. Minimal added value.
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 the tool invalidates cache entries, specifying matching by URL substring or regex. This is a specific verb+resource, distinguishing it from siblings like cache.clear.
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 implies usage for targeted invalidation but does not explicitly state when to use vs alternatives (e.g., cache.clear) or provide any exclusions. Usage context is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke an OpenAPI operation by operationId. Supports path, query, and body inputs. Handles API key via env CDISC_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes | ||
| pathParams | No | ||
| query | No | ||
| body | No | ||
| headers | No | ||
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description must disclose behavior. It mentions API key handling via env var, which is useful. But it does not state whether operations are read-only or destructive, error behavior, or rate limits. Adds some value but incomplete.
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 crisp sentences, no fluff. Front-loaded with core purpose and key capabilities (operationId, input types, API key handling). Every sentence earns its place.
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 no output schema, no annotations, and 6 parameters, the description covers essential invocation but lacks details on error handling, response format, or which operations are available. Adequate for a generic tool but leaves 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% with 6 parameters. Description adds meaning: 'path, query, and body inputs' map to pathParams, query, and body. However, headers and timeoutMs are not explained, and operationId's role is implied. Partial compensation for missing schema 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?
Description clearly states it invokes an OpenAPI operation by operationId, specific verb and resource. Mentions input types. However, it does not differentiate from sibling tools which are concrete operations, missing explicit distinction.
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 on when to use this generic tool versus the many specific sibling operations (e.g., bc.get, sdtm.get). No alternatives or exclusions mentioned, leaving the agent uncertain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available OpenAPI operations across loaded specs.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Substring to filter operationId or path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose behavior such as scope of 'loaded specs', whether filtering affects output, or any side effects.
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, front-loaded with key action, no wasted words. Efficiently communicates primary function.
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?
While simple, the description lacks explanation of what 'available operations' means or expected output. No output schema defined, so return value is unspecified.
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 parameter description provided. The tool description adds no additional meaning beyond what the schema already provides, so baseline score 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?
Description clearly states it lists OpenAPI operations across loaded specs, which distinguishes it from domain-specific list tools like bc.list or sdtm.list.
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 on when to use this tool versus alternatives like call_operation or other list tools. Implied context but no explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List dataset specializations specializing a given Biomedical Concept (latest).
| Name | Required | Description | Default |
|---|---|---|---|
| conceptId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior. It mentions 'latest' version but lacks details on pagination, limits, error states, or what 'dataset specializations' entail (e.g., structure, scope). Minimal transparency for a list operation.
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?
One sentence is concise but contains redundancy ('specializations specializing') and could be clearer. Front-loads action, but word choice reduces clarity.
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 simple schema (1 param) and no output schema, description is adequate for basic listing but lacks context on what specializations are, how they relate to concepts, and how this differs from sibling tools. An agent would likely need additional context to use correctly.
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, so description must compensate. It adds 'Biomedical Concept' and 'latest' but does not explain conceptId format, source, or examples. Marginal value over schema, but incomplete.
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 'List', resource 'dataset specializations', and context 'specializing a given Biomedical Concept (latest)'. It distinguishes from sibling tools like sdtm.list or sdtm.get by specifying 'specializations' and '(latest)', but doesn't fully differentiate from similar sibling sdtm.packages.getSpecialization.
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 on when to use this tool vs alternatives like sdtm.packages.getSpecialization or sdtm.domains. Agent must infer from context; missing explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SDTM specialization domains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral context. It only states the action (list) without indicating side effects, read-only nature, or output characteristics. Users cannot infer safety or impact.
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, efficient sentence with no extraneous words. It conveys the core purpose directly.
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?
While the tool is simple (no params), the description lacks output details (e.g., list of domain names or objects). For a listing tool with no output schema, this is adequate but minimal. Could benefit from mentioning expected return format.
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 and 100% schema description coverage (empty schema). The description adds no parameter info, but none is needed. Baseline for 0-param tool is 4.
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 'List SDTM specialization domains' uses a clear verb (list) and specific resource (SDTM specialization domains), distinguishing it from sibling tools like sdtm.get (fetch single) and sdtm.list (likely broader).
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 on when to use this tool vs alternatives. The description provides no context about prerequisites, exclusions, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest SDTM specialization by datasetSpecializationId.
| Name | Required | Description | Default |
|---|---|---|---|
| datasetSpecializationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; description says 'Get latest' but does not explain what 'latest' means, whether the call is idempotent, or any side effects. Minimal behavioral disclosure beyond the basic operation.
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 is concise and front-loaded, but it is under-specified. Could include more context without becoming 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?
For a simple getter with one parameter and no output schema, the description is minimally adequate. However, it lacks details on the meaning of 'latest' and the nature of the specialization, leaving gaps for an AI 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?
Schema description coverage is 0%; the sole parameter datasetSpecializationId is not explained in the description. The parameter name is somewhat self-explanatory but the description adds no additional meaning or format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the latest SDTM specialization by its ID, using specific verb 'Get' and resource 'SDTM specialization'. However, it does not distinguish from sibling tools like sdtm.packages.getSpecialization or sdtm.list.
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 on when to use this tool versus alternatives such as sdtm.list or sdtm.byBiomedicalConcept. No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List latest SDTM dataset specializations (optional domain).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'list latest', implying a read operation, but does not specify whether it requires authentication, how pagination works, what happens with invalid domains, or if it is destructive. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loading the key action. It is concise, but this brevity sacrifices necessary detail. Every sentence should earn its place; here, the sentence is too short to provide adequate 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?
Given the low complexity (one optional parameter) and absence of annotations and output schema, the description should still clarify the output format or behavior. It lacks details on what 'specializations' are, what 'latest' means, and the return type, making it incomplete for an AI 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'optional domain' but does not explain what a domain is, its expected format, or any constraints. For a single parameter, this is insufficient to guide correct parameter construction.
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 latest SDTM dataset specializations' with a verb and resource. It mentions an optional domain filter, which distinguishes it from siblings like sdtm.get (presumably for a single specialization) and sdtm.domains (lists domains). However, 'latest' is ambiguous without context about versioning.
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 on when to use this tool versus alternatives like sdtm.get or sdtm.domains. The description does not include any when-to-use or when-not-to-use information, leaving the agent to infer from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SDTM specialization within a package.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes | ||
| datasetSpecialization | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description does not disclose behavior such as error handling, side effects, authentication requirements, or return value structure.
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?
Extremely concise (one sentence) but lacks necessary detail; under-specification outweighs 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 simple retrieval tool with two required parameters, no output schema, and no annotations, the description is incomplete—missing return format, error cases, and prerequisite context.
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 for parameters, and the description adds no meaning to 'package' or 'datasetSpecialization', leaving the agent to infer from names alone.
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 'Get' and the resource 'SDTM specialization within a package', distinguishing it from sibling 'listSpecializations' which lists all.
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 on when to use this tool versus alternatives like listSpecializations, nor any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SDTM packages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It offers no details on what a 'package' is, whether results are paginated, or any other behavioral traits. This is a minimal description for a list operation.
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 with no wasted words. One sentence is sufficient for this trivial tool, and the structure is front-loaded with the key action.
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 list, the description provides minimal but acceptable completeness. However, the presence of similar sibling tools and lack of output schema specification leaves some ambiguity about what exactly is listed and how the output is structured.
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, so the input schema is fully covered. The description adds no parameter information, which is acceptable since none exist. According to guidelines, baseline for 0 params is 4.
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 'list' and the resource 'SDTM packages', making the tool's primary function obvious. However, it does not differentiate from sibling tools like bc.packages.list or sdtm.packages.listSpecializations, which could cause 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?
No guidance is provided on when to use this tool versus alternatives. The user must infer from the tool name alone, which is insufficient given multiple list tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List SDTM specializations within a package.
| Name | Required | Description | Default |
|---|---|---|---|
| package | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'list' implying read-only, but omits details like pagination, error handling, or what happens if the package does not exist. Limited transparency.
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 no redundant information. Front-loaded with verb and resource, perfectly concise for a simple list operation.
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 low complexity and no output schema or annotations, the description is minimally adequate. It covers the basic purpose but lacks details about return type, error behavior, or additional context that would fully prepare an agent for correct invocation.
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%, and the description does not elaborate on the 'package' parameter. While the name 'package' is somewhat self-explanatory, the description adds no additional meaning or format hints, failing to compensate for the missing schema 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?
Description clearly states action (list), resource (SDTM specializations), and scope (within a package). It distinguishes from sibling tools like sdtm.packages.list (lists packages) and sdtm.packages.getSpecialization (singular get), making 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?
No guidelines provided on when to use this tool vs alternatives (e.g., getSpecialization). No prerequisites or context about package identification are given, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across CDISC Library with paging, facets, and filters.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| start | No | ||
| pageSize | No | ||
| facets | No | ||
| filters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits (e.g., read-only, auth, rate limits, default pagination, or effect of facets). It only lists features without 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?
Single sentence is concise but too brief; lacks structure like sections or examples. Could be longer to add necessary detail 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 five parameters (including a nested object) and no output schema, the description is insufficient. It omits return format, error handling, and how to construct filters effectively.
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%, and description only vaguely references paging, facets, and filters. Parameters like q, start, pageSize, and the nested filters object are not explained. No default values or accepted formats mentioned.
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 it searches across CDISC Library with paging, facets, and filters. This distinguishes it from search.suggest and other tools.
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 on when to use this tool versus alternatives like bc.categories or sdtm.domains. No when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest search terms across CDISC Library.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top | No | ||
| select | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fails to disclose any behavioral traits beyond the tool's name. There are no annotations to compensate, so the agent gains no insight into how suggestions are generated, any restrictions, or side effects. This is a critical gap.
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 short, but it is under-specified rather than concise. It wastes no words but fails to provide essential details, making it inadequate for effective tool understanding.
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 absence of output schema, annotations, and parameter descriptions, the description is entirely incomplete. It does not convey return values, parameter behavior, or usage context, leaving the agent ill-equipped to use the tool correctly.
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 schema description coverage at 0%, the description adds no meaning to the three parameters ('q', 'top', 'select'). The agent receives no explanation of their purposes or expected values, forcing reliance solely on parameter names, which are insufficient.
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 'suggest' and the resource 'search terms across CDISC Library', effectively conveying the main function. However, it does not explicitly differentiate from the sibling tool 'search.query', leaving a slight ambiguity. The purpose is clear but lacks sibling distinction.
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 on when to use this tool versus alternatives, such as the related 'search.query' tool. There are no hints about context-specific usage or exclusions, leaving the AI agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear and distinct purpose. The bc.* and sdtm.* tools are name-spaced to avoid confusion, and other tools like cache.*, call_operation, and search.* are well-separated. No overlapping functionality.
Most tools follow a domain.action or domain.entity pattern with dots (e.g., bc.categories, sdtm.list). However, call_operation and list_operations use underscores instead of dots, introducing a minor inconsistency in separator style.
With 19 tools, the set is well-scoped for a CDISC library API. It covers browsing concepts, SDTM specializations, search, cache management, and generic API operations without being bloated or too sparse.
The toolset covers the main use cases of a library API: browsing (list, get), searching (query, suggest), and managing cache. For a read-only metadata service, missing create/update/delete operations are not gaps. The generic call_operation adds flexibility.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide structured access to ClinicalTrials.gov data for searching, retrieving, and analyzing clin…
ClinicalTrials MCP — wraps ClinicalTrials.gov API v2 (free, no auth)
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
HealthData.gov MCP — wraps HealthData.gov CKAN API (free, no auth)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cicatriiz/cdisc-library-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server