[mrunalpendem123]

Fixes #544

This implements the tasks in #544 as written. The issue predates the SAM → agentmesh rename, so the code uses today's names: the agentmesh bin, AGENTMESH_* variables and @agentmesh-p2p/sdk.

Tasks

1. agentmesh executable (sdk/js/src/cli.ts, mcp-server.ts): McpServer + StdioServerTransport over MeshSession.
   • It exposes get_mesh_info, discover_remote_services, find_remote_tools, describe_remote_tool and call_remote_tool, with the node's parameter contracts and failure behaviour. Mesh-wide fan-out has a per-provider deadline, and a failing provider becomes an error row.
   • No list_local_services. Inference is left out: inference services are discoverable but not callable, because there is no /v1 endpoint here.
   • Configuration comes from AGENTMESH_CONTROL_PLANE_URL, AGENTMESH_BOOTSTRAP_TOKEN_PATH or AGENTMESH_JWT_PATH, AGENTMESH_STATE_DIR and AGENTMESH_INSECURE_CONTROL_PLANE. The first run enrolls; later runs resume as the same peer. No secret is passed on the command line.
   • Logs go to stderr only.
2. mcpName: io.github.google/agentmesh.
3. sdk/js/server.json: one npm package with stdio transport. The token paths are marked isSecret, and the version is stamped by hack/sdk-version.sh.
4. Auth: GitHub OIDC from release.yml. The registry grants io.github.google/* to workflows in google/agentmesh, so no DNS record or secret is needed.
5. release.yml: after npm publish, it runs mcp-publisher login github-oidc and mcp-publisher publish, and skips a version that is already listed. The publisher is downloaded at a pinned version, and its SHA-256 is checked.
6. Tests:
   • Unit tests for the tool mapping in sdk/js/src/mcp-server.test.ts.
   • TestNativeSDKMCPStdio drives the executable with a stdio MCP client against agentmesh-one. It checks parameter contracts against the node's own registrations, discovery and calls, that policy and label refusals never reach the backend, and identity reuse after a restart.
7. Docs: Connecting agents stays node-first. A new section, "Without a node: the MCP registry server", covers the stdio server as a lighter, complementary caller.

Validation

• CI passes on GitHub-hosted runners, from a PR inside my fork: Test, SDK, bats, kind-mesh-e2e, Test Flutter App, Deployment to GitHub Pages, Govulncheck and console-ui (all 8 workflows green on this commit).
• Locally:
  • make sdk-js passes (154 tests).
  • TestNativeSDKMCPStdio passes with -race.
  • mcp-publisher validate accepts server.json.
  • actionlint is clean.
  • sdk-version.sh stamps server.json together with package.json.
• Live check: Claude Code used the executable as its MCP server against agentmesh-one and an agentmesh-node provider. It discovered, described and called tools. A policy-denied call was refused, and a relaunch resumed the same peer ID.

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces a native JavaScript SDK implementation for running an Agent Mesh MCP client over stdio, including a CLI entry point, local MCP server, registry configuration, and updated documentation. Feedback on the changes suggests using fileURLToPath instead of .pathname in Node.js tests to ensure cross-platform compatibility on Windows. Additionally, several assertions in the Go integration tests should be updated to comply with the Repository Style Guide (§ 3.8) by explicitly stating both the observed and expected values in failure messages.

[aojea]

Since the rename, the docs live at google.github.io/agentmesh. Do you still want dev.sam-mesh/mesh, or would you prefer io.github.google/agentmesh?

@mrunalpendem123 yeah, the rename was very painful, the goal is to have it in the official registry, so do you know if there is anything else to do for using io.github.google/agentmesh or it will just work out of the box?

[aojea]

I can see in https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx we can use the github url directly and avoid the legacy sam-mesh domain so we can remove this

[mrunalpendem123]

Done in b1e9891. release.yml now uses mcp-publisher login github-oidc (the job already has id-token: write), and the server is published as io.github.google/agentmesh. The DNS step and the MCP_REGISTRY_PRIVATE_KEY secret are gone.

[aojea]

this is not here, so there is the agentmesh-node that provides a lot of functionality and this is just a simple way to have access to the mesh via an mcp without having the node, those are complementary

[aojea]

Oh, I see you added a section later, I need to read it , sorry

[mrunalpendem123]

Agreed, they are complementary. In ece3e28 I kept Connecting agents as it is on main, node-first, and added one section, "Without a node: the MCP registry server", for the stdio server as the lighter option. The separate deploying-node-mcp page is gone, so the docs change is now just that section.

[mrunalpendem123]

It works out of the box. The registry grants io.github.<repository_owner>/* to GitHub Actions OIDC tokens, so the release workflow in google/agentmesh can publish io.github.google/agentmesh with no DNS record and no secret. publish-sdk-js already has id-token: write for npm trusted publishing. The registry also checks that the npm version declares the same mcpName, and the publish step runs after npm publish, so the first release with this change gets listed.

I have switched the PR to it (b1e9891), and the docs keep the node first, with the stdio server as one complementary section (ece3e28). There is nothing to set up on your side.

[aojea]

Thanks