intent · supabase_json

Oro Docs MCP intent

intent artifact · for Oro Docs MCP · status draft

Planning Surface

Use this to decide what happens next.

Status

draft

open questions

id	why	answer	question
OQ-INTENT-001	Placement affects config, versioning, and reuse outside RedKey.	Assume sibling repo `C:/Users/jstnk/Downloads/cc/projects/oro-docs-mcp` for planning to keep RedKey and Oro sources separate.	Should the MCP package live inside RedKey tooling or as a sibling repo?
OQ-INTENT-002	Application source indexing helps implementation questions but has higher noise and must remain separate from official docs search.	Yes. Plan it as a second corpus with explicit filtering and separate result labels, after the docs search and docs filesystem tools are safe.	Should the complete project include Oro application source indexing?

Agent Handoff

Start Here

intent artifact · for Oro Docs MCP · status draft

Completion Evidence

No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.

Open Questions

OQ-INTENT-001: id: string, why: string, answer: string, question: string
OQ-INTENT-002: id: string, why: string, answer: string, question: string

Structured Payload

Machine-readable source fields

brief

goal

Create a hosted MCP service at https://mcp.bezeliq.ai/ that indexes Oro documentation and selected Oro source, exposes reliable search plus exact read-only inspection, and publishes MCP cards for agent/tool discovery.

name

Oro Documentation MCP

must show

A search_oro tool that returns relevant Oro documentation snippets with source paths.
A query_docs_filesystem_oro tool that can read and search the docs tree with constrained read-only commands.
RST-aware indexing that extracts document titles, sections, code blocks, and source paths.
Clear source mapping from local paths to public documentation URLs where possible.
A refresh/index command that can rebuild the search corpus after the Oro docs repo updates.
A hosted MCP endpoint at https://mcp.bezeliq.ai/ with service-level routing for Oro docs.
MCP cards that describe the Oro docs MCP tools, auth/transport, source coverage, safety boundaries, and examples.
No writes to the Oro documentation checkout during normal MCP use.

constraints

Treat the Oro documentation checkout as a read-only source corpus for the MCP runtime.
Do not place the Oro repositories inside RedKey; they live as sibling repositories under C:/Users/jstnk/Downloads/cc/projects.
The complete MCP should include hosted access plus offline/index refresh capability for controlled rebuilds.
Keyword search must work without paid APIs; semantic/hybrid search may use configured server credentials.
The complete MCP should support both Oro documentation and a separately gated Oro application source corpus.
The MCP should follow the Hedera docs MCP interaction pattern where possible.
Do not implement product code until Justin explicitly approves a build slice.

out of scope

Hosting a public Oro documentation website.
Changing Oro documentation content.
Building a visual UI.
Executing arbitrary shell commands from the MCP.
Indexing private customer code or credentials.
Using the MCP to execute or modify Oro application code.

client context

RedKey already benefits from a Hedera documentation MCP that gives agents focused search and read-only filesystem inspection over official docs. Justin wants the same capability for OroCommerce/OroPlatform documentation.

why this matters

Oro is a large Symfony-based commerce platform with extensive Sphinx/reStructuredText documentation. Agent work against Oro needs grounded source lookup instead of web search, stale model memory, or manual file browsing.

delivery decision

runtime

Hosted HTTP MCP on Cloudflare/Workers-style edge or small Node service, with local development server support

database

Projects database

docs source

C:/Users/jstnk/Downloads/cc/projects/documentation

planning owner

Atlas-Codex

hosted endpoint

https://mcp.bezeliq.ai/

architecture owner

Vikram

implementation home

Separate local MCP package, likely C:/Users/jstnk/Downloads/cc/projects/oro-docs-mcp unless Justin chooses RedKey tooling ownership.

reference app source

C:/Users/jstnk/Downloads/cc/projects/orocommerce-application

project start rule

This project is in artifact/planning mode. Do not create the MCP package, write implementation code, or register MCP config until Justin explicitly approves build execution.

project

oro-docs-mcp

name

Oro Documentation MCP

client id

redkey

created at

2026-05-01

source refs

path	type	title	commit	remote	created at
C:/Users/jstnk/Downloads/cc/projects/documentation	repo	oroinc/documentation checkout	b6f7312cc21f0c66797505e17216b3ea79daa828	https://github.com/oroinc/documentation.git
C:/Users/jstnk/Downloads/cc/projects/orocommerce-application	repo	oroinc/orocommerce-application checkout		https://github.com/oroinc/orocommerce-application.git
	session_context	Justin asked to create a Hedera-docs-style MCP for Oro documentation			2026-05-01

project type

internal_tool

not related to

Oro product implementation
RedKey public product UI
A hosted Oro documentation fork

project name canonical

Oro Documentation MCP

stakeholders

id	name	message
STAKE-JUSTIN	Justin	Needs agents to answer Oro questions and inspect exact Oro docs quickly, like the existing Hedera docs MCP.
STAKE-ATLAS	Atlas-Codex and RedKey agents	Need grounded Oro source retrieval for planning, implementation, review, and debugging.

artifact type

INTENT

open questions

id	why	answer	question
OQ-INTENT-001	Placement affects config, versioning, and reuse outside RedKey.	Assume sibling repo `C:/Users/jstnk/Downloads/cc/projects/oro-docs-mcp` for planning to keep RedKey and Oro sources separate.	Should the MCP package live inside RedKey tooling or as a sibling repo?
OQ-INTENT-002	Application source indexing helps implementation questions but has higher noise and must remain separate from official docs search.	Yes. Plan it as a second corpus with explicit filtering and separate result labels, after the docs search and docs filesystem tools are safe.	Should the complete project include Oro application source indexing?

schema version

1.0