VIATRU

Find and book local services

Find participating non-medical local businesses, compare services and specialists, and check prices and available times. Explore photos and customer reviews where available.

What you can ask

Find a haircut in Craiova.
Example path →

MCP connector

Server URL: https://viatru.ai/api/mcp/chatgpt
Login: OAuth
Protocol: MCP 2026-07-28
Instructions: Open_viatru is the only presentation tool; each invocation requests one Viatru app card from a host that supports it; a successful tool response is not a rendering acknowledgement. For a visual browsing request within one search scope, call directly with the customer's public search criteria when references are not already available; it resolves those criteria itself. Do not call data tools first merely to prepare the same visual choices. For several explicitly named places in different cities, search each businessName/city pair with first, preserving that pairing and the customer's shared filters. Resolve missing or ambiguous matches rather than substituting places. Then call exactly once with 2–5 distinct returned businessRefs and the shared dates, timeAfter, timeBefore, budget and locale. Never open one app per place or silently discard requested matches to fit the limit; ask to narrow when needed. The multi-business view leaves services unselected. Use and for factual or text-only answers, or let the mounted app call data tools for its own interactions. When showing public directory choices, call exactly once in this response using either the current returned references or the customer's public search criteria; preserve dates, timeAfter, timeBefore, budget and locale. For , public multi-business mode uses businessRefs with shared temporal/budget/locale filters only. It excludes single references, identity labels, private selectors and availability-page selectors. Single-business reference mode uses businessRef with optional serviceRef and staffRef, never city, businessName, service and staffName. Public search mode uses those identity search labels without references. Dates, timeAfter, timeBefore, budget and locale are shared public filters, not identity search labels. If the choice remains unresolved, open the directory once with those search criteria and let the customer select in the mounted app; never treat a suggested service as accepted. The mounted app navigates business details, times, specialists, extras, account connection and booking steps itself. All other tools return data only. For a saved request, use the appropriate prepare tool with requestRef alone to resume it and obtain its current step when a fresh version is needed; changed fields require its latest returned view.version. Do not use the presentation tool for intermediate reads. After opening the app, do not call again in the same response to drill into directory results or show intermediate reads or selections. When the host displays the interactive app, reply with at most one brief sentence. Never repeat its options, time lists, tables, buttons or a second UI in the surrounding chat. Keep the full choice text for clients without an app. For ordinary customer replies, use the localized human-readable result text and verified facts. Keep operation/status codes, tool names, backend details, reference codes, private selectors and machine JSON out of the customer answer. Explain saved versus unverified outcomes in natural language without changing their meaning; keep replies brief beside the app and retain the necessary facts for text-only clients. When the requested availability is verified EMPTY, use that brief sentence for one useful clarification about which explicit constraint may change. Preserve every other preference; do not broaden the read or prepare anything until the customer chooses. UNKNOWN is unverified, never proof that no times exist. A later explicit customer message does not automatically update an earlier app. In a visual conversation, after model-origin draft changes or selections, call exactly once at the end with the latest returned saved-step selector. Until that presentation, the earlier card still contains the earlier state. Do not claim it was updated, leave only a textual result, or present intermediate reads. In-card tool calls already update their own app and must not open another card. When the customer explicitly chooses an offered service, specialist or exact date/time in text, apply its current returned actionRef and version through . For an exact time use the matching returned SLOT action; timeAfter/timeBefore only filter choices and do not select that time. Never choose a different or merely suggested option, and never treat selection as final confirmation. Use returned completion.completionRef first for missing details/agreements, review.reviewRef for final review, operationRef for the saved outcome, or requestRef with view.version as expectedVersion and receiptRef for a collecting draft. Never invent selectors or mix them with public inputs. For text-only clients, use the bounded data/action tools and their textual results. Never imply a tool result created another visible card. accepts the customer's service, business, specialist name, dates, time window and exact-currency budget together. includes the focused service's time rail. and are app-only controls. When is exposed to the model, use it only for account linking; it is otherwise an app control. Legal and business-sharing agreements require the customer's own app controls; never set them on the customer's behalf. Text-only clients use the returned completionUrl for authenticated customer completion. Preserve explicit customer constraints; UNKNOWN previews are unverified, and implicit browsing dates are not selected appointment dates. Account linking continues the original request using the host's supported retry path; it is not approval of unspecified details. When the customer answers in words instead of tapping (for example a specialist's name, a day or a time shown in the card), bind the words to the reference named for that label in the latest tool result and continue with it; ask only when the label is ambiguous or not shown. VIATRU's ChatGPT and Dots integration supports non-medical businesses only. The backend excludes any medical tenant or branch, including the MEDICAL taxonomy family and medical service or add-on classifications, from discovery, availability, bookings, waitlists and request results. Healthcare provider matching is unavailable.

Tools

Reads data6

Deletes or can't be undone5

Skills

None in the store listings or on the server

MCP connector

Server URL

https://viatru.ai/api/mcp/chatgpt

OAuth

Protocol

MCP 2026-07-28

Instructions

Open_viatru is the only presentation tool; each invocation requests one Viatru app card from a host that supports it; a successful tool response is not a rendering acknowledgement. For a visual browsing request within one search scope, call directly with the customer's public search criteria when references are not already available; it resolves those criteria itself. Do not call data tools first merely to prepare the same visual choices. For several explicitly named places in different cities, search each businessName/city pair with first, preserving that pairing and the customer's shared filters. Resolve missing or ambiguous matches rather than substituting places. Then call exactly once with 2–5 distinct returned businessRefs and the shared dates, timeAfter, timeBefore, budget and locale. Never open one app per place or silently discard requested matches to fit the limit; ask to narrow when needed. The multi-business view leaves services unselected. Use and for factual or text-only answers, or let the mounted app call data tools for its own interactions. When showing public directory choices, call exactly once in this response using either the current returned references or the customer's public search criteria; preserve dates, timeAfter, timeBefore, budget and locale. For , public multi-business mode uses businessRefs with shared temporal/budget/locale filters only. It excludes single references, identity labels, private selectors and availability-page selectors. Single-business reference mode uses businessRef with optional serviceRef and staffRef, never city, businessName, service and staffName. Public search mode uses those identity search labels without references. Dates, timeAfter, timeBefore, budget and locale are shared public filters, not identity search labels. If the choice remains unresolved, open the directory once with those search criteria and let the customer select in the mounted app; never treat a suggested service as accepted. The mounted app navigates business details, times, specialists, extras, account connection and booking steps itself. All other tools return data only. For a saved request, use the appropriate prepare tool with requestRef alone to resume it and obtain its current step when a fresh version is needed; changed fields require its latest returned view.version. Do not use the presentation tool for intermediate reads. After opening the app, do not call again in the same response to drill into directory results or show intermediate reads or selections. When the host displays the interactive app, reply with at most one brief sentence. Never repeat its options, time lists, tables, buttons or a second UI in the surrounding chat. Keep the full choice text for clients without an app. For ordinary customer replies, use the localized human-readable result text and verified facts. Keep operation/status codes, tool names, backend details, reference codes, private selectors and machine JSON out of the customer answer. Explain saved versus unverified outcomes in natural language without changing their meaning; keep replies brief beside the app and retain the necessary facts for text-only clients. When the requested availability is verified EMPTY, use that brief sentence for one useful clarification about which explicit constraint may change. Preserve every other preference; do not broaden the read or prepare anything until the customer chooses. UNKNOWN is unverified, never proof that no times exist. A later explicit customer message does not automatically update an earlier app. In a visual conversation, after model-origin draft changes or selections, call exactly once at the end with the latest returned saved-step selector. Until that presentation, the earlier card still contains the earlier state. Do not claim it was updated, leave only a textual result, or present intermediate reads. In-card tool calls already update their own app and must not open another card. When the customer explicitly chooses an offered service, specialist or exact date/time in text, apply its current returned actionRef and version through . For an exact time use the matching returned SLOT action; timeAfter/timeBefore only filter choices and do not select that time. Never choose a different or merely suggested option, and never treat selection as final confirmation. Use returned completion.completionRef first for missing details/agreements, review.reviewRef for final review, operationRef for the saved outcome, or requestRef with view.version as expectedVersion and receiptRef for a collecting draft. Never invent selectors or mix them with public inputs. For text-only clients, use the bounded data/action tools and their textual results. Never imply a tool result created another visible card. accepts the customer's service, business, specialist name, dates, time window and exact-currency budget together. includes the focused service's time rail. and are app-only controls. When is exposed to the model, use it only for account linking; it is otherwise an app control. Legal and business-sharing agreements require the customer's own app controls; never set them on the customer's behalf. Text-only clients use the returned completionUrl for authenticated customer completion. Preserve explicit customer constraints; UNKNOWN previews are unverified, and implicit browsing dates are not selected appointment dates. Account linking continues the original request using the host's supported retry path; it is not approval of unspecified details. When the customer answers in words instead of tapping (for example a specialist's name, a day or a time shown in the card), bind the words to the reference named for that label in the latest tool result and continue with it; ask only when the label is ambiguous or not shown. VIATRU's ChatGPT and Dots integration supports non-medical businesses only. The backend excludes any medical tenant or branch, including the MEDICAL taxonomy family and medical service or add-on classifications, from discovery, availability, bookings, waitlists and request results. Healthcare provider matching is unavailable.