# Elron Club public agent interface

Use the customer-safe API or MCP endpoint. Never drive the private Hub or the human web application.

- OpenAPI: https://elron.club/api/public/v1/openapi.json
- Portable Streamable HTTP MCP (snake_case tool names): https://elron.club/api/agent/public/mcp/v1
- Full public capability index: https://elron.club/agent-docs/capabilities
- Streamable HTTP MCP: https://elron.club/api/agent/public/mcp
- MCP Registry metadata: https://elron.club/.well-known/mcp/server.json
- UCP business profile: https://elron.club/.well-known/ucp
- UCP rental specification: https://elron.club/agent-docs/ucp
- Listings: https://elron.club/api/public/v1/rentals
- Discovery-to-booking example: https://elron.club/agent-docs/example
- Human MCP onboarding: https://elron.club/mcp

## Access and scope

Connect to the portable endpoint for clients including Google. No account or API key is needed to initialize, list tools, or read public information. The original endpoint preserves dotted tool names; portable tools use underscores, for example rentals_search and applications_get. Use names and input/output schemas returned by tools/list.

The catalogue covers rentals, locations, regions, jobs, company/legal information, help, all four contact forms and support photo uploads, customer-owned Request fields/documents, inquiry activation, viewing proposals/windows/cancellation/feedback, quotes/holds, contract/payment/booking status, availability update preferences, and resident access recovery. The capability index lists every tool and both names. OpenAPI describes the existing REST rental subset; tools/list describes the full MCP catalogue.

Personal rental data and follow-up actions require the owning email-verified session; availability preferences require the email management token. Initial contact intake, photos, signup and resident access recovery require explicit customer confirmation. Obtain confirmation before sending communications, submitting a Request, changing consent or making commitments. Refresh applications.get and viewings.get_details before writes, carry exact versions, and retain the idempotency key. An uncertain outcome requires reconciliation, never a new-key retry.

Email identity verification and legal signatures remain human steps. Jobs use their published application email; resident operations use the authenticated resident portal. Saved rental IDs, cookies and display preferences are client-owned. Google app listing requires Google's separate onboarding, review and publication; endpoint availability alone does not establish admission.

## Recommended discovery flow

1. Call rentals.search for a compact shortlist. By default it returns up to 10 AVAILABLE or UPCOMING rentals, ordered by actionability; summaries are bounded to 280 characters.
2. Filter with city, region, ISO availableFrom, availabilityStatus, rooms, occupancy, monthly rent, or 3/6/12-month duration. Location matching accepts common English, German, and unaccented forms.
3. Read count, total, and hasMore before increasing limit (maximum 50).
4. Call rentals.get only for shortlisted rentalIds to retrieve the full description, address, coordinates, complete price/terms detail, and media.
5. Treat availability.availableFrom as ISO YYYY-MM-DD and availability.verifiedAt as the freshness timestamp.

Use availabilityStatus=AVAILABLE_OR_UPCOMING (the default), AVAILABLE, UPCOMING, UNAVAILABLE, or ANY. Do not use the human website to discover inventory when the API or MCP is available.

Discovery is anonymous. UCP callers advertise a stable HTTPS platform profile and negotiate an exact club.elron.rentals.* capability. Application and viewing mutations require a scoped email-verified session, exact versions, bounded inputs, and durable idempotency keys. Upload documents with applications.create_document_upload, POST the binary to its exact-size signed form, then call applications.complete_document_upload. Use viewings.get_status before proposing availability or explicitly responding to an Elron Club proposal. Quote acceptance creates only an expiry-bound availability hold. Contract signature and payment authorization remain human/provider gates; follow an authorization URL only when payments.get_status returns one with its unexpired provider timestamp.