Aman Amith Shastry Scientific Computation MCP server

Scientific Computation MCP

Installation Guide

The server speaks streamable HTTP. Add it from Smithery with the Smithery CLI (Node 20+):

npm install -g smithery@latest
smithery mcp add @aman-amith-shastry/scientific_computation_mcp --client claude

The namespace is lowercase. Smithery's registry lookup is case-sensitive, and the mixed-case spelling resolves to an empty record with no tools rather than failing outright, so a capitalized name looks like a server with no capabilities.

Swap --client cursor for Cursor, or drop --client to add it as a remote Smithery connection. Restart the client afterwards so it picks up the server.

Running Locally

uv sync
uv run src/main.py

The MCP endpoint is at http://localhost:8081/mcp and a liveness probe at http://localhost:8081/health. Environment overrides: PORT, HOST, MCPPATH, ALLOWEDORIGINS, LOG_LEVEL.

Deployment

Smithery no longer builds or hosts containers — servers are published either as a URL that Smithery's gateway proxies to, or as an MCPB bundle for local stdio. This server is published by URL, so the container runs on any host that can serve HTTPS.

docker build -t scientific-computation-mcp .
docker run -p 8081:8081 -e PORT=8081 scientific-computation-mcp

Two constraints the host must satisfy:

single replica splits the store and breaks createtensor → viewtensor flows.

• One instance. Tensors live in process memory between tool calls, so scaling past a

the tensor store is keyed per MCP session, which is what keeps concurrent users from reading each other's tensors.

• Sessions must survive. The transport runs stateful (stateless_http=False) and

Hosting on Render

render.yaml deploys the Dockerfile as a single free-plan web service. In the Render dashboard: New → Blueprint, then select this repo. Render injects PORT, terminates TLS, and probes /health; no other configuration is required.

Free instances spin down after 15 minutes without inbound traffic and take roughly a minute to come back. An open MCP session does not prevent this: the streamable-HTTP stream is server-to-client, so an idle session sends nothing inbound and the service sleeps out from under it. Two consequences worth planning around:

memory, so a spin-down takes the session and its tensors together. Active use keeps the service up, since each tool call is inbound traffic; a long pause mid-analysis does not.

• Tensors do not survive a 15-minute gap between tool calls. The store is in process

SmitheryBot/1.0, and a cold start can outrun its timeout. Warm /health first.

• Publish-time scans can land on a sleeping instance. Smithery scans the URL as

The free tier also grants 750 instance-hours per workspace per month against a ~730-hour month, so one continuously running free service just fits and a second does not.

Any host that keeps one process always on avoids all of this — the container is plain HTTP on $PORT with no platform-specific assumptions.

Publishing

curl -sS -o /dev/null -w '%{http_code}\n' https://<your-host>/health
smithery mcp publish "https://<your-host>/mcp" -n @aman-amith-shastry/scientific_computation_mcp

The server takes no user configuration, so no config schema is needed.

Shortened. The full README is on GitHub.