Skip to main content
Glama

check_ctd_completeness

Identifies gaps in a list of CTD sections by comparing them against required sections for NDA, BLA, or MAA submissions in modules 3, 4, or 5.

Instructions

Check a list of provided CTD sections against required sections and identify gaps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
provided_sectionsYesList of CTD sections already prepared
submission_typeYesTarget submission type: 'NDA', 'BLA', or 'MAA'
moduleYesWhich module to check: '3', '4', or '5'

Implementation Reference

  • src/index.ts:285-297 (registration)
    Registration of the 'check_ctd_completeness' tool in the ListToolsRequestSchema handler, defining its name, description, and inputSchema (provided_sections, submission_type, module).
    {
              name: "check_ctd_completeness",
              description: "Check a list of provided CTD sections against required sections and identify gaps.",
              inputSchema: {
                          type: "object",
                          properties: {
                                        provided_sections: { type: "array", items: { type: "string" }, description: "List of CTD sections already prepared" },
                                        submission_type: { type: "string", description: "Target submission type: 'NDA', 'BLA', or 'MAA'" },
                                        module: { type: "string", description: "Which module to check: '3', '4', or '5'" }
                          },
                          required: ["provided_sections", "submission_type", "module"]
              }
    },
  • Core handler function for 'check_ctd_completeness'. Parses arguments, looks up CTD_MODULES data, calculates provided vs missing sections using prefix matching, computes a completeness score percentage, and returns a formatted result.
    if (name === "check_ctd_completeness") {
            const { provided_sections, submission_type, module } = z.object({ provided_sections: z.array(z.string()), submission_type: z.string(), module: z.string() }).parse(args);
            const moduleData = CTD_MODULES[module];
            if (!moduleData) return { content: [{ type: "text", text: "Module " + module + " not found." }] };
            const allRequired = Object.keys(moduleData.sections);
            const missing = allRequired.filter(s => !provided_sections.some(p => p.startsWith(s) || s.startsWith(p)));
            const provided = allRequired.filter(s => provided_sections.some(p => p.startsWith(s) || s.startsWith(p)));
            const score = Math.round((provided.length / allRequired.length) * 100);
            return { content: [{ type: "text", text: "# CTD Module " + module + " Completeness Check\n**Submission:** " + submission_type + "\n**Score:** " + score + "%\n\n**Provided (" + provided.length + "):**\n" + provided.map(s => "- " + s + ": " + moduleData.sections[s]).join("\n") + "\n\n**Missing (" + missing.length + "):**\n" + missing.map(s => "- " + s + ": " + moduleData.sections[s]).join("\n") }] };
    }
  • The CTD_MODULES constant defining all CTD module data (sections and descriptions) used by the handler to determine required sections for modules 1-5.
    const CTD_MODULES: Record<string, { title: string; sections: Record<string, string>; submissionType: string[] }> = {
        "1": {
              title: "Regional Administrative Information",
              sections: {
                      "1.1": "Comprehensive Table of Contents",
                      "1.2": "Application Forms",
                      "1.3": "Product Information (PI / SmPC / Package Insert)",
                      "1.4": "Information about the Experts",
                      "1.5": "Specific Requirements for Different Types of Applications",
                      "1.6": "Environmental Risk Assessment",
                      "1.7": "Information relating to Pharmacovigilance",
                      "1.8": "Information relating to Clinical Trials (EudraCT)",
                      "1.9": "Information relating to Paediatrics",
                      "1.10": "Information about Pharmacovigilance System",
                      "1.11": "Summary of the Risk Management System"
              },
              submissionType: ["NDA", "BLA", "MAA", "JNDA"]
        },
        "2": {
              title: "Common Technical Document Summaries",
              sections: {
                      "2.1": "CTD Table of Contents",
                      "2.2": "CTD Introduction",
                      "2.3": "Quality Overall Summary (QOS)",
                      "2.4": "Nonclinical Overview",
                      "2.5": "Clinical Overview",
                      "2.6": "Nonclinical Written and Tabulated Summaries",
                      "2.7": "Clinical Summary"
              },
              submissionType: ["NDA", "BLA", "MAA", "JNDA"]
        },
        "3": {
              title: "Quality",
              sections: {
                      "3.1": "Table of Contents of Module 3",
                      "3.2.S": "Drug Substance (API)",
                      "3.2.S.1": "General Information (nomenclature, structure, properties)",
                      "3.2.S.2": "Manufacture (manufacturer, process, controls, validation)",
                      "3.2.S.3": "Characterisation (structure elucidation, impurities)",
                      "3.2.S.4": "Control of Drug Substance (specifications, methods, validation)",
                      "3.2.S.5": "Reference Standards or Materials",
                      "3.2.S.6": "Container Closure System",
                      "3.2.S.7": "Stability",
                      "3.2.P": "Drug Product (Finished Product)",
                      "3.2.P.1": "Description and Composition",
                      "3.2.P.2": "Pharmaceutical Development",
                      "3.2.P.3": "Manufacture",
                      "3.2.P.4": "Control of Excipients",
                      "3.2.P.5": "Control of Drug Product (specifications, methods, validation)",
                      "3.2.P.6": "Reference Standards or Materials",
                      "3.2.P.7": "Container Closure System",
                      "3.2.P.8": "Stability",
                      "3.2.A": "Appendices",
                      "3.2.R": "Regional Information"
              },
              submissionType: ["NDA", "BLA", "MAA", "JNDA"]
        },
        "4": {
              title: "Nonclinical Study Reports",
              sections: {
                      "4.1": "Table of Contents",
                      "4.2.1": "Pharmacology (primary, secondary, safety pharmacology)",
                      "4.2.2": "Pharmacokinetics (absorption, distribution, metabolism, excretion)",
                      "4.2.3": "Toxicology (single/repeat dose, genotoxicity, carcinogenicity, reproductive)"
              },
              submissionType: ["NDA", "BLA", "MAA", "JNDA"]
        },
        "5": {
              title: "Clinical Study Reports",
              sections: {
                      "5.1": "Table of Contents",
                      "5.2": "Tabular Listing of All Clinical Studies",
                      "5.3.1": "Reports of Biopharmaceutic Studies",
                      "5.3.2": "Reports of Studies Pertinent to Pharmacokinetics",
                      "5.3.3": "Reports of Human PK Studies",
                      "5.3.4": "Reports of Human PD Studies",
                      "5.3.5": "Reports of Efficacy and Safety Studies",
                      "5.3.6": "Reports of Post-marketing Experience",
                      "5.3.7": "Case Report Forms and Individual Patient Listings"
              },
              submissionType: ["NDA", "BLA", "MAA", "JNDA"]
        }
    };
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the full burden falls on the description. It does not disclose whether the tool is read-only, has side effects, or requires specific permissions. The description only states the function 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence that conveys the essential purpose without any extraneous words. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 required params, no output schema, and no annotations, the description is too minimal. It does not explain what the tool returns, how it behaves under different submission types or modules, or any error conditions. For a tool that likely produces a gap analysis, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters. The description adds no additional meaning beyond the schema descriptions. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Check' and the resource 'CTD sections', specifying it identifies gaps against required sections. This distinguishes it from sibling tools like check_ich_compliance or map_ctd_section.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 generate_submission_checklist or get_agency_deficiency_guidance. The context signals show multiple related tools, but the description offers no context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pubspro/regsub-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server