vitena-directory
Registry code: 0c5fa80a5ffbd419
Vitena's public directory of bookable health and wellness professionals across Europe and Turkey. Use list_directory_filters to learn valid city and specialization values, search_providers to find professionals, and get_provider for one professional's full public profile. All data is public; nothing here is patient or medical-record data.
- endpoint
- https://api.vitena.care/mcp
- protocol
- streamable-http ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is vitena-directory live?
- Yes — it answered the hub's last check (checked 4h ago). It answered 99% of checks over the last 30 days.
- Is vitena-directory free to use?
- Yes — the hub reached it with no key and no payment.
- What tools does vitena-directory have?
- 3 tools: get_provider, list_directory_filters, search_providers.
- Is vitena-directory safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.5%· all time 99.5%
last good check
of 3 tools
- degraded → live
- live → degraded· timeout after 20000ms
- degraded → live
- used for
- find health and wellness professionals
- get a professional's public profile
- list directory filters
- takes → gives
- text → data
- tools
- 3 reads
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
list_directory_filters reads open 13h ago
Returns the valid filter values currently available in the Vitena provider directory: specialization codes (with human labels), spoken-language codes, and the countries that currently have listed professionals. Call this FIRST when you intend to filter a search by specialization — that argument only matches exact codes from this list, so guessing a specialty name will silently return no results. Note that CITY is NOT in this list and does not need to be: search_providers resolves a free-text city, district or region name against a gazetteer, so pass the name the user actually said.
{ "type": "object", "properties": {}, "additionalProperties": false }arguments 5 linessearch_providers reads open 13h ago
Searches the public Vitena directory of health and wellness professionals who accept appointments (dietitians, dentists, physiotherapists, psychologists, beauty and aesthetics practitioners, child development specialists). Every filter is optional; with no filters it returns the first page of all publicly listed professionals. Results are public profile data only. Each result includes a profileUrl that can be given to the user for booking.
{ "type": "object", "properties": { "city": { "type": "string", "description": "Deprecated alias for 'location', kept so agents that learned the older argument name keep working. Prefer 'location'." }, "page": { "type": "integer", "minimum": 1, "description": "1-based page number. Page size is fixed at 20." }, "country": { "type": "string", "description": "Two-letter ISO country code, e.g. 'TR', 'ES', 'DE'. Narrows an ambiguous place name. Valid values come from 'countries' in list_directory_filters." }, "language": { "type": "string", "description": "Two-letter language code the professional consults in, e.g. 'es', 'tr'." }, "location": { "type": "string", "description": "City, district or region name in free text, e.g. 'Istanbul', 'Kadıköy', 'Madrid', 'Andalucía'. Resolved against a place gazetteer, so it does NOT have to match a fixed list and is NOT returned by list_directory_filters — pass the place the user actually named. Choosing a region matches everywhere inside it. An unrecognised place returns an explanatory error rather than silently ignoring the filter." }, "workMode": { "enum": [ "online", "in_person" ], "type": "string", "description": "Consultation mode. 'online' for remote, 'in_person' for on-site." }, "discipline": { "enum": [ "dietitian", "psychologist", "physiotherapist", "beauty", "child-development", "dentist", "doctor", "other" ], "type": "string", "description": "Profession to filter by. One of: dietitian, psychologist, physiotherapist, beauty, child-development, dentist, doctor, other." }, "specialization": { "type": "string", "description": "Specialization CODE (not label) as returned by list_directory_filters." } }, "additionalProperties": false }arguments 53 linesget_provider reads unknown 13h ago
Returns the full public profile of one professional by their slug (the value returned as 'slug' by search_providers): services offered, specializations, spoken languages, locations, working hours, contact details and whether online booking is available.
{ "type": "object", "required": [ "slug" ], "properties": { "slug": { "type": "string", "description": "Profile slug from search_providers, e.g. 'cristobal-diaz'." } }, "additionalProperties": false }arguments 13 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's id0c5fa80a5ffbd419.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/0c5fa80a5ffbd419/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/0c5fa80a5ffbd419?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.