Naming Conventions

5.1 Why naming is normative

Interchangeability is the entire point of the standard. If two conformant servers name the same capability differently, an agent must special-case them — and the standard has failed. Names are therefore normative, not advisory.

5.2 Tool names

Tools are named domain.verb_object in lower_snake_case:

inventory.search
leads.create
consent.update
deals.request_trade_value
service.book_appointment
parts.check_availability

• The domain prefix MUST match a canonical domain namespace.
• The verb SHOULD come from a controlled vocabulary: list, get, create, update, search, cancel, check, request.
• Tool names MUST be stable across PATCH and MINOR versions. Renaming a tool is a MAJOR change.

Every standard resource SHOULD expose the predictable CRUD set so the surface mirrors a conventional REST resource and is trivial to learn — list and get for reads, plus create and update where the resource is writable:

consent.list      →  GET    /consents
consent.get       →  GET    /consents/{id}
consent.create    →  POST   /consents
consent.update    →  PUT    /consents/{id}

This one-to-one mapping between MCP tools and a REST resource keeps a conformant server implementable as a thin layer over an existing API.

5.3 Resource and field names

• Resource types are singular lower_snake_case nouns: vehicle, lead, repair_order.
• Fields are lower_snake_case. Industry identifiers keep their conventional spelling as a field (vin, ro_number), exposed alongside the server-scoped id.
• Enumerated values are lower_snake_case and drawn from the controlled vocabulary defined per field. Servers MUST NOT emit values outside the vocabulary; unknown states MUST map to a defined unknown member rather than a freeform string.

5.4 Stability rules

Change	Allowed in
Add an optional field	MINOR
Add a tool or domain	MINOR
Add an enum member	MINOR (consumers MUST tolerate unknown members)
Rename a tool, resource, or field	MAJOR
Remove or repurpose a field	MAJOR

5.5 Extensions

A server MAY expose vendor-specific capabilities, but they MUST be namespaced under x_<vendor>. (tools) or x_<vendor>_ (fields) so they can never collide with — or be mistaken for — standardized names. Agents MUST treat x_-prefixed names as non-portable.