Experience Bamfield

A guest's booked trip, from the link they gave you

get_trip_summary

Read-onlyIdempotent

After the booking. Takes the link a guest made for their assistant on their trip page (or just the key on the end of it) and returns a read-only summary of that one trip: whether it is ready to travel, what needs doing, by what date and who it is waiting on, each booked line with what it came to, and the money — payments received, refunds completed and pending, what is retained, the damage deposit and what is owing. Read it again each time you are asked (freshness.staleAfterSeconds). A fact that is not known is "unknown" and an amount that cannot be stated is null: never read those as yes, no or 0. When money.state is not_reconciled, tell the guest not to pay again on the strength of this and to call the desk. It includes nobody's name or contact details and can change nothing. A link that is wrong, expired or turned off is refused; ask the guest for a new one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`key`	No	Or only the 43-character key on the end of that link.
`link`	No	The link the guest gave you, whole: it looks like https://experiencebamfield.com/api/assistant/trip/KEY. Send this or key.

Output Schema

TableJSON Schema

Name	Required	Description
`trip`	Yes
`about`	Yes
`money`	Yes	Read from the order's own payment record. Always present on this link.
`ready`	Yes
`booked`	Yes
`contact`	Yes
`finishes`	Yes	Three separate things: ready to travel, the trip being over, and the money being settled.
`thisLink`	Yes
`freshness`	Yes	The summary is the trip as recorded at checkedAt and is worked out again on every read. Read the link again before answering; do not answer from a copy older than staleAfterSeconds.
`notIncluded`	Yes
`needsAttention`	Yes	Lines that need someone: a payment record to be checked first, then the guest's own, then the desk's, then what could not be verified, then what is waiting; within each, the earliest actBy first. Once the trip is over or cancelled, only money that still needs someone is listed (a payment record to check, a deposit not returned).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/idempotent annotations: it discloses return semantics ('unknown' for unknown facts, null for unstatable amounts, never read as yes/no/0), freshness via staleAfterSeconds, that no names or contact details are included, that nothing can be changed, and what happens with wrong/expired/disabled links. This is precisely the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the key framing ('After the booking.') and each sentence carries distinct operational information, but the money clause is a long run-on list and the overall prose is dense. Efficient in content, slightly heavy in delivery.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only lookup with an output schema, the description still supplies everything an agent needs: freshness guidance, null/unknown interpretation rules, the not_reconciled escalation instruction, and the refusal behavior for bad links. No material gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are already well described in the schema (whole link format, 43-character key, 'send this or key'). The description restates the either/or choice but adds no format or validation detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('returns a read-only summary of that one trip') and enumerates exactly what is returned — readiness, tasks, deadlines, booked lines, and money movements. The 'After the booking' framing cleanly separates it from pre-booking siblings like quote_trip without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear timing context ('After the booking') and an operational habit ('Read it again each time you are asked'), which tells the agent when to call and how often. It does not explicitly name an alternative tool or state when this one should not be used, so it falls short of a full when/when-not treatment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Experience Bamfield tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?