Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Wheel load dispersal to a patch

point_to_patch_dispersal
Read-only

The Point to Patch Convertor's dispersal for one point load: the code's contact area (or the load-derived one), the spread through surfacing and slab to the mid-plane or neutral axis, the effective patch b_eff × l_eff and its pressure, with the clause. Presets cover EN 1991-2 LM1/LM2, the UK NA, CS 454 / HB, BS 5400 and Network Rail ballast/fill. Needs no model.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "presetId": "<presetId>"
    },
    "name": "point_to_patch_dispersal"
  }
}

Input Schema

NameRequiredDescriptionDefault
b0NoContact width across the traffic, m (null = the preset's).
l0NoContact length along the traffic, m.
tcNoSlab depth, m (apply: default the plate thickness).
tsNoSurfacing / ballast / fill depth, m.
loadNoPoint load, kN (needed for load-derived presets and the pressure).
alphaCNoHalf-angle through the concrete, °.
alphaSNoHalf-angle from vertical through the surfacing, ° (0 is honoured).
presetIdYesContact area and spread rule (EN 1991-2, UK NA, CS 454, BS 5400, Network Rail…; point_to_patch_read lists them with their clauses).
alphaCLongNo
alphaSLongNo
targetPlaneNo
neutralAxisDepthNom below the top, for NEUTRAL_AXIS.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false; the description adds that the tool needs no model and returns the effective patch and pressure with the governing clause. It does not describe error handling or output structure, but for a read-only calculation it adds useful behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, with the core purpose and outputs front-loaded, then presets and the no-model note. The first sentence is dense with parentheticals, but no sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter calculation with no output schema, the description covers the purpose, key outputs, preset families, and the fact that no model is required. It omits some parameter-level detail, but the schema fills most of that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, so the schema documents most parameters. The description still adds meaning by explaining the contact area can come from the code or be load-derived, the spread goes through surfacing and slab to mid-plane/neutral axis, and presets encode the contact/spread rule; it leaves alphaCLong/alphaSLong unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific calculation (dispersal for one point load) and enumerates its outputs—contact area, spread, effective patch b_eff × l_eff and pressure—so an agent knows what it computes. It also distinguishes itself from point_to_patch_read by saying that tool lists presets and clauses, and from model-based siblings with 'Needs no model.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives context that the tool is a standalone calculation ('Needs no model') and that presets are available, pointing to point_to_patch_read for the preset list. It does not explicitly say when to use this versus point_to_patch_apply or other siblings, so usage is implied rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources