[MCP] feat: Add local MCP client

[MonkeyCanCode]

Currently we need a third-party tool to be able to interact with MCP server (which can be costly if you have limited quota and result may not be consistent depends on the tools/models you are using), This PR adds a local MCP client for quick local testing.

Small catch, when using STDIO transport (reading local python file as server), the provided examples will all failed due to they won't be able to get environment variables from parent process (this is detail called out in https://fastmcp.mintlify.app/clients/transports#stdio-transport). However, once #82 is in, this problem should go away as the server now then load from .env file on the same path and not depends on environment variables from parent process. Thus for the sample example, I put default to HTTP transport (SSE will also work). If preferred, we can change back to STDIO once related PR got merged.

Also, once #83, I can add example for using diff realm.

[flyrain]

Thanks a lot for working on it, @MonkeyCanCode. It is a great tool for integration test. Can we move client.py out of mcp-server/ so it’s clear that this is an integration-test helper rather than production code.

Right now it lives alongside the runtime server modules, which means, it becomes part of the package namespace, it will get shipped with the PyPI artifact, and it can confuse contributors into thinking it’s a supported API.

A cleaner structure would be creating a dedicated integration test directory:

mcp-server/
  polaris_mcp/        # production code
  tests/              # unit tests
  int_test/           # <-- new directory for manual/integration tools
    client.py
    it.py             # move all sample commands in README here 

Then the README examples would simply reference:

uv run int_test/it.py

WDYT?

[MonkeyCanCode]

Thanks a lot for working on it, @MonkeyCanCode. It is a great tool for integration test. Can we move client.py out of mcp-server/ so it’s clear that this is an integration-test helper rather than production code.

Right now it lives alongside the runtime server modules, which means, it becomes part of the package namespace, it will get shipped with the PyPI artifact, and it can confuse contributors into thinking it’s a supported API.

A cleaner structure would be creating a dedicated integration test directory:

mcp-server/
  polaris_mcp/        # production code
  tests/              # unit tests
  int_test/           # <-- new directory for manual/integration tools
    client.py
    it.py             # move all sample commands in README here 

Then the README examples would simply reference:

uv run int_test/it.py

WDYT?

Hello @flyrain ,

Thanks for the review. So client.py was under mcp_server but on the same dir level as polaris_mcp. Looking at pyprojet.toml, it shouldn't be include in the package:

[tool.setuptools.packages.find]
include = ["polaris_mcp"]

But yes, I do agreed with you it may be better to put under some common path in case if we are planning to add more integration/manual testing tools.