Skip to main content
Glama
rhyne1012

avl-mcp

by rhyne1012
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Related Servers

Alternatives to avl-mcp

No user-submitted related servers found.

    Related Servers

    • Groundline

      fhs1220888
      A
      license
      B
      quality
      B
      maintenance
      Enables any MCP client to plan and run verifiable analysis of engine hot-fire and bench test data through tools that open runs, segment phases, check sensor health, redlines, valve response and oscillations, compare simulations, verify every reported number against an evidence ledger, and write HTML reports. All findings stay traceable and reproducible from deterministic tool calls rather than raw samples.
      5
      50 PyPI
      MIT

    • OpenVSP MCP (Maintained Fork)

      rhyne1012
      A
      license
      A
      quality
      A
      maintenance
      Maintained fork of Three-Little-Birds/openvsp-mcp, adding OpenVSP geometry inspection, typed parameter editing, SVG/STL previews, validated VSPAERO analysis, and durable parallel batches with progress, cancellation, resume, and CSV/JSON export. Independently maintained by rhyne1012; not an official OpenVSP or NASA project.
      18
      MIT

    • tigl-mcp

      cmudrc
      A
      license
      B
      quality
      B
      maintenance
      Provides MCP tools for CPACS-oriented TiGL workflows, enabling lifecycle management, inspection, export, and parameter manipulation of aircraft geometry models without native geometry runtimes.
      11
      3
      MIT

    • su2-mcp

      cmudrc
      A
      license
      Not graded
      quality
      B
      maintenance
      Enables interaction with SU2 CFD solver for session lifecycle management, config editing, solver execution, and results inspection, with optional CPACS integration for aircraft analysis.
      6
      MIT
    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    A3.9/5.0

    Scored across 14 tools

    Disambiguation4/5

    Most tools have clearly distinct roles: single-case run, multi-case sweep, detached submit, and job control/status/results are readily separable. The main ambiguity is within the trim family (prepare_trim, trim, trim_physical), though their descriptions clarify whether AVL is executed and what inputs are required.

    Naming Consistency3/5

    All names use lower snake_case under the avl. namespace, which is consistent at the lexical level. However, the set mixes imperative verbs (run, sweep, submit, inspect) with noun-like resource names (status, results, health) and compound descriptive forms (mesh_sensitivity, trim_physical), so it is readable but not a predictable verb_noun convention.

    Tool Count5/5

    Fourteen tools is well within the appropriate range for a complex AVL analysis server. Each major phase—inspection, validation, execution, background job control, and result retrieval—has a dedicated tool without obvious filler.

    Completeness4/5

    The surface covers the core AVL lifecycle: inspect/validate/health, trim preparation, run/sweep/submit, status/cancel/resume, and results retrieval. Minor gaps such as a job-list operation or explicit geometry/setup management are not central to the apparent analysis scope, but there is no obvious dead end.

    Maintenance

    ActivityMaintained
    ResponsivenessNo issues

    Resources