Phorme Training

Update my place

update_place

Idempotent

Use this when an owner wants to change what their place's page says: name, address, hours, booking link, what kind of place it is, the line about it, its time zone, its phone, its price list or the email for requests. Read the change back to the owner first, and set confirmation to true only after they said yes. Only the things given change; an empty value clears one. A new address moves the map pin. A live page shows the change at once. The price list only shows what the place charges; nothing is sold here. It needs a connected Phorme account that owns the place.

Input Schema

Name	Required	Description
`lat`	No	Latitude of the map pin, only to set it by hand.
`lon`	No	Longitude of the map pin, only to set it by hand.
`city`	No
`kind`	No	What the place is: gym (also studios and boxes) or a kind of care.
`line`	No	One line on what the place is, in the owner's words.
`name`	No
`about`	No	One or two plain sentences about the place, in the owner's words.
`hours`	No	Opening hours, one line each, for example ["Mon to Fri, 6 am to 9 pm", "Sat, 8 am to noon"].
`phone`	No	The place's public phone number, as the owner gave it.
`prices`	No	What training at the place costs, shown on its page, in the owner's own words: one line each, for example "Drop-in 25 dollars", or { label, amount (in dollars) or amount_cents, period, note }. At most 12; an empty list clears them. Repeat them only to the owner.
`address`	No	The street address. The map pin is found from it.
`country`	No
`website`	No	The place's own website, starting with https://.
`book_url`	No	The place's own booking page, starting with https://.
`place_id`	Yes	The place_id of one of the owner's places, from get_gym_report or create_or_claim_place.
`timezone`	No	The place's IANA time zone, for example "America/Chicago".
`book_label`	No	The words on its booking button, for example "Book a class".
`confirmation`	Yes	Set to true only after the owner said yes to these changes.
`request_email`	No	Where booking confirmations and requests are emailed. Never shown in public.

Output Schema

Name	Required	Description	Default
`next`	Yes
`place`	Yes	The place: place_id, name, kind, line, city, country, address, hours, about, book_url, request_email, request_phone (texts, never public), prices, phone, timezone, status (draft or live), page_url, upcoming_classes, brain_id, on_plan, held_requests and plan_url (the plan on phor.me, a price-free link; null when on the plan).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 19, 2026

changedOutput schema / properties / place / description

Previous value: -"The place: place_id, name, kind, line, city, country, address, hours, about, book_url, request_email, prices, phone, timezone, status (draft or live), page_url, upcoming_classes, brain_id, on_plan, held_requests and plan_url (the plan on phor.me, a price-free link; null when on the plan)."New value: +"The place: place_id, name, kind, line, city, country, address, hours, about, book_url, request_email, request_phone (texts, never public), prices, phone, timezone, status (draft or live), page_url, upcoming_classes, brain_id, on_plan, held_requests and plan_url (the plan on phor.me, a price-free link; null when on the plan)."

AddedOct 19, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (idempotent, non-destructive), the description discloses that only supplied fields change, that an empty value clears a field, that a new address moves the map pin, that a live page updates immediately, and that a connected Phorme account owning the place is required. These are exactly the behavioral details an agent needs before invoking a mutation.

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?

The description is front-loaded with the use case and confirmation workflow, then packs field and side-effect details into a few dense sentences. It is appropriately sized for 19 parameters, though some clauses are tightly stacked.

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

Completeness5/5

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

For a mutation tool with 19 parameters, an output schema, and rich annotations, the description covers the required elements: auth requirement, confirmation gating, clearing semantics, and side effects. Nothing essential for correct invocation is missing.

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 description coverage is high (84%), so the schema already documents individual parameters, setting a baseline of 3. The description adds meaningful cross-parameter semantics not present in the schema: 'Only the things given change; an empty value clears one' and that address changes reposition the map pin.

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 states a specific verb and resource ('change what their place's page says') and enumerates the updatable fields, making the tool's scope unmistakable. It does not, however, explicitly name or distinguish itself from any sibling tool such as update_gym_brain or publish_place, so it falls short of a 5.

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

Usage Guidelines4/5

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

It gives a clear when-to-use trigger ('when an owner wants to change...') and an explicit workflow: read changes back, set confirmation only after the owner says yes. It provides no when-not-to-use guidance or alternative-tool routing, so it is not a 5.

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

All Phorme Training 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.