Phorme Training

List or claim my place

create_or_claim_place

Use this when a gym, studio or clinic owner wants their place on Phorme, for example after an AI check, or says "list my gym". Confirm the name, city and address with the owner first, and set confirmation to true only after they said yes. It lists the place for the connected account as a draft nobody sees yet, with its page facts, and finds the map pin from the address. If the account already lists a place with that name in that city it returns that place and changes nothing. Listing is free; it takes no payment and starts no plan. It needs a connected Phorme account.

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`	Yes
`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`	Yes	The place's name, as the owner wrote it.
`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`	Yes	For example "United States".
`website`	No	The place's own website, starting with https://.
`book_url`	No	The place's own booking page, starting with https://.
`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 listing this place.
`request_email`	No	Where booking confirmations and requests are emailed. Never shown in public.

Output Schema

Name	Required	Description
`next`	Yes	What to tell the owner next.
`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).
`status`	Yes

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.7/5.0

Behavior5/5

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

Beyond the annotations (which only declare readOnly=false, destructive=false, openWorld=false), the description discloses that the result is an invisible draft, that page facts are captured and the map pin is derived from the address, that an existing name+city match is returned unchanged, that no payment or plan starts, and that a connected Phorme account is required.

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

Conciseness5/5

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

It is front-loaded with the when-to-use trigger, then the confirmation workflow, then side effects and constraints, then the account prerequisite. Every sentence carries a distinct fact (draft visibility, pin lookup, idempotency, no charge) with no filler.

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 an 18-parameter mutation with an output schema available, the description covers all that remains necessary: purpose, trigger, human-confirmation requirement, side effects, idempotency, cost posture, and auth prerequisite. Return values are correctly left to the output schema.

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 description coverage is 94%, so the schema already documents all 18 fields thoroughly. The description only reiterates the confirmation gating and the address-to-pin behavior, which the schema already states, so it adds little new parameter meaning beyond the baseline.

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?

The description states a concrete verb and resource (list/claim the owner's place on Phorme) and pins down the exact scope: a private draft that nobody else sees. It also implicitly separates the operation from publishing/updating by describing the draft-only, idempotent claim behavior.

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?

It names the precise trigger ('when a gym, studio or clinic owner wants their place on Phorme, for example after an AI check, or says "list my gym"') and the required precondition workflow (confirm name, city and address; set confirmation=true only after the owner agrees). This is explicit both about when to reach for the tool and how to gate it.

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.