OLEXI Australian Laws MCP Server

## Requirements checklist (status) - [x] Confirm Independent Publisher certification applies to MCP “connectors” and is feasible. - [x] Clarify whether Step 2 (proposal) is required if the connector is already built (optional, recommended). - [x] Audit compliance with “Prepare connector files for certification”; list gaps. - [x] Produce an actionable plan with owner splits (you vs me), including any manual steps you must do. - [x] Public website live and accurate, vendor‑neutral, endpoint correct (Cloud Run base URL). - [x] Connector manifest prepared with correct endpoint, publisher, icons, privacy. - [x] Docs: README, TESTING, SUPPORT, SECURITY, CHANGELOG, RIGHTS present. - [ ] Optional proposal: draft and submit (recommended to mitigate data‑rights risk). - [ ] Submission PR: assemble package and open PR in Microsoft repo. ## Feasibility: can this MCP be certified as an Independent Publisher connector? - Bottom line: Feasible with caveats. - Microsoft Copilot Studio supports MCP servers (“connectors”) and provides a certification path via the Independent Publisher process alongside Power Platform connectors. Your attached docs (“Prepare Copilot Studio and Power Platform connector files for certification”, “Independent publisher certification process”) indicate MCP connectors are now in scope for certification in Copilot Studio. - Key dependencies to clear: - Data rights: The server scrapes AustLII. We’ll need terms-of-use compliance and (ideally) a documented permission/allowance for redistribution/use via a public connector. This is the biggest risk. - Public hosting: Stable TLS endpoint — Cloud Run endpoint is live and documented. - Required certification artifacts: Manifest and docs are now prepared in `docs/copilot/connector/`. - Confidence: High if data rights are cleared. Otherwise Medium (risk of rejection on IP/terms grounds). ## Step 2 (proposal) clarification - The proposal is recommended but not strictly required if you’re ready to submit. It helps avoid duplication and lets MS flag any policy concerns early (useful given the AustLII data-rights question). Skipping is allowed; however, for risk mitigation, I recommend filing the short proposal issue. ## Compatibility & gaps against “Prepare connector files for certification” What you seem to already have: - Working MCP HTTP server (FastAPI/uvicorn) with tests. - Privacy doc(s): PRIVACY_MCP.md and privacy-mcp.html. - Branding assets: multiple favicons present (we’ll need a 32x32/128x128 square PNG for the connector logo—likely OK). - Deployment scaffolding (Cloud Run YAMLs). What’s likely missing or needs work (to be created/verified): - Copilot connector manifest (YAML/JSON) for MCP, including: - Name, description, categories, auth scheme, server URL, tool list, parameters, and metadata (publisher, support). - Public, stable HTTPS endpoint (production URL), with: - Health endpoint (`/healthz`), CORS config for Copilot, rate limiting policy. - Error schema consistency (structured errors), 4xx/5xx mapping, retries guidance. - Authentication policy: - Either “No auth” (with justification) or API key (recommended), documented with sample/testing credentials for certification. - Documentation set: - README for the connector (purpose, capabilities, setup, auth, limitations). - Sample prompts/queries and expected outputs (deterministic test steps). - Support contact and issue triage policy. - Changelog and versioning info. - Security and data-handling notes (PII stance; what’s logged, retention). - Terms/ToS links for data sources and your connector. - Data rights proof/justification: - Reference to AustLII terms; if needed, a permission letter or clear terms permitting this usage. Include attribution. - Publisher metadata: - Publisher display name, website, email, privacy policy URL, icon license. Nice-to-have but strengthens approval: - Basic usage telemetry ON/OFF toggle and disclosure. - SLA/uptime statement and throttling policy. - Verified domain (DNS) for the public endpoint. ## Plan to certification (owner-split and sequence) Phase 0 — Confirm path and risks (You) - Confirm you want the Independent Publisher route (vs. private/internal). - Validate AustLII usage: provide their ToS link and, if required, obtain written permission or confirm permissive terms; provide planned attribution text. - Provide publisher details: name, website, support email, privacy policy URL. - Choose authentication: No auth (if acceptable) or API key (preferred). If API key, confirm we can issue test keys for MS validation. Phase 1 — Proposal (optional but recommended) (Me drafts, You submit) - Draft short proposal (problem solved, audience, data source, auth, high-level endpoints/tools, public URL). You submit via the Microsoft process referenced in the docs. Phase 2 — Technical hardening (Me) - Add/verify: - `/healthz` endpoint and basic status. - CORS to allow Copilot Studio origins. - Consistent error payloads and HTTP codes. - Optional: simple API key auth (header-based), if chosen. - Rate limit headers and simple throttling or documented policy. - Smoke tests and minimal unit tests for error cases and health. Phase 3 — Certification artifacts (Me) - Create Copilot MCP connector manifest with: - Name, description, auth, server URL(s), tool list and parameters. - Documentation in a connector folder (e.g., `docs/copilot/connector/`): - README (overview, capabilities, auth, configuration, sample prompts, known issues). - TESTING.md (manual validation steps with expected outputs). - SUPPORT.md (contact, SLA, response times). - SECURITY.md (data, logging, retention). - CHANGELOG.md. - Branding: - 32x32 and 128x128 PNG connector icon, attribution if needed. Phase 4 — Public hosting readiness (You, Me assists) - Deploy to production (Cloud Run or equivalent) under a stable HTTPS URL. - Optional: set custom domain and TLS; verify CAA/DNS if applicable. - Provide a test API key (if used). Phase 5 — Submission (You; I prep content) - If using the Independent Publisher route: - Follow the submission instructions in “Prepare Copilot Studio and Power Platform connector files for certification”. - Provide the manifest, docs, icon, public URL, credentials, test steps, data rights notes. - If the path uses a GitHub PR to Microsoft’s connectors repo, I’ll prepare the folder structure and PR content; you open the PR and sign any CLA as needed. Phase 6 — Validation support and fixes (Me primary, You for approvals) --- ## Current status snapshot - Website: live at https://mcp.olexi.legal with accurate, host‑agnostic instructions. Done - Public MCP endpoint: https://olexi-mcp-root-au-691931843514.australia-southeast1.run.app/ (MCP at root). Done - Manifest: updated with endpoint, publisher, icons, privacy URL. Done - Connector docs: README, TESTING, SUPPORT, SECURITY, CHANGELOG, RIGHTS present and aligned. Done - Auth policy: No auth (documented in manifest/docs). Done - Data rights note: Attribution present; RIGHTS.md included. In progress (permission letter optional) - CORS/rate limit: Documented policy; implementation not required for MCP server to function. In progress (optional) ## Immediate next step 1) Optional but recommended: submit a short proposal issue to Microsoft (I can draft the text; you submit if the process requires your account). 2) Prepare and open the Independent Publisher submission PR with our manifest, docs, and icons. I will assemble the package in-repo and draft the PR body; you may need to complete org CLA or final submit depending on Microsoft’s process. ## Your manual items (minimal) - Provide/confirm AustLII ToS link and any permission letter (if available) to include in submission. If none, confirm we proceed with attribution-only justification. - Confirm publisher display name and website (currently “Olexi”, https://olexi.legal) and support email (ai@olexi.legal). - If Microsoft requires PR from your GitHub account: approve the prepared PR draft and complete any CLA checks. ## What I will do next (no action needed from you) - Create a `docs/copilot/connector/SUBMISSION_PACKAGE.md` with links to all artifacts and a PR-ready submission body. - Verify all docs link to the correct endpoint and privacy/terms URLs (done; will recheck in the package). - Start the submission PR draft text and instructions for the target Microsoft repo. - Triage MS feedback quickly. - Implement requested fixes and update artifacts. - Resubmit as needed. ## What I need from you now - Decision on auth approach: No auth vs. API key. - Publisher info: name, website, support email. - Confirmation of public hosting target (Cloud Run OK? custom domain or not). - Data rights confirmation for AustLII (link to ToS and/or permission). - Whether you want me to draft the optional proposal, or skip to submission. ## Risks to watch - Data rights/IP and scraping acceptability. - If Microsoft requires additional MCP-specific metadata not yet in public docs—we’ll iterate quickly. - Uptime/SLA expectations if on a free tier. ## Estimated effort - Technical hardening: 0.5–1.5 days. - Artifacts and docs: 1–2 days. - Submission packaging and iterations: 0.5–1 day (excluding MS review cycles). Once you confirm the few choices above, I’ll execute the plan and prepare everything for submission.