Skip to main content
Glama
Sign In

Free Agent Tools

by io.github.akiba-labs
OverviewDiscussionsAdmin

Which of these Airbnb house rules are likely not allowed under the policy for reservations booked from 2026-11-20, and how should they be rewritten?

airbnb_house_rules_check
Read-onlyIdempotent

Checks pasted short-term-rental house rules / checkout requests (English or Japanese, one per line) against keyword patterns built from Airbnb's help article 4168 and its 2026-10-20 announcement (rules as of 2026-10-28; policy covers reservations booked on or after 2026-11-20). Per rule: likely_flagged (cleaner tasks: washing/putting away dishes, dishwasher, stripping beds, laundry, vacuuming, taking trash off-site; fines, penalties, late-checkout fees, deposit deductions; restricting advertised amenities such as AC or hot tub; separate contracts or waivers; ID / personal info; off-platform apps or forms; new rules by message, sign or in person), review, move_to_section (mandatory fees → Pricing, HOA/local-government fines → Local rules, check-in times), legal_exception (Japan: 宿泊者名簿 guest register and passport copy for foreign guests without a Japan address under 住宅宿泊事業法 art. 8 / 旅館業法 art. 6, if disclosed in Requests before booking), use_standard_rule (max guests, quiet hours, events, pets, smoking, commercial photography, lock up), likely_ok (dishes in the sink, gather towels, sort trash into indoor bins, turn off AC, optional priced add-ons, safety info, local exceptions like bear-proof bins) or no_match. Returns verdict (fix_needed | review_needed | tidy_up | looks_ok), headline, summary, policy {appliesToBookingsFrom, appliesToThisBooking, daysUntilPolicy}, counts, items [{text, finding, reasons, reasonsJa, rewrite, moveTo, japanNote}], standardRulesToSet, japanChecklist (art. 9 explanation duty, minpaku trash is business waste), sources, disclaimer. Use for 'can I still ask Airbnb guests to do dishes / strip beds / take out trash', 'Airbnb house rules change November 2026', 'Airbnb late checkout fee allowed', エアビー ハウスルール 変更, 民泊 パスポート 写し Airbnb. Educational keyword check, likely outcomes only; not affiliated with Airbnb, which decides.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "text": "<text>"
    },
    "name": "airbnb_house_rules_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesHouse rules / requests to check, one per line (English or Japanese). Max 8000 chars, 80 rules.
todayNoYYYY-MM-DD (default: today in Japan).
channelNoWhere guests see the rules: listing (default, House rules and requests) | message | sign | in_person. Outside the listing can't add new rules.
lodgingNoJapan licence: minpaku (住宅宿泊事業法) | ryokan (旅館業法: hotel, ryokan, 簡易宿所) | unknown (default).
bookingDateNoYYYY-MM-DD date the reservation was booked (policy covers bookings on or after 2026-11-20).
jurisdictionNoJP (default) adds Japan legal exceptions (guest register, passport copy) and notes; other = generic.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses that matching is keyword-based, that outputs are 'likely outcomes only', that it is not affiliated with Airbnb 'which decides', and that policy applicability depends on booking date. That is exactly the residual-risk context an agent needs before relying on the verdict.

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

Conciseness3/5

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

The usage triggers and date scope are front-loaded, but the middle is a single enormous parenthetical enumerating every flag category, plus a second exhaustive field list for the return object. Dense and hard to scan; it earns most of its length but could be split into short bullets without losing information.

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?

There is no output schema, and the description fully compensates by enumerating every returned field (verdict values, headline, summary, policy block, counts, items subfields, standardRulesToSet, japanChecklist, sources, disclaimer). An agent knows exactly what it will get back and how to interpret the verdict enum.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description still adds meaning: input is one rule per line in English or Japanese, and it ties the bookingDate/lodging/jurisdiction semantics to the substantive outcome (policy applicability, Japan legal exceptions). Minor duplication of schema text keeps it from a 5.

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+resource ('Checks pasted short-term-rental house rules / checkout requests ... against keyword patterns') and scopes it to a named policy (help article 4168, 2026-10-20 announcement, bookings on/after 2026-11-20). No sibling tool in the list does Airbnb rule auditing, so differentiation is implicit but unambiguous.

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?

Provides explicit trigger phrases in two languages ('can I still ask Airbnb guests to do dishes', 'Airbnb late checkout fee allowed', エアビー ハウスルール 変更) so the agent can pattern-match user intent. However it names no alternative tool or when-not-to-use condition; the only boundary is the 'Educational keyword check, likely outcomes only' caveat.

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

All Free Agent Tools toolsInspect
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