Student assignment: build an MCP server that bridges the STH REST API with AI coding assistants (Claude, Cursor, Copilot, Codex). The MCP server exposes STH specifications as queryable tools so LLMs can search, retrieve, and create specs programmatically. This epic tracks the STH-side API work and the corresponding MCP server features needed to support AI-driven specification management. ## Background - Student assignment kick-off and planning: - semantic-treehouse/project-management#402, - semantic-treehouse/project-management#409, - semantic-treehouse/project-management#430, - semantic-treehouse/project-management#443 - Initial external API setup by supervisor: [!825](https://gitlab.com/semantic-treehouse/semantic-treehouse/-/merge_requests/825) - MCP server repo: https://gitlab.com/semantic-treehouse/sth-mcp-server ## Scope - External API endpoints in `backend/src/Controller/External/Latest/` for read and write operations on specifications - MCP server tools and resource registry changes to consume these endpoints ## Milestones ### Milestone 1a: Production-ready MCP server Make the MCP server deployment-ready - Integrate repository (couple CI w/ existing configuration) - Deploy MCP app through Kubernetes deployment (sse) - Bonus: Add CD - Bonus: Package app to run standalone (stdio) ### Milestone 1b: Support user-scoped API access API access to STH resources is currently on very bleeding edge; properly support it throughout the platform - Add fine-grained access control to API endpoints, where applicable - Add option for users to let machines (MCP Server) authenticate with the platform on their behalf - Publish versioned API endpoints for accessing (reading) STH resources - Bonus: API specifications ### Intermediate: Dissemination The MCP server can now be used by the general public - Pilot in key environment - Blogpost ### Milestone 2: Improve STH––MCP interface - Improvements on the read interface (some issues attached) - Add new specification types (read-only first) - Implementing create/update interface, research implications of that (how to prevent ensloppification of platform?) - Validator tool: validate message instances against configured specs (calls existing `/api/evalidator/` endpoints) - Cross-assistant testing (Cursor, Copilot, Codex) ### Milestone 3: Ontology-driven message model wizard LLM creates message models grounded in existing ontologies, using the STH wizard workflow. - Expose wizard workflow via External/Latest API - Inspect ontology class properties, add selected properties to message model - Export to XSD/JSON Schema/SHACL/OpenAPI - Multi-ontology support ### Milestone 4: Broader coverage - Ontology/taxonomy write support (Turtle/RDF import) - Validator configuration via MCP (SyntaxBinding setup, Schematron upload) - Expose other STH functionalities (e.g. exports, transformations) through API endpoints and MCP tools (two separate goals)