Morris Golf

Plays like

plays_like

Read-onlyIdempotent

Calculate how far a shot plays with slope, wind and altitude, from rules of thumb with their sources. Given the course, it fills the forecast wind and the course altitude itself; give shot_bearing to apply the wind. Use it before choosing a club; then club_for_distance gives the club for the result. Read-only.

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": {
      "distance": "<distance>"
    },
    "name": "plays_like"
  }
}

Input Schema

Name	Required	Description
`unit`	No	Unit of distance and elevation_change. Metres by default.
`course`	No	The course. Without wind or altitude, they are filled from the forecast at the course and its altitude.
`distance`	Yes	Distance to the target.
`wind_unit`	No	km/h by default.
`wind_speed`	No	Wind speed, in wind_unit. Leave it out to use the forecast at the course.
`shot_bearing`	No	Direction the shot travels, in degrees from north. With a forecast wind it tells head, tail and cross.
`wind_direction`	No	Relative to the shot.
`elevation_change`	No	Target above the ball (positive) or below it (negative).
`course_altitude_m`	No	Altitude of the course above sea level, in metres.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026
- addedInput schema / properties / wind_speed / description
```
Added value: +"Wind speed, in wind_unit. Leave it out to use the forecast at the course."
```
First observedNov 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so the plain "Read-only." sentence earns nothing. The description does add real behavior beyond that: results come from "rules of thumb with their sources" (i.e., heuristics, not physics, with provenance), and the tool silently performs a forecast/altitude lookup for the course when those inputs are omitted. It stops short of describing the returned fields or units of the result.

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?

Front-loaded with the purpose, then scoping behavior, then the workflow, then safety. Every sentence contributes, though the phrase "from rules of thumb with their sources" is slightly awkward and the trailing "Read-only." duplicates the annotations.

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

Completeness3/5

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

Nine parameters and no output schema mean the description should say what the response contains (adjusted playing distance, whether it reports per-factor breakdowns, the cited rules of thumb, output units). It never does. The input-side story is nearly complete, but the result side — the whole point of a calculator — is left unspecified.

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

Parameters3/5

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

Schema coverage is 100% and the parameter descriptions already explain the forecast fill-in and that shot_bearing resolves head/tail/cross. The description mostly restates these. Its only added value is the relational dependency chain (course + shot_bearing -> wind applied -> result -> club_for_distance), which is useful but marginal against a fully documented schema.

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

Purpose5/5

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

"Calculate how far a shot plays with slope, wind and altitude" names a specific verb (calculate) and a specific output (how far a shot plays) plus the three modifiers it accounts for. It also distinguishes itself from the nearest sibling by naming club_for_distance as the downstream tool, so an agent can separate the two without opening either schema.

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

Usage Guidelines5/5

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

"Use it before choosing a club; then club_for_distance gives the club for the result" gives an explicit ordering and the alternative that follows. It also states the conditional branch for wind: the course fills forecast wind/altitude, but shot_bearing must be supplied to actually apply wind direction — a concrete when/when-not rule.

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

All Morris Golf tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.