book
Unified tool for booking a trip. Actions are determined by which object you provide. SCHEMA: { create?: { // Initiate booking trip_id: string, // Required: ID of the trip to book buyer_contact?: { // Optional: buyer contact info email: string, phone?: string } }, status?: { // Check booking statu...
This record as markdown: /tools/com-gojinko-mcp-jinko/book.md
What book does on Jinko MCP
AI agents use book to commit financial operations through Jinko MCP, usually the final step of a payment, billing, or trading workflow. A call moves real money.
| Parameter | Type | Required | Description |
|---|---|---|---|
create | object | — | Initiate booking for a trip. Quotes the trip and returns a Stripe Checkout URL for payment. Mutually exclusive with `status` — provide exactly one action per ca |
status | object | — | Check the status of an existing booking. If payment is authorized, triggers fulfillment automatically. Mutually exclusive with `create` — provide exactly one ac |
user_intent | string | — | A concise summary of what the user is trying to accomplish, derived from their message or the conversation context that triggered this tool call. This is used t |
idempotency_key | string | — | Idempotency key to prevent duplicate processing |
Parameters from the server's own tool schema.
Why book is rated Critical
Booking a trip commits a financial obligation (purchasing flights, hotels, etc.) on behalf of the user. The `create` action initiates a real booking transaction with buyer contact details and an idempotency key — a pattern typical of payment/reservation APIs to prevent duplicate charges. Misuse could result in unauthorized financial commitments.
From the tool's definition "Unified tool for booking a trip" with a `create` action that "Initiate[s] booking" requiring a trip_id and buyer contact info including email and phone, with an idempotency_key to "Prevent duplicate processing"
Attacks that exploit this kind of access
The rule that runs book safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Jinko MCP, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For book, this is the rule to start with:
Any call to book is blocked until a human approves it. The rest of the server keeps working.
The button opens the PolicyLayer dashboard: create your workspace, connect Jinko MCP, apply this rule, and every book call is checked against it from then on.
Questions about book
Unified tool for booking a trip. Actions are determined by which object you provide. SCHEMA: { create?: { // Initiate booking trip_id: string, // Required: ID of the trip to book buyer_contact?: { // Optional: buyer contact info email: string, phone?: string } }, status?: { // Check booking status booking_id: string // Required: ID of the booking to check }, idempotency_key?: string // Prevent duplicate processing } ACTIONS: 1. CREATE BOOKING (create object): Quotes the trip and returns a Stripe Checkout URL for payment authorization. { "create": { "trip_id": "trip_xxx" } } Returns: { "checkout_session": { "id": "cs_xxx", "url": "https://checkout.stripe.com/...", // Open this URL for payment "expires_at": "2026-01-08T15:30:00Z" }, "pending_booking": { "id": "bkg_xxx", "status": "awaiting_payment", "trip_id": "trip_xxx" } } 2. CHECK STATUS (status object): Retrieves booking status. If payment is authorized but fulfillment hasn't started, automatically triggers fulfillment. { "status": { "booking_id": "bkg_xxx" } } Returns: Full booking object with status, items, passengers, totals, payment info. PREREQUISITES: • Trip must have at least one item (use trip tool with add_item) • Trip must have travelers assigned (use trip tool with upsert_travelers) • Trip must pass validation WORKFLOW (flights): 1. flight_calendar → offer_token 2. flight_search → trip_item_token 3. trip(add_item) → trip created 4. trip(upsert_travelers) → travelers set 5. book(create={trip_id}) → checkout URL WORKFLOW (hotels): 1. hotel_search → htl_* offer_id 2. trip(add_item, trip_item_token=htl_*) → trip created 3. trip(upsert_travelers) → travelers set 4. book(create={trip_id}) → checkout URL Flights and hotels can be in the same trip (single checkout). After book(create), poll with book(status={booking_id}) for confirmation. EXAMPLES: 1. Create booking: { "create": { "trip_id": "trip_xyz789" } } 2. Create booking with buyer contact: { "create": { "trip_id": "trip_xyz789", "buyer_contact": { "email": "john@example.com", "phone": "+1-555-123-4567" } } } 3. Check booking status: { "status": { "booking_id": "bkg_xxx" } } Cost: 1 credit per call. It is categorised as a Financial tool in the Jinko MCP MCP Server, which means it involves financial transactions. Block by default and require explicit approval.
book accepts 4 parameters: create, status, user_intent, idempotency_key. The full parameter table on this page comes from the server's own tool schema.
Register the Jinko MCP server in PolicyLayer and add a rule for book: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Jinko MCP. Nothing to install.
book is a Financial tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the book rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for book. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
book is provided by the Jinko MCP server (https://mcp.gojinko.com). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Jinko, and thousands of servers like it.
Across the catalogue