用途：帮助操作者在 API 与 API 包进入 Dev Portal 发布或消费者访问环节之前，创建、塑造并排查 Catalog 对象。它专注于 Catalog 就绪诊断与对象建模，不接管 Portal 发布、应用认证或声明式交付流程，只做清晰交接。
主要能力：优先使用共享的 kong-konnect MCP 服务器实时检查 API、版本、规范、文档、实现、包与门户发布；在改配置前先做面向 Catalog 的读取。需要变更时保留仓库既有的声明式工具链：HCL 管理的 Catalog 资源用 terraform-konnect，仓库已用该方式管理 Konnect 工作流时用 kongctl-declarative；仅当真正缺失的是实现或关联服务背后的网关实体配置时才用 deck-gateway。若实时 Konnect 状态重要但 MCP 未连接，应尽早说明并改用用户提供的产物或相邻 CLI/配置来源。
使用方式：先分类操作者真实目标（Catalog 可见且正确、Portal 可发布、可通过注册或应用认证消费、编码进声明式工具链），非 Catalog 就绪则尽早交接。再定位第一个真正缺失的 Catalog 对象（API 本身、版本、有效规范或生成文档、API 文档或页面结构、网关实现链接、API 包、应在 Catalog 就绪后发生的门户发布）。随后确认 API 身份与版本模型（名称、当前版本、slug 或 URL 身份、单 API 多规范版本还是按主版本拆分）。检查规范与文档就绪度（规范是否存在、版本是否匹配、验证问题是否理解、文档页面 slug 父页面与状态是否匹配），无效但被接受的规范视为降级输入。仅当消费依赖实现时检查实现与服务链接。涉及 API 包时区分发布单个 API 还是包、哪些操作属于包、边界是业务面向还是纯技术。Catalog 就绪明确后再交接给 konnect-api-publish、konnect-app-auth 或声明式工具技能。
适用场景：Catalog 就绪性、API 版本与规范质量、文档与元数据对齐、包与实现边界、网关服务链接等诊断。
限制：不处理 Portal 发布、应用认证或网关配置变更；Catalog 就绪与 Portal 发布相关但不相同；API 版本、规范版本与 slug 身份可能各自漂移；开发者自助依赖实现链接而非仅 API 对象存在；包不能修复混乱的底层 API 模型。具体命令与配置细节暂未提供。