ostrov-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OSTROV_API_TOKEN | No | An existing API token can be passed securely via the application's environment mechanism in OSTROV_API_TOKEN. | |
| OSTROV_API_BASE_URL | No | Changes the API base URL for local testing. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Quotes are preliminary. Availability and booking require confirmation. Obtain explicit user confirmation before saving or submitting.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_centerC | Public location and contact information. |
| get_catalogB | Current tariff version, resources and rules. Do not cache prices as permanent knowledge. |
| get_objectsB | Current public resource descriptions and availability rules; no guarantee of open places. |
| get_calendarC | Confirmed public activity; empty dates do not mean availability. |
| get_eventsC | Public programs and labeled demo data; contact the organizer to ask about joining. |
| calculate_quoteB | Calculate without saving or contacting anyone. Check complete, warnings and availabilityStatus. |
| suggest_groupB | Suggest room/program selection for the ordinary group tariff; not an availability check. |
| save_estimateA | Save after explicit user request. Group/biggroup require organizer and retreat title; resident requires guest name. Confidential human link returned. |
| get_estimateC | Read only a document owned by this session. |
| edit_estimateA | Edit an owned draft after explicit user request; stale versions conflict. |
| submit_applicationA | Submit only after user confirmation and contact consent. This does not confirm a booking. |
| get_applicationB | Read the actual state of the session-owned application. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct resource+action targets, and the descriptions proactively disambiguate (e.g. calculate_quote 'without saving', suggest_group 'not an availability check'). The weakest boundary is the read cluster get_events / get_calendar / get_objects, which all describe public schedule/resource information and could be confused by an agent, as could calculate_quote vs suggest_group for advisory tasks.
Every tool follows a strict verb_noun snake_case pattern (get_events, calculate_quote, save_estimate, submit_application). The estimate lifecycle uses a coherent get/save/edit triplet, making the convention highly predictable.
12 tools sit comfortably in the well-scoped range, and each maps to a distinct stage of the workflow: discovery, quoting, estimate drafting, and application submission. No tool looks like filler or a duplicate alias.
The surface covers discovery, quoting, estimate CRUD (save/get/edit), and application submit/get, but there are notable gaps: no tool actually checks availability despite repeated disclaimers that other tools do not, and there is no cancel/withdraw or update path for a submitted application, nor a list/delete for estimates. Agents hitting these dead ends will have to fall back on contacting the organizer.