Related Servers

The server hosts ~10 distinct scientific domains, but the sharpest problem is the eleven near-identical `report_feedback` tools (one per domain prefix) that all do exactly the same thing, and the repeated `generate_code`/`execute_code` names whose semantics diverge sharply across domains (local sandbox for ModelFitter/Argmin, cloud-submit for Tidy3D, remote k8s job for Meep). The domain prefixes help separate them, but an agent can easily pick the wrong execute_code or the redundant report_feedback.

Naming mixes CamelCase domain prefixes with snake_case verbs, which is internally readable, but is undermined by generic duplicated verb sets (generate_code, execute_code, report_feedback repeated across many domains) and an awkward legacy/new split (AxModelFitterLegacy vs AxModelFitter). Convention is broadly consistent within a domain but inconsistent across the aggregate surface.

57 tools is an extreme count for a single MCP server — well beyond the 25+ heavy threshold and effectively an aggregation of roughly ten unrelated toolkits (equations, model fitting, PDE, knowledge base, document parsing, plotting, numerical solvers, literature search, Tidy3D, Meep) under one namespace. This would be far more coherent split into separate servers per capability.

Each individual domain is reasonably complete: the knowledge base offers search, graph read, schema, overview, ingestion, listing, deletion and paper assets for both curated and private graphs; the model fitter covers fit, covariance, info criteria, R², cross-validation and comparison; PDE covers parse, derive and verify; Tidy3D and Meep each have full generate→execute→status→results lifecycles. Minor gaps exist (no knowledge-base update tool), but per-domain coverage is solid, though the aggregate purpose is unfocused.