{"applicationHumanReadableId":"CRRI2564-T28613","applicationDetails":{"applicationHumanReadableId":"CRRI2564-T28613","applicationType":"New gTLD","primaryString":{"aLabel":"mcp","uLabel":""},"tldVariants":[],"originalTldVariants":[],"tldTypes":["Community"],"priorityNumber":-1,"applicationStatus":"Active","processingStage":"Pre-Evaluation Processing","hasClarifyingQuestions":false,"hasChangeRequests":false,"hasObjections":false,"lastPublishedAt":"2026-10-07T15:32:58.350Z"},"questionAndResponses":{"applicationHumanReadableId":"CRRI2564-T28613","sections":[{"displayOrder":1,"sectionId":"1","sectionTitle":"Applying Entity Information","sectionInstructions":"This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.","questions":[{"displayOrder":1,"questionText":"AGB Q1. Full Legal Name","instructions":"Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.","responseText":"Charleston Road Registry Inc.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q2. Doing Business As ","instructions":"Provide the name under which the applying entity is doing business, if different from the full legal name answered in Question 1. Such a name must be registered with appropriate local jurisdiction or public authority.","responseText":"Google Registry","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q3. Legal Entity Form/Business Structure","instructions":"Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.","responseText":"Corporation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q4. Jurisdiction","instructions":"The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include \"Delaware\", \"Germany\", etc.","responseText":"Delaware","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q10. Website URL","instructions":"Provide the website URL of the applying entity, if available.","responseText":"https://registry.google","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":11,"questionText":"AGB Q11. Is the applying entity an existing registry operator, ICANN accredited registrar, or an Affiliate of either?","instructions":"1. Choose Yes or No. \n2. Use the definition of Affiliate from the Base Registry Agreement (see  https://www.icann.org/en/registry-agreements/base-agreement).","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":12,"questionText":"AGB Q12. If \"Yes\", explain.","instructions":"1. Specify if the applying entity is an existing registry operator, ICANN accredited registrar, and/or an Affiliate of a registry operator and/or registrar.\n2. If the applying entity is an Affiliate, provide the details of such Affiliate relationship, including the name of the affiliated registry operator and/or registrar.\n3. If the applying entity is an ICANN accredited registrar, specify the registrar ID number.","responseText":"Applying entity is an existing registry operator","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":13,"questionText":"AGB Q13. Is the applying entity a back-end registry service provider (RSP), an ICANN-approved data escrow agent, an emergency back-end registry operator, a Uniform Rapid Suspension (URS) service provider, an ICANN dispute resolution service provider, a Privacy or Proxy Service Provider, or a Reseller?","instructions":"Choose Yes or No.","responseText":"false","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q17. Phone Country Code","instructions":"","responseText":"1","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":18,"questionText":"AGB Q18. Primary Business Phone","instructions":"Provide the primary business phone number without including the country code.","responseText":"650 253 0000","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q19. Primary Business Email Address","instructions":"Provide the primary business email address of the applying entity.","responseText":"registry-application@google.com","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q20. Address Line 1","instructions":"Enter the street address (no PO Box).","responseText":"Google Registry","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":21,"questionText":"AGB Q21. Address Line 2","instructions":"","responseText":"111 8th Avenue, 5th Floor","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q22. Locality","instructions":"Enter the city, village, municipality, etc.","responseText":"New York","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q23. State/Province/Region","instructions":"Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.","responseText":"New York","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":24,"questionText":"AGB Q24. Postal Code","instructions":"1. Enter the postal code, if applicable.\n2. If a postal code does not exist, type “Not Applicable”. ","responseText":"10011","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q25. Country Code of Location","instructions":"","responseText":"US","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":26,"questionText":"AGB Q26. Full Legal Name","instructions":"If applicable, provide the full legal name as it appears on the official registration documents of the Direct Parent Company of the applying entity. Do not use abbreviations. ","responseText":"Google LLC","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":27,"questionText":"AGB Q27. Doing Business As","instructions":"Provide the name under which the Direct Parent Company is doing business, if different from the full legal name answered in Question 26. Such a name must be registered with appropriate local jurisdiction or public authority.","responseText":"Google","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":28,"questionText":"AGB Q28. Legal Entity Form/Business Structure","instructions":"Provide the long form (no acronyms) of the legal entity form/business structure of the Direct Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.","responseText":"Limited Liability Corporation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":29,"questionText":"AGB Q29. Jurisdiction","instructions":"The jurisdiction indicates the location in which the business of the Direct Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include \"Delaware\", \"Germany\", etc.","responseText":"Delaware","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":36,"questionText":"AGB Q36. Full Legal Name","instructions":"If applicable, provide the full legal name as it appears on the official registration documents of the Ultimate Parent Company of the applying entity. Do not use abbreviations. \"Ultimate Parent Company\" means, with respect to an Applicant (and, if applicable, a Direct Parent Company), the top-level entity that directly or indirectly possesses the power to direct the management and policies of such Applicant (and, if applicable, a Direct Parent Company) through the ownership of voting securities, as a general partner, as a managing member, by contract, or otherwise. An Ultimate Parent Company is not controlled by any other entity. If there are no intermediary entities between the Applicant and the Ultimate Parent Company, the Ultimate Parent Company would be the same entity as the Direct Parent Company.","responseText":"Alphabet Inc.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":37,"questionText":"AGB Q37. Doing Business As","instructions":"Provide the name under which the Ultimate Parent Company is doing business, if different from the full legal name answered in Question 36. Such a name must be registered with appropriate local jurisdiction or public authority.","responseText":"Alphabet","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":38,"questionText":"AGB Q38. Legal Entity Form/Business Structure","instructions":"Provide the long form (no acronyms) of the legal entity form/business structure of the Ultimate Parent Company as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation.","responseText":"Corporation","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":39,"questionText":"AGB Q39. Jurisdiction","instructions":"The jurisdiction indicates the location in which the business of the Ultimate Parent Company is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the Direct Parent Company is registered. Examples include \"Delaware\", \"Germany\", etc.","responseText":"Delaware","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"sectionId":"1","sectionTitle":"Applying Entity Background and Organization","sectionInstructions":"This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.","questions":[{"displayOrder":1,"questionText":"AGB 104. List all directors of the applying entity.","instructions":"","responseText":"Kenneth Yi","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB 105. List all officers & partners of the applying entity.","instructions":"","responseText":"Kenneth Yi, Robert E. Andreatta, Halimah  DeLaine Prado","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB 106. List all Material Shareholders","instructions":"","responseText":"Google LLC","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB 108. Disclose Ultimate Control of applying entity","instructions":"","responseText":"Alphabet Inc.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"sectionId":"6","sectionTitle":"Self-Certification","sectionInstructions":"Provide a single document for Self-Certification question Q2.2-1.\r\nThe document must include only the SC2.2-1.1, SC2.2-1.2, or SC2.2-1.3 statements.\r\nDo not modify any of the Self-Certification statements.","questions":[{"displayOrder":1,"questionText":"AGB Q199. Q2.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO, and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE) of the applying entity, the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant:\nSC2.2-1.1 - As of the submission date of the application, the applying entity is a current registry operator or an affiliated entity of a current registry operator with one or more active Registry Agreements (RA). \nSC2.2-1.2 - The applying entity and/or a QPE will fund the startup and long-term operation of all of the applying entity’s current gTLDs and applied-for gTLD strings.\nSC2.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.","instructions":"1. Provide a single document for Self-Certification question Q2.2-1.\n2. The document must include only the SC2.2-1.1 through SC2.2-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. If the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC2.2-1.1 through SC2.2-1.3 statements.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":5,"sectionId":"7","sectionTitle":"Operational/Planning","sectionInstructions":"The document for Q2.3.1 must be a PDF.\r\nThe document for Q2.3-2 must be an Excel (.xlsx) file.","questions":[{"displayOrder":1,"questionText":"AGB Q200. Q2.3-1 - Provide a document with a list of all of the applying entity’s current gTLDs and a list of all gTLDs for entities affiliated with the applying entity (if applicable).","instructions":"The document for Q2.3-1 must be a PDF.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"sectionId":"8","sectionTitle":"Security Policy and Planning","sectionInstructions":"Provide a single document for Self-Certification question AGB Q220, Q5.1-1.\r\nThe document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.","questions":[{"displayOrder":1,"questionText":"AGB Q220. Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:\nSC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services.\nSC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent).  The security program must be in place prior to delegation, and exist through at least the period of the registry agreement.\nSC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.","instructions":"1. Provide a single document for Self-Certification question Q5.1-1.\n2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements.\n3. Do not modify any of the Self-Certification statements.\n4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"sectionId":"9","sectionTitle":"DNS Abuse","sectionInstructions":"Provide a single document for Self-Certification question AGB Q221, Q5.2-1.\r\nThe document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\r\nDo not modify any of the Self-Certification statements.\r\nIf the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.","questions":[{"displayOrder":1,"questionText":"AGB Q221. Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant:\nSC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD.\nSC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies.\nSC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6).\nSC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate.\nSC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone.\nSC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse.\nSC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.","instructions":"1. Provide a single document for Self-Certification question Q5.2-1.\n2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements.\n3. Do not modify any of the Self-Certification statements.\n4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements,  provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.","responseText":"","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"sectionId":"16","sectionTitle":"Primary String","sectionInstructions":"This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.","questions":[{"displayOrder":4,"questionText":"AGB Q118. What is the meaning/definition of the applied-for gTLD string?","instructions":"Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state \"No English Translation\"","responseText":"The applied-for string, 'mcp', is an acronym for the Model Context Protocol, an open source standard that enables secure, standardised context integration between artificial intelligence models and data sources.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q119. Script of String","instructions":"If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)","responseText":"Latin","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q120.  Phonetic Representation","instructions":"Provide a representation of the string according to the International Phonetic Alphabet.","responseText":"/ˌɛm.siːˈpiː/","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q121. As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.","instructions":"Confirm the statement using a checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q133. What is the mission and purpose of the applied-for gTLD?","instructions":"1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose.\n\n1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose.\n\n2. Explain how this purpose is sustainable over time.","responseText":"Mission and Purpose: Charleston Road Registry (CRR), a company wholly owned by Google, provides registry services to the public. Google is a technology leader focused on improving how millions of users connect with information. In line with Google’s mission, we make information accessible by extending the utility of the Domain Name System while enhancing the performance, security, and stability of the Internet. This applied-for gTLD provides community members greater ability and security in categorizing their online AI interoperability, securely managing their digital presence, and offering a highly recognized web space to the public. The primary purpose of the applied-for gTLD is to provide a dedicated, recognizable, and trusted space that serves the clearly delineated Model Context Protocol (MCP) community. Towards that end, CRR is proposing a registration policy that has been reviewed and endorsed by LF Projects, LLC, the Agentic AI Foundation (AAIF), and Anthropic. CRR is wholly owned by Google, itself an MCP stakeholder and AAIF platinum member, and is a technology leader focused on improving how millions of users connect with information; CRR’s involvement enhances the TLD’s mission and purpose.\n\nIntended Registrants and Users: Charleston Road Registry intends to operate the applied-for gTLD as a community-based registry, operating exclusively for the benefit of the open Model Context Protocol community ecosystem. The goal is to allow ecosystem participants to comprehensively manage their domain space for community-related offerings. Registration will be restricted under a Registration Policy, and only verified community members will be authorized to register domains in accordance with such Policy. The intended registrants include AI developers, technology partners such as AAIF, The Linux Foundation, Anthropic, and other recognized contributors to the MCP ecosystem. The intended users of the applied-for gTLD are the general Internet public and enterprises who will navigate to these domains to securely access Model Context Protocol tools, documentation, and resources.\n\nRelated Activities: The applied-for gTLD will provide community members with the ability to customize their domain names to signal to Internet users the precise, verified nature of their domains. The specialization goal of the applied-for gTLD is to extend the trusted Model Context Protocol community identity to each dedicated second-level domain space. This provides a centralized mechanism by which verified organizations can easily link their diverse initiatives, allowing them to actively manage their digital presence and coordinate the introduction of web spaces for AI integration services. Launching the applied-for gTLD will generate increased competition in the online marketplace by adding incremental availability to the domain pool. The applied-for gTLD will spur further innovation by providing an accelerated platform for the seamless introduction of new community offerings and enhanced branding.\n\nSustainability Over Time: Charleston Road Registry will strive to provide the highest level of user experience through operational stability, security, and performance for the applied-for gTLD. This purpose is highly sustainable over time due to Google's long-term corporate standing, continuous investment, and robust technical infrastructure. We are uniquely positioned to provide this experience given our relationship with Google; Google invests heavily in IT infrastructure and maintains a record of excellence in operations. Google runs one of the largest DNS system globally, maintains industry-leading uptime, and offers enterprise services on which governments depend. Google keeps speed, reliability and scale in mind with each new service, ensuring ongoing stability for the registry's lifetime. Google is well-financed and committed to maintaining Charleston Road Registry, ensuring operation of the TLD remains viable, relevant, and fully funded.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q116. Applied-for Primary String (ASCII Label)","instructions":"","responseText":"mcp","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":10,"sectionId":"5","sectionTitle":"Community","sectionInstructions":"This question set collects information specific to Community gTLDs. However, question 133 (Mission & Purpose) must be answered by all applying entities.","subsections":[{"displayOrder":1,"subsectionTitle":"General","questions":[{"displayOrder":2,"questionText":"AGB Q132. What community will the applied-for string serve?","instructions":"1. Provide the name of the community that the applying entity is committing to serve. \r\n2. Describe the distinct aspects of the community.","responseText":".mcp will service the Model Context Protocol (MCP) community of open-source contributors, developers, operators, and organisations in the Agentic AI Foundation (AAIF) working to define frameworks, standards, and collaborations guiding agentic AI forward.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q134. How would you categorize your community?","instructions":"Enter a category that best describes your community. Some examples of community categories could include, but are not limited to: activity-based and volunteer groups, online or social media groups, religious or political groups, diasporic communities, linguistic communities, celebrity or sports team supporters.","responseText":"The Model Context Protocol (MCP) community is best categorised as a highly technical, activity-based, open source software developer and industry-wide technology ecosystem. The community is united by a shared, active pursuit: the collaborative development, deployment, and standardisation of the open Model Context Protocol.\n\nThe community is clearly delineated and comprises four main, verifiable categories of members:\n\n1) Project Contributors: Developers, programmers, and software engineers with a documented history of technical contributions to the official Model Context Protocol open source project. These contributions include code commits, pull requests, technical documentation, or core specification development, all of which are public and verifiable via official GitHub repositories.\n\n2) MCP Server Operators: Individuals and organisations that manage, host, and operate active MCP servers. These operators demonstrate strict technical compliance with the official, current MCP specification.\n\n3) Registry-Listed Entities: Registered owners or authorised representatives of active MCP servers and developer tools that are officially catalogued in the public MCP Registry maintained by the Model Context Protocol project.\n\n4) Agentic AI Foundation (AAIF) Members: Members in good standing of the AAIF - an industry consortium established to define the frameworks, standards, and collaborations that will guide agentic AI forward. These members are subject to the AAIF Charter and other AAIF policies.\n\nBy operating within these distinct, activity-based categories, community members collaborate to establish a secure, semantic, and highly interoperable namespace.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":1,"questionText":"AGB Q131. Is this application for a community TLD?","instructions":"","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":2,"subsectionTitle":"Organization","questions":[{"displayOrder":3,"questionText":"AGB Q135. What is the applying entity's connection to the community?","instructions":"Describe and provide evidence of the relationship between the applying entity and the identified community.","responseText":"The applying entity, Charleston Road Registry Inc. (CRR), is an American company wholly owned by Google LLC, whose ultimate parent company is Alphabet Inc. Google is a core technical stakeholder, active co-developer, and major industry sponsor within the Model Context Protocol (MCP) community. It is a platinum member of the AAIF, the organization that supports the Model Context Protocol project. Rather than acting as a detached registry service provider, CRR’s connection to the community is organic, direct, and technically integrated through Google's substantial contributions to the ecosystem.\n\nCRR’s connection to the MCP community is built upon three primary pillars:\n\nTechnical and Administrative Endorsement: \nCRR is applying to operate the applied-for gTLD with the explicit, formal written support of the Agentic AI Foundation (AAIF), a directed fund of The Linux Foundation (LF), along with LF Projects, LLC (LFP) - the neutral administrative host and supporting organization for the Model Context Protocol, formally organized under Model Context Protocol a Series of LF Projects, LLC (MCP), and Anthropic - the creator of the Model Context Protocol. This collaborative alignment ensures that the operation of the applied-for gTLD remains strictly in the best interests of the open source developer ecosystem.\n\nOperational Rationale (Security and AI Safety): \nThe technical purpose of this application is to solve a critical infrastructure challenge within the AI development community. Currently, AI models locate MCP servers via traditional, complex, and unstandardised web URLs. CRR will leverage Google Registry’s infrastructure to establish a preloaded HSTS namespace for the applied-for gTLD. This allows host machines and AI agents to utilise semantic, cleanly structured lookups (such as weather.mcp or postgres.mcp) to verify that the host complies with strict AI safety, cryptographic certification, and machine-to-machine transport-layer authentication protocols.\n\nEnforcement of Community Standards: \nIn complete alignment with community leadership, CRR has committed to a binding Specification 12 Community Registration Policy. CRR will neutrally administer the applied-for gTLD to restrict registrations exclusively to verified open source contributors, active server operators, listed registry entities, and members in good standing of the Agentic AI Foundation (AAIF), preventing the namespace from being hijacked, warehoused, or abused.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q136. How is the community organized? Are there one or multiple organizations (\"organizing body\") that represent or administer the community?","instructions":"Describe and provide evidence related to the community organization, any relevant organizing bodies, and any relevant leaders within the community.","responseText":"The Model Context Protocol (MCP) community operates under a structured, and neutral multi-stakeholder governance model administered by recognized industry-leading bodies and open source foundations:\n\nNeutral Governance: Agentic AI Foundation (AAIF), a directed fund of The Linux Foundation (LF), along with LF Projects, LLC (LFP) are the neutral administrative host and supporting organization for the Model Context Protocol, formally organized under Model Context Protocol a Series of LF Projects, LLC (MCP). As the official governing host of the Model Context Protocol project since it was contributed by Anthropic in December 2025, MCP provides open source administrative oversight, and is backed by AAIF, which supports the MCP community globally and manages community outreach and events. It ensures the protocol remains a neutral, open specifications unencumbered by proprietary interests.\n\nAnthropic (Protocol Creator): Anthropic created the Model Context Protocol and released it as an open standard in November 2024. In December 2025, Anthropic contributed MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, and continues to contribute to MCP through the AAIF.\n\nThe coexistence of these highly established, global organising bodies provides an independent administrative structure, formalises community participation, and guarantees that the community's pursuits are enduring, neutral, and sustainable over time.\n\nLF Projects, LLC, AAIF, and Anthropic have provided written support of this Community application.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q137. Does the community have defined membership requirements, such as registration, licensing, or use of specific communication? Or, do community members self-identify as part of the community? ","instructions":"1. Describe any formal membership process, if there is one.\r\n2. If there is no formal membership process, provide evidence related to how an individual can join the identified community (i.e., “self-identify” as a community member).","responseText":"The Model Context Protocol (MCP) community comprises both formal membership structures and structured, objectively verifiable self-identification pathways. Because the community is built around an open-source, multi-stakeholder artificial intelligence specification, participation is open to any individual or organisation that actively contributes to or implements the protocol, yet remains clearly delineated through public and verifiable technical benchmarks.\n\n1. Structured Self-Identification via Technical Benchmarks - The vast majority of the community’s active members - namely software developers, open source contributors, and system operators - self-identify as part of the community through their voluntary participation in the protocol's development and implementation. This self-identification is not merely subjective, but is verified through objective, publicly reviewable mechanisms:\n\na) Open Source Contribution: Developers \"join\" the project contributor segment by submitting code commits, pull requests, bug reports, or core specification documentation to the official MCP open source repositories. These contributions are publicly tracked and verifiable via GitHub or other official project code hosting platforms.\n\nb) Protocol Implementation and Server Operation: Software engineers and organisations self-identify by developing and operating active, compliant MCP servers. To be recognised as an eligible registrant in the applied-for gTLD, these operators must demonstrate that their servers comply with the official, current MCP specification.\n\nc) Ecosystem Registry Listing: Individuals and entities can register their MCP-compliant servers, developer tools, or AI integrations in the official, public MCP Registry maintained by the Model Context Protocol project. Listing on this neutral registry provides a transparent record of community involvement.\n\n2. Formal Membership Structures - In addition to self-identified technical participants, the community is anchored by formal membership organisations that provide administrative, legal, and operational oversight:\n\nAgentic AI Foundation (AAIF): The AAIF, a directed fund of The Linux Foundation, is a structured, formal industry association dedicated to safe AI-to-machine interface standardisation. Joining the AAIF requires signing a membership agreement, which includes a commitment to follow the organization’s formal charter, adhering to established code-of-conduct guidelines and other policies, and paying dues, which establishes a legally-defined category of community members in good standing. AAIF, along with LF Projects, LLC (LFP) are the neutral administrative host and supporting organization for the MCP community (since its contribution in 2025), formally organized under Model Context Protocol a Series of LF Projects, LLC.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q138. Where is the community located?","instructions":"Provide the primary location of the community.","responseText":"Located globally, primarily within decentralised digital spaces such as GitHub, developer forums, and open source communication channels, as well as the global office locations of contributing technology organisations and software developers.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q139. What is the estimated size of the community? This should take into account any regions listed in Question 138.","instructions":"1. Provide the estimated size of the community. The size should be in number format (e.g., “1,000,000 members”).\r\n2. If the community is divided by group, region, sector, etc., this should include estimated size for each group.","responseText":"MCP community size measured by various metrics: SDK downloads exceed 170M/month and 1B/year. The project has 190k+ GitHub stars and 1,300+ quarterly contributors. The April 2026 North America Dev Summit drew 1,100 attendees representing 457 organisations.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q140. What portion of the community do any organizing bodies represent or administer to?","instructions":"Provide the estimated size of the community that is administered or represented by each relevant organizing body in the identified community.","responseText":"While Model Context Protocol a Series of LF Projects, LLC and the Agentic AI Foundation (AAIF) administers to the entirety of the MCP community, its open source development is intentionally decentralised, allowing anyone globally to participate.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":3,"subsectionTitle":"Engagement","questions":[{"displayOrder":9,"questionText":"AGB Q141. Do the organizing bodies demonstrate active and consistent efforts to engage and connect with the identified community and its members?","instructions":"1. Provide evidence of any documented practices of community efforts to date\r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission: \r\na) Offering support; \r\nb) Sharing information; \r\nc) Responding to specific community needs;\r\nd) Fostering and strengthening relationships within the community.","responseText":"Anthropic established the open MCP specification, and the community (including Google) has since contributed to its evolution.\n\nThe organising bodies administering the Model Context Protocol (MCP) community - specifically LF Projects, LLC (LFP) and the Agentic AI Foundation (AAIF) - demonstrate active, consistent, and documented practices to engage and connect with community members. Across the two years leading up to the submission of this application (2024-2026), these bodies have led ongoing, multi-stakeholder initiatives categorised into four core areas:\n\n1) Offering Support: Organising bodies provide continuous technical support, maintaining open source Software Development Toolkits (SDKs) in Python, TypeScript, and Java. Engineers from Anthropic, Google, and other member organizations contribute to the project’s public open-source repositories.\n\n2) Sharing Information: Clear, open communication is maintained through a public registry of verified MCP servers and tools, which serves as a central discovery directory. Complete technical specifications are publicly available on open-access websites, supplemented by technical blogs, architectural guides, and active developer forums.\n\n3) Responding to Specific Needs: In response to developer demands for secure, standardised context integration pathways, Anthropic released MCP as an open standard, and the community, including Google, has contributed to its development. To address transport-layer security concerns and prevent the malicious hijacking of AI-to-machine endpoints, the Registry Operator will preload the applied-for gTLD in the HTTP Strict Transport Security (HSTS) list.\n\n4) Fostering and Strengthening Relationships The community is built on neutral, collaborative relationships governed by open source principles. Since the Model Context Protocol project joined the LF in 2025, the community’s governance has transitioned to a neutral, multi-stakeholder model, ensuring that the protocol's development remains unencumbered by proprietary interests. The organising bodies coordinate development outreach, host technical workshops and conferences, and collaborate directly with community members to promote cross-industry interoperability and safe AI interface standardisation.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":10,"questionText":"AGB Q142. What is the role of the applying entity in the engagement efforts listed in Question 141?","instructions":"1. Describe whether the applying entity has a role in any of the activities listed in Question 141.\r\n2. If the applying entity does play a role, provide evidence of the applying entity’s role. If the applying entity does not play a role, describe why this is the case.","responseText":"The applying entity, Charleston Road Registry Inc. (CRR), as a wholly owned subsidiary of Google LLC, plays an active role in the community engagement efforts. Rather than acting as a detached registry service provider, CRR and Google will coordinate directly with the primary organising bodies of the Model Context Protocol (MCP) community to support adoption, security, and developer outreach.\n\nCRR's and Google’s active role in the community engagement pillars includes: \n\n1) Offering Support: Google's engineers play a direct role in technical engagement, contributing to MCP core specifications. Google's engineers actively participate in public GitHub repositories, resolving technical bugs, reviewing pull requests, and providing debugging support.\n\n2) Sharing Information: Google drives broad community awareness by publishing technical guides, architectural best practices, and developer blogs on Google platforms. These resources accelerate adoption and standardise semantic interface integrations.\n\n3) Responding to Specific Needs: Google provides an ecosystem of cloud-hosted, fully-managed MCP servers that safely connect AI agents to real-time data and tools without requiring custom integrations. Further, to address developer demands for secure, reliable transport-layer paths, CRR will preload the applied-for gTLD in the HTTP Strict Transport Security (HSTS) list, ensuring secure machine-to-machine connections.\n\n4) Fostering Relationships: Google provides leadership for the MCP community. It is a platinum member of AAIF and has a representative on the Governing Board. \n\nGoogle’s extensive technical resources and direct sponsorship guarantee that the community's pursuits are robustly supported, highly visible, and sustainable over the operational lifetime of the applied-for gTLD.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":4,"subsectionTitle":"Awareness","questions":[{"displayOrder":11,"questionText":"AGB Q143. Are community members aware of the identified community and each other?","instructions":"1. Provide evidence that demonstrates that community members are aware of the identified community and the different member groups or segments within the identified community. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Surveys conducted;\r\nb) Records of activities involving a diversity of community groups, segments, or members.","responseText":"Yes, members of the Model Context Protocol (MCP) community demonstrate a high level of mutual awareness, recognising both the overarching community and the distinct member segments that form the ecosystem. Because the protocol is an open specification, this mutual awareness is preserved and documented through shared public infrastructure, developer indices, and collaborative open source governance.\n\n1) Structural Alignment and Shared Infrastructure - Rather than operating as an unstructured group, members of the MCP community interact and identify each other through standardised technical benchmarks:\n\na) Open Source Collaboration: Software developers and contributors actively collaborate on core specifications and toolkits within the official MCP open source project repositories, tracking contributions publicly via GitHub.\n\nb) Central Registry Indexing: The community maintains an official, public MCP Registry. Developers and server operators register their compliant implementations in this central registry, allowing users and AI agents to discover active tools.\n\nc) Semantic Interoperability: This mutual technical awareness is demonstrated in practice through the deployment of protocol implementations. For example, AI agents and developers can easily identify and connect with specific compliant tools by looking up semantic, cleanly structured hosts.\n\n2) Shared Governance and Strategic Alignment - The transition of the protocol’s administration has formalised and solidified mutual awareness across both commercial and open source stakeholders:\n\na) Neutral Governance Umbrella: Following Anthropic’s creation of the Model Context Protocol in 2024, it moved the project to LF Projects, LLC in 2025 to be supported by Agentic AI Foundation. Agentic AI Foundation (AAIF), a directed fund of The Linux Foundation (LF), along with LF Projects, LLC (LFP) are the neutral administrative host and supporting organization for the Model Context Protocol, formally organized under Model Context Protocol a Series of LF Projects, LLC (MCP) Operating under LF's neutral administrative framework provides the entire ecosystem with a unified, sustainable structure.\n\nb) Corporate and Standardisation Coordination: Industry-wide alignment is further maintained through coordination between leading technical entities and standardisation bodies. \n\nThrough these active registry databases, shared GitHub repositories, and multi-stakeholder governance frameworks, members of the MCP community remain highly integrated, technically aligned, and deeply aware of each other’s active contributions.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":12,"questionText":"AGB Q144. Are community members aware of the applying entity and its intention to apply for a community gTLD?","instructions":"1. Provide evidence of community members’ awareness of the applying entity and its intent to apply for a community gTLD. \r\n2. If there is no such evidence, explain why not.","responseText":"The Agentic AI Foundation, and related entities, The Linux Foundation and LF Projects, LLC as representatives and governing body of the MCP Community are aware of and support the applying entity, Charleston Road Registry Inc. (CRR) and its intention to apply for the applied-for gTLD as a Community gTLD. Anthropic is similarly aware and supportive. Evidence of the community members’ awareness is evidenced by the endorsement letters included in this application. \n\nThis support will be published online following ICANN’s reveal of all gTLD applications.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":5,"subsectionTitle":"Established Presence","questions":[{"displayOrder":13,"questionText":"AGB Q145. Was there an established presence of the identified community prior to the opening of the application submission period?","instructions":"Provide evidence of the established presence of the community prior to the opening of the application submission period.","responseText":"Yes","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":14,"questionText":"AGB Q146. Are individuals and groups outside of the identified community aware of the existence of the identified community?","instructions":"1. Provide evidence that demonstrates that individuals and groups outside of the community show an awareness of the identified community. \r\n2. The applying entity should provide documentation of the following practices, which should have occurred within the two years leading up to application submission:\r\na) Media or other public information regarding the community and its activities or members; \r\nb) Discussion of the community in various fora, whether online or in person; \r\nc) Evidence of partnerships or collaborations with groups outside of the identified community;\r\nd) Evidence of the chartering or organization of the community prior to the opening of the application submission window;\r\ne) Evidence of contributions (for example, cultural or scientific) to a larger society or population;","responseText":"Yes, individuals and groups outside the immediate Model Context Protocol (MCP) developer community demonstrate a clear, documented awareness of the community’s existence and its active technical pursuits. As an open protocol designed to solve critical artificial intelligence connectivity challenges, the community’s established presence is recognised globally by technology organisations, enterprise networks, and standardisation bodies.\n\nTo demonstrate this established presence and external awareness, the community’s organising bodies have documented active practices across five core pillars during the two years leading up to the submission of this application (2024–2026):\n\n1) Media and Public Information regarding the Community - Widespread technical and mainstream media coverage has documented the rapid rise and adoption of the Model Context Protocol since its creation by Anthropic in 2024. Widespread global coverage occurred in late 2025 when Anthropic formally contributed the protocol to the Linux Foundation and LF Projects, LLC (together \"LF\") to establish neutral, open source governance under the Agentic AI Foundation. This landmark contribution was reported by global technology journalists, open source news outlets, and industry commentators, highlighting to the general public that the protocol has become the standard for artificial intelligence data integration. This broad public reporting demonstrates that the community’s activities are highly visible to those outside the immediate development base.\n\n2) Discussion of the Community in Technical Fora - Beyond core developer channels, the protocol is discussed extensively in broader technology, enterprise software, and artificial intelligence forums. It is recognised by enterprise architecture committees, database developers, and web standard groups as a revolutionary framework that replaces messy, proprietary APIs with semantic, cleanly structured lookups. These public discussions demonstrate that IT professionals and corporate decision-makers outside the core development group are highly aware of the community's existence and technical progress.\n\n3) Evidence of Prior Chartering and Organisation - The formal chartering and transition of the protocol to AAIF, LF Projects, LLC, and Model Context Protocol a Series of LF Projects, LLC in 2025 provides concrete, legal proof of the community's established presence. This formal governance structure under a universally recognised, neutral open source foundation ensures that individuals and corporate groups outside the direct developer base can reliably participate in, contribute to, and adopt the protocol under established open source legal frameworks.\n\n4) Technical and Scientific Contributions to a Larger Population - The protocol represents a major scientific and technical contribution to the broader digital society by solving a critical security and interoperability bottleneck. By standardising how AI agents connect safely to data sources, the community has significantly advanced global AI safety, machine-to-machine transport-layer authentication, and public standards for secure artificial intelligence deployment, benefiting the wider Internet population who rely on secure AI integrations.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":6,"subsectionTitle":"Longevity","questions":[{"displayOrder":15,"questionText":"AGB Q147. Are the pursuits of the identified community enduring and sustainable?","instructions":"1. Provide evidence of the longevity of the community. \r\n2. The applying entity should provide documentation of the following practices which should have occurred within the two years leading up to application submission:\r\na) Evidence of recurring or scheduled activities that demonstrate continuity over time;\r\nb) Documented records of past activities that demonstrate a long-standing tradition or practice;\r\nc) Records of discussions emphasizing the community’s enduring presence or its cultural significance.","responseText":"Yes, the pursuits of the Model Context Protocol (MCP) community are enduring, sustainable, and structurally built for long-term growth. This longevity is demonstrated by the protocol’s rapid industry-wide adoption since its creation by Anthropic in 2024, and its transition to the neutral administrative governance of Model Context Protocol a Series of LF Projects, LLC and its supporting organization, the Agentic AI Foundation (AAIF).\n\nTo demonstrate the longevity and sustainability of the community's pursuits, the following practices have occurred within the two years leading up to the submission of this application:\n\n1) Established and Enduring Open Source Governance: Following its initial development in 2024, the protocol transitioned to the neutral, open source stewardship of AAIF in 2025. This transition established a stable, permanent administrative framework designed to scale and add long-term value to the open source developer ecosystem, ensuring the protocol remains free from proprietary lock-in.\n\n2) Recurring and Scheduled Activities: The community participates in continuous, structured collaborations, including ongoing codebase commits, regular software developer kit (SDK) version releases in Python, TypeScript, and Java, and public technical reviews of protocol specifications. This persistent development cycle demonstrates a long-standing technical tradition that will endure over the operational lifetime of the applied-for gTLD.\n\n3) Widespread Enterprise and Industry Endorsement: The longevity of these pursuits is backed by leading technology companies and standardisation bodies. \n\nThis multi-stakeholder support ensures that the MCP community is forward-looking and highly sustainable. Supporting documentation and articles illustrating LF’s established track record of scaling open source communities, alongside the official MCP community charters, are attached to this application to substantiate these pursuits:\n\nThe Model Context Protocol Project Governance: https://modelcontextprotocol.io/community/governance \n\nAgentic AI Foundation Charter: https://github.com/aaif/foundation/blob/main/charter.md\n\nThe Linux Foundation Annual Report: https://www.linuxfoundation.org/hubfs/Publications/2025%20Linux%20Foundation%20Annual%20Report_122225a_lr.pdf","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":7,"subsectionTitle":"Nexus","questions":[{"displayOrder":16,"questionText":"AGB Q148. Does the string match the name of the identified community?","instructions":"Explain how the applied-for string matches the name of the community or is a well-known alternative name (whether long or short form) of the community.","responseText":"Yes, “MCP” is a commonly used acronym for the Model Context Protocol.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":17,"questionText":"AGB Q149. Will the general public instinctively think of the community when thinking of the applied-for string?","instructions":"1. Explain how the applied-for string clearly relates to or represents the community \r\n2. Explain whether the applied-for string has any other significant meaning beyond identifying the community or community members described in the application. The applying entity may wish to provide pertinent information regarding any particular geography, region, or themes that may be alluded to by the string, of which the community may or may not be a part.","responseText":"In today’s agentic online environment, the acronym “MCP” is strongly connected to Model Context Protocol. It is the first result from a Google search of “mcp” (see below). The acronym and protocol itself has become and will continue to be the backbone of modern AI agents, secure enterprise AI systems, and agentic workflows on the DNS.\n\nCRR acknowledges that “mcp” has historically been used as an acronym for other terms, including: Master Control Program (1982 movie Tron), Metacarpophalangeal, Master of Clinical Psychology, Master Cleaning Program, Minor Compromise Petition, Metric Capital Partners, and Microsoft Certified Professional although none of these terms constitute a community as anticipated in the Applicant Guidebook.\n","hasResponseDocuments":true,"hasCr":false,"hasCq":false}]},{"displayOrder":8,"subsectionTitle":"Community Registration Policy","questions":[{"displayOrder":18,"questionText":"AGB Q150. Are you proposing to include one or more Community Registration Policies in the Registry Agreement (RA) that are unique to the applying entity's applied-for community gTLD?","instructions":"Select from Radio Buttons - Yes/No. Notes: 1. Community Registration Policies are conditions that community gTLD registry operators impose upon registrants within their gTLDs. 2. If you select “Yes” to this question, the applying entity is required to pay the conditional Registry Commitments Evaluation fee, and Community Registration Policies that are approved by ICANN will be scored in the CPE (if the applying entity elects to participate) and included in Specification 12 of the applicable Base RA. 3. If you select “No,” then the application cannot proceed as a community application.","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":19,"questionText":"AGB Q151.1. Please state a specific Community Registration Policy with respect to registration eligibility for community members.","instructions":"1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.\n\n2. Enter a single proposed Community Registration Policy with respect to registrant eligibility in each response field. Up to 10 Community Registration Policies can be submitted.\n\n3. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars ,:\na) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose  any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring ___\"; and/or\nb) \"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) Registry Operator shall develop and implement a registration eligibility policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS.\nb) Registry Operator shall review the registration policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date.\n\n7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a registrant eligibility restriction is time-limited, the applying entity must state if the restriction will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).\n\n8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.","responseText":"This Registration Policy (the \"Policy\") sets forth the criteria and requirements for the registration and use of domain names within the .mcp top-level domain (TLD). .mcp is a community-based TLD which will solely serve the Model Context Protocol (MCP) community, including contributors, developers, and operators of MCP-compliant systems. The purpose of .mcp is to provide a dedicated, secure, and recognizable namespace that fosters the growth and interoperability of the MCP ecosystem. The Policy, as adopted by the .MCP Policy Council, including the Community Protection Commitments, will be enforced by the Registry Operator with the assistance of the .MCP Policy Council and may be amended only with the consent of the .MCP Policy Council.\n\nCommunity Protection Commitments\n\nEligibility \nOnly the following types of individuals and organizations are eligible to register domain(s) in .mcp:\n\n1) Project Contributors: documented history of contributions to the official Model Context Protocol open source project, including but not limited to code commits, documentation, extension development or core specification development, verifiable via GitHub or other official project repositories. \n2) MCP Server Operators: operation of an active MCP Server that demonstrates compliance with the current MCP specification. \n3) MCP Registry Listing: registered owner and/or authorized representative of a server listed in the official MCP registry maintained by the Model Context Protocol project.\n4) AAIF Members: members in good standing of the Agentic AI Foundation (AAIF), subject to adherence to the AAIF charter and community compliance standards.\n","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":20,"questionText":"AGB Q152.1. State a specific Community Registration Policy with respect to name selection criteria or rules for the applied-for string.","instructions":"1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Base Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.\n\n2. Enter a single proposed Community Registration Policy with respect to name selection criteria or rules for the applied-for string in each response field. Up to 10 Community Registration Policies can be submitted. \n\n3. These criteria or rules should align with the community objectives of the applied-for gTLD string.\n\n4. Follow this format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n6. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___\"\"; and/or\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting ___\"\".\n\n7. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) Registry Operator shall develop and implement a name selection rule and publish it on its website no later than the date on which the TLD is delegated in the DNS.\nb) Registry Operator shall review the name selection rule described in (a) at least once per year, and publish the results of such review (including any updates to the rule) on its website within thirty (30) days following the anniversary of the Effective Date.\n\n8. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a name selection rule is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).\n\n9. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.","responseText":"Naming Selection \nRegistry Operator shall restrict the selection of second-level domain names such that all registered domain names relate to the registrant's specific Model Context Protocol (MCP) implementation, their MCP service name, or their recognised brand within the developer community. Acceptable domain names must communicate that the registrant's business, service, or API is natively designed to integrate with Large Language Models (LLMs) and agentic artificial intelligence.","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":21,"questionText":"AGB Q153.1. State a specific Community Registration Policy with respect to an additional commitment besides registration eligibility for community members and naming selection criteria or rules for the applied-for string.","instructions":"1. Draft the Community Registration Policy as proposed contract language. Policies that are approved by ICANN will be included in Specification 12 of the applicable Registry Agreement and will be subject to enforcement by ICANN Contractual Compliance. See Appendix 4 Base Registry Agreement, Specification 12 for drafting approach. Consider the usage of defined terms and the definitions of such terms in the 2026 Round Base RA.\n\n2. Enter a single proposed Community Registration Policy in each response field. Up to 10 Community Registration Policies can be submitted.  \n\n3. Follow the format to propose what the Registry Operator must do and/or must not do:\na) “Registry Operator shall___”; and/or\nb) “Registry Operator shall not___”.\n\n4. Follow this format to propose any specific requirement(s) that the Registry Operator commits to include in its Registry-Registrar Agreement for registrars:\na) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall___”; and/or\nb) \"\"Registry Operator will include the following provisions in its Registry-Registrar Agreement: Registrar shall not___”.\n\n5. Follow this format to propose any specific requirement(s) that the Registry Operator commits to require registrars to include in the applicable Registration Agreements:\na) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision requiring___\"\"; and/or\nb) \"\"Registry Operator will include a provision in its Registry- Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting___\"\".\n\n6. Include any objective measures that can be applied to demonstrate the Registry Operator’s compliance with the Community Registration Policy. For example:\na) Registry Operator shall develop and implement a Community Registration policy and publish this policy on its website no later than the date on which the TLD is delegated in the DNS.\nb) Registry Operator shall review the Community Registration Policy described in (a) at least once per year, and publish the results of such review (including any updates to the registration policy) on its website within thirty (30) days following the anniversary of the Effective Date.\n\n7. If the Community Registration Policy is limited in time, duration, scope, or any other factors, specify the applicable limitations. For example, if a commitment is time-limited, the applying entity must state if the rule will apply for the lifetime of the gTLD, only during a specified period, or for some other defined period (such as, Registry Operator shall, for a period of x days from the Effective Date, ___).\n\n8. See Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria for evaluation criteria that ICANN will apply for evaluating each proposed Community Registration Policy.","responseText":"Other Commitments\n\n1) Community Alignment: domain names in the .mcp are strictly limited to hosting MCP related content, services, APIs, or documentation directly related to the MCP ecosystem. General-purpose use unrelated to the MCP protocol, use, or its development is prohibited.\n2) Trademark Usage: Registrants must comply with the MCP trademark policy. Use of domains in .mcp must not imply official endorsement by the Model Context Protocol technical project, AAIF, LF Projects, The Linux Foundation, or Anthropic unless such endorsement exists.\n3) Security Obligations: Registry Operator shall preload .mcp in the HTTP Strict Transport Security (HSTS) list to enforce secure HTTPS-only connections across all active hosts.\n\nPublication \nRegistry Operator shall implement and publish this Policy on its website no later than the date on which the TLD is delegated in the DNS.\n\nRegistrar Obligations\nRegistry Operator shall include requirements in its Registry-Registrar Agreement for registrars offering the .mcp TLD to (i) implement verification processes as approved by and made available by Registry Operator inline with this Policy and (ii) bind registrants to this Policy, that specifically reserve the rights of Registry Operator to suspend, delete or take other action on domain names in .mcp based on violation of this Policy.\n","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":22,"questionText":"AGB Q154. Explain the rationale for any limitations to the Community Registration Policy proposed by the applying entity in Questions 151-153.","instructions":"1. If you are proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please provide a rationale in this response field. Please see Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria.\n2. If you are not proposing any limitation to a proposed Community Registration Policy in Questions 151-153, please type \"\"Not Applicable\"\" in this response field.","responseText":"Not Applicable","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":23,"questionText":"AGB Q155. Explain how the proposed Community Registration Policies of the applying entity meets the Registry Commitments Evaluation criteria 4 and 5?","instructions":"1. Provide an explanation of how the proposed Community Registration Policies meet the Registry Commitments Evaluation criteria 4 and 5 using the considerations in the Section 7.8.3.3 Registry Voluntary Commitments (RVCs) Criteria.\n2. Consider whether the proposed Community Registration Policy could be argued to be duplicative of a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. There may be circumstances in which a Community Registration Policy that would duplicate requirements under applicable consensus policy or law could be approved at ICANN’s sole discretion. If not duplicative, please explain why you believe the Community Registration Policy is not duplicative. If yes, please specify such a requirement and explain why you believe duplication in the Base RA is necessary.\n3. Consider whether the proposed Community Registration Policy could be argued to be contrary to a requirement under applicable law, ICANN agreements, or ICANN Consensus Policies or Temporary Policies. ICANN will not approve any Community Registration Policies that are found to be contrary to applicable laws, ICANN agreements and policies. Please share your views on this issue in the answer to this question.\n4. Consider whether the proposed Community Registration Policy could be argued to be incompatible with ICANN’s Bylaws. ICANN will not approve any Community Registration Policies that are found to be incompatible with the ICANN Bylaws. See background at the ICANN Board resolution 2024.06.08.08-2024.06.08.10. Please share your views on this issue in the answer to this question.\n5. Consider whether the proposed Community Registration Policy requires the operation of an additional Registry Service. The applying entity shall engage its selected RSP to discuss the implementation of such an additional Registry Service, which must be evaluated through the RSP Program and approved by ICANN.","responseText":"The proposed Community Registration Policies for the applied-for gTLD satisfy all requirements under Registry Commitments Evaluation (RCE) Criteria 4 and 5.\n\n1. Compatibility with Criterion 4 (No Duplication or Contradiction of Laws and Agreements) - The eligibility and name selection policies proposed for the applied-for gTLD do not duplicate, nor are they contrary to, applicable national laws, ICANN agreements, consensus policies, or temporary policies.\n\nNo Duplication: \nThese policies are highly specific to the technical and operational parameters of the Model Context Protocol (MCP) open source standard. They do not duplicate general registration obligations already governed by standard ICANN Consensus Policies or the Base Registry Agreement.\n\nNo Contradiction: \nAll criteria rely on objective, publicly verifiable developer and operational benchmarks - such as documented contribution history on GitHub repositories or the active operation of an MCP-compliant server. These rules do not conflict with local jurisdictions or data protection regulations (such as GDPR). Furthermore, they do not commit registry operators or registrars to actions that violate the Registrar Accreditation Agreement (RAA) or any applicable Consensus Policies.\n\n2. Compatibility with Criterion 5 (Compatibility with ICANN's Bylaws and Content Neutrality) - The proposed policies are fully compatible with ICANN's Bylaws, specifically aligning with ICANN’s core technical mission to ensure the stable and secure operation of the Domain Name System.\n\nStrict Content Neutrality: \nUnder its Bylaws, ICANN is prohibited from regulating or enforcing content-based restrictions on the Internet. In complete alignment with ICANN Board directives on content neutrality, these policies are strictly non-content-restrictive.\n\nProcedural and Eligibility Focus: \nRather than regulating the substance of speech or the messages carried by services in the applied-for gTLD, the policies focus entirely on operational, procedural, and technical eligibility (who can register based on verifiable community standing) and structural naming rules (domain names must relate to the registrant's specific MCP implementation, brand, or service).\n\nNo Content Policing: \nOnce an eligible community participant (such as an open source contributor or active server operator) is verified and registers a domain, they are free to deploy their compliant tools and services without any content policing from the registry. Consequently, ICANN will never be put in the position of enforcing content-based restrictions or passing judgment on speech.\n\n3. No Additional Registry Services Required - The execution and enforcement of these Community Registration Policies utilize standardised, automated verification workflows. They are processed entirely within the capabilities of the pre-evaluated Main Registry Service Provider (RSP) and do not require the operation or evaluation of any new or additional technical Registry Services.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":9,"subsectionTitle":"Community Endorsement","questions":[{"displayOrder":24,"questionText":"AGB Q156. From where does the applying entity have the support to run the applied-for string on behalf of the identified community?","instructions":"Please provide evidence of support for the applying entity’s application by attaching written endorsements from the organizing bodies relevant to the identified community (related to Question 136).","responseText":"Charleston Road Registry Inc. (CRR) has secured the formal, written endorsements of the primary organising, governing, and technical bodies that represent and administer the Model Context Protocol (MCP) community. \nThese endorsements demonstrate that a substantial majority of the community’s leadership fully supports CRR’s application to operate the applied-for gTLD for the benefit of the ecosystem.\n\nThe supporting entities include:\n\nAgentic AI Foundation (Neutral Governing Body), a directed fund of The Linux Foundation and LF Projects, LLC (Trademark Owner): As the neutral administrative host and supporting organization for the Model Context Protocol project since December 2025, and the owner of the Model Context Protocol project’s trademarks, AAIF and LF Projects have both formally endorsed CRR’s application. They govern and represent the global open source community to ensure that the ongoing development and maintenance of the protocol remains open and neutral.\n\nAnthropic (Protocol Creator): Anthropic, which created the Model Context Protocol and released it as an open standard in 2024, has provided a letter of support for CRR’s application.\n\nThese organisations represent the absolute majority of the community's leadership, developers, and active users. Operating the applied-for gTLD under the proposed community registration policies ensures a secure, standardised, and highly trusted namespace for the Model Context Protocol ecosystem.\n","hasResponseDocuments":true,"hasCr":false,"hasCq":false},{"displayOrder":25,"questionText":"AGB Q157. Is there any opposition to the applying entity, application, or applied-for string that the applying entity is aware of? If yes, please explain.","instructions":"Provide an explanation of why opposition may or may not be relevant or how the applying entity intends to address or resolve the opposition, if applicable.","responseText":"Charleston Road Registry Inc. (CRR) is not aware of any active, formal, or relevant opposition to this application or to the applied-for gTLD string. CRR is aware that the acronym ‘MCP’ is used by unrelated third parties in other fields. CRR is not aware that any such party intends to apply for the string or to oppose this application.\n","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]},{"displayOrder":13,"sectionId":"2","sectionTitle":"Safeguard Identification","sectionInstructions":"This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.","questions":[{"displayOrder":1,"questionText":"AGB Q164. Will people see a domain name as more trustworthy because it is registered in your TLD?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q165. Is it likely that consumers will face significant risks if domain names in the TLD(s) in the application are abused?\r\nThink about how people around the world will understand the TLD string(s) in the application, including literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":3,"questionText":"AGB Q166. Would people generally think that this TLD will be used by entities that require strict licensing or accreditation to do business?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":4,"questionText":"AGB Q167. Would most people think that (domains in) the TLD(s) in the application are used for activities that require regular government reporting, inspections, and oversight in various countries?\r\nThink about how the TLD string(s) in the application will be understood around the world, including both literal and informal meanings in different languages and regions.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\n2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":5,"questionText":"AGB Q168. Could people reasonably believe that (domains in) your TLD will cause or lead to harassment, harm, aggression, complaints, criticism, distress, or embarrassment?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\r\na. Literally as described in the application\r\nb. Literally in any other language in which the string is a recognized word or phrase.\r\nc. Informally in any language or regional variant, where alternative meanings exist.\r\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":6,"questionText":"AGB Q169. Would most people think that the TLD is used for something usually done by governments?\r\nThink about how the TLD string(s) in the application will be understood globally, including different languages and cultures.","instructions":"1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts:\na. Literally as described in the application\nb. Literally in any other language in which the string is a recognized word or phrase.\nc. Informally in any language or regional variant, where alternative meanings exist.\nI-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q170. Are you proposing to include one or more of the Safeguard Public Interest Commitments (Safeguard PICs) in the Registry Agreement (RA) voluntarily regardless of ICANN’s Safeguard Assessment outcomes?","instructions":"Select Yes or No.\n\nNotes:\n1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA).\n2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs.\n3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).","responseText":"Yes","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":8,"questionText":"AGB Q171. If Yes, which Safeguard PIC(s) are you proposing to include in the RA?","instructions":"Choose the applicable Safeguard PICs from the provided list (more than one option can be selected).","responseText":" • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring registrants to comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures.\n • Registry Operators will include a provision in their Registry-Registrar Agreements that requires registrars at the time of registration to notify registrants of the requirement to comply with all applicable laws.\n • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law.","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":14,"sectionId":"12","sectionTitle":"Registry Voluntary Commitments (RVCs)","sectionInstructions":"This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.","questions":[{"displayOrder":1,"questionText":"AGB Q172. Are you proposing to include one or more Registry Voluntary Commitments (RVCs) in the Registry Agreement (RA) that are unique to your applied-for string?","instructions":"1. Select Yes or No.\n2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs).\n3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer \"yes\" and proceed to answer the following questions.\n4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs).\n\nNotes:\nIf you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":16,"sectionId":"11","sectionTitle":"Brand & Code of Conduct Exemptions","sectionInstructions":"This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).","questions":[{"displayOrder":1,"questionText":"AGB Q179. Are you applying for a Brand TLD?","instructions":"Select Yes or No","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":7,"questionText":"AGB Q185. Does the applying entity request a Code of Conduct Exemption?","instructions":"This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.","responseText":"No","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]},{"displayOrder":17,"sectionId":"13","sectionTitle":"Additional Information and Supporting Materials","sectionInstructions":"This question set collects any additional information that the applying entity would like to provide, including any supporting materials.","questions":[]},{"displayOrder":18,"sectionId":"14","sectionTitle":"Bona Fide Intent and Prohibited Communications","sectionInstructions":"This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.","questions":[{"displayOrder":1,"questionText":"AGB Q223. By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false},{"displayOrder":2,"questionText":"AGB Q224. By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1  Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.","instructions":"Confirm the statement using the checkbox.","responseText":"true","hasResponseDocuments":false,"hasCr":false,"hasCq":false}]}]}}