- Don’t rename the directory immediately; it’s critical for not breaking existing URLs, documentation, or integrations.
- Keep the “mcp_server” name while it’s in active, public/shared use.
- At the top of your
README.mdand/code/mcp_server/README.md, add a bold note:⚠️ Note: The `mcp_server` directory predates the industry-standard “Model Context Protocol.” In this repo, “mcp_server” means “multi-protocol agentic system (or modular cognitive platform).” It is the orchestrator and agent core—not just a modern “MCP tool registry.” Renaming is planned for future compatibility, but directory is unchanged to preserve link/AEO integrity.
- Create a migration plan:
- Internally, start referring to the replacement name in docstrings, comments, new docs (“agent_core/”, “cognitive_orchestrator/”, etc.).
- When you are ready to rename:
- Move
mcp_serverto e.g.,agent_core/in a new main branch/version (v2+). - Leave a
mcp_server/folder as a symlink (if possible) to new dir, or a README with explanation:This directory has moved to /agent_core/. All links will be maintained for legacy shared/SEO access. - Use
git mvor a scripted rename for open-source tracking.
- Move
- If you control deployment/docs:
- Update URLs, TOCs, and navigation for new/existing users, but keep forwarding or anchor docs for the old name until search/AEO/clients have caught up (could be 3-6 months).
- GitHub doesn’t support automatic soft redirects for renamed folders, but you can:
- Leave a stub/README in
/mcp_server/pointing to/agent_core/or/cognitive_orchestrator/. - In web docs/blogs, use canonical links or HTML meta-ref redirects for key content.
- Update ecosystem package indexes (PyPI, Docker Hub, etc.) to reflect the new name when you’re ready.
- Leave a stub/README in
- Announce the rename in:
- Project changelogs
- Key README docs and update guides
- Social channels (Twitter, LinkedIn), blog posts if relevant
- Archive historic “mcp_server” usage in a migration doc (explain the rationale—industry standard convergence, clarity, etc.).
- For all NEW contributions, use the new preferred naming in:
- Code comments, function/class docstrings, workflow demos
agent_core- Be explicit about the architecture (“agent”, “orchestrator”, “governance”): that helps future search, ecosystem, and contributors.
| Step | What to do/How to signal |
|---|---|
| Keep current dir | Don’t break links until ready |
| Explain everywhere | Add bold notice in README, docs |
| Prepare rename | Migrate internally, announce & document |
| Redirect/forward links | README pointer in old directory |
| Announce and archive | Changelogs, blogs, project update notes |
| Use new names in new code | Phase in “agent_core” (or similar) now |
This lets you support current users/search, avoid confusion for new ones, and smoothly upgrade the project over time—without breaking your AEO, collaborations, or community integrations.
-
Do NOT rename immediately.
Keepmcp_serveras-is in main/master for now to preserve:- All shared URLs (GitHub, docs, search engines)
- Backward compatibility for collaborators and integrations
-
Add a prominent note in your README and
/code/mcp_server/README.md:Note: “mcp_server” here refers to our historic “modular cognitive platform”—the full agentic orchestrator. We plan to update naming for standard clarity, but links are retained for now for stability, SEO, and user continuity.
-
Prepare your new name in background:
- Pick a futureproof term (e.g.,
agent_core,orchestrator,governance_brain, etc.) - Start using that internally in new code, docstrings, and new tutorial docs.
- Optionally, mirror directory structure—keep both
mcp_server/andagent_core/in a dev branch for initial migration.
- Pick a futureproof term (e.g.,
-
When you’re ready to rename publicly:
- Move contents to the new folder in a major version/branch bump (
v2or similar). - Leave a
mcp_server/directory with only a README:This directory has moved to
/agent_core/([link]). All legacy links are maintained for search/discoverability. Please update bookmarks as development migrates. - In web documentation, set canonical element or a redirect to prioritize the new path in search engines.
- Move contents to the new folder in a major version/branch bump (
-
Signal widely:
- Announce rename in GitHub releases, changelog, and community channels (Twitter, LinkedIn, mailing list, etc.)
- Highlight rationale: aligning with evolving AI/LLM/agentic ecosystem standards.
-
Monitor AEO/SEO:
- Search your current links in Google/Bing and note top-ranking pages.
- Keep the old directory/index file around for at least 6–12 months (or longer if you have heavy traffic).
Short version:
- Add a visible note now.
- Build out the new organization behind the scenes.
- When you do change, leave a prominent marker (README) in the old directory for continuity.
- Announce clearly to users and search engines.
Let me know if you need example README boilerplate or further advice for specific indexation/migration tools!
Goal: Give Paper2Agent clear Python files that act as “callable tools” for each protocol you want indexed.
How:
- For each major protocol/class, create a file in
/code/tools/(or top-level/tools/) named for the protocol, e.g.:run_sep_tool.pyrun_ccp_tool.pyrun_rep_tool.py
Sample wrapper for SEP:
# run_sep_tool.py
from code.mcp_server.protocols.sep.semantic_encoding_protocol import SemanticEncodingProtocol
import sys
import asyncio
def main():
sep = SemanticEncodingProtocol()
text = sys.argv[1] if len(sys.argv) > 1 else input("Enter text: ")
result = asyncio.run(sep.encode_text(text))
print(result)
if __name__ == "__main__":
main()- Repeat for other protocols (REP, CCP, VVP, etc.), calling their main method for a demo input.
Goal: Some extractors also look for function/class docstrings with clear "tool" or "entrypoint" markers.
- Ensure your wrappers have:
- A top-of-file docstring:
""" Tool: Run the SEP Protocol Input: Text string Output: Semantic encoding vector and meta """
- Optionally standardize with a tag/comment like
# MCP_TOOL_ENTRYPOINT
- A top-of-file docstring:
Goal: Help Paper2Agent “see” everything.
- Make a
tools_manifest.pyorpaper2agent_index.mdlisting every protocol/tool and its wrapper.SEP: run_sep_tool.py REP: run_rep_tool.py CCP: run_ccp_tool.py ... - Some frameworks will auto-index from such a manifest.
- Add a short section in your main README or in
/case-studies/:# 🛠️ Tool Entrypoints for Extraction Each major protocol is exposed as a CLI/standalone tool in `/tools/`. These wrappers are for agentizing and auto-tool-indexing. - Clearly map each protocol to their respective wrapper script.
- For any multi-step methods or pipeline demos (not just single protocols), make wrappers that run those as “one-click” scripts, too.
- Name and describe them for Paper2Agent as above.
- Make sure it targets the repo root.
- It should now recognize a whole suite of simple entrypoint scripts as “tools,” and treat your actual protocols as discoverable/agentizable.
- NO NEED to rewrite or refactor your orchestrator/architecture.
- These wrappers are adapters for tooling and auto-indexers—your real system remains clean.
- Later, when MCP terminology is fixed in your repo, you can extend this to direct API/agent integration without breaking backward compatibility.
| Step | Action | Example |
|---|---|---|
| Wrappers | One per protocol in /tools/ dir |
run_sep_tool.py |
| Docstrings | Describe usage/input/output | Top of each wrapper file |
| Manifest | List all wrappers/tools in one place | tools_manifest.py |
| Docs | Brief section in README/case-studies | Mapping protocols to wrappers |
| Demos | Wrap any pipeline/multi-step example | E.g. full_pipeline_tool.py |