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 create or update resources in Jinko MCP, usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your Jinko MCP environment.
| 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 Medium
An AI agent can call book faster than any human can review: one bad instruction and it creates or modifies resources in Jinko MCP by the hundred, each call as confident as the last.
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:
book stays usable, but capped: an agent stuck in a loop can't make hundreds of changes a minute. Everything else on the server is denied unless you say otherwise.
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" // quote deadline — payment is refused past it, not re-priced. Not a price hold. Absent if the quote names none }, "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 Write tool in the Jinko MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
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 Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
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.
This server
Across the catalogue