Add a property to your human's bridge page. Include a score (1-10) and explain WHY this property fits their needs. You are their buyer's agent — only recommend properties you believe match. The human sees your score and notes on their page.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Property RIN to add | |
| notes | No | Why this property matches | |
| score | No | Fit score 1-10 | |
| session | Yes | Session hash | |
| agent_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the human sees the score and notes, implying the action is visible to the user. However, it does not mention side effects, limits, reversibility, or any required permissions for the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes instructional text directed at the agent ('You are their buyer's agent...') which, while useful, could be trimmed. The main action is front-loaded. Overall, it's well-structured but not perfectly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description provides some context (e.g., the human sees the notes) but lacks explanation of the bridge page concept, what happens after adding, and how the session parameter is used. Sibling tools like rental_session_read hint at follow-up actions but are not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%. The description reinforces the meaning of parameters (e.g., 'Include a score (1-10)') but adds little beyond the schema's own descriptions. For the undocumented parameter agent_id, the description offers no additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a property to your human's bridge page.' It specifies the tool's purpose as recommending properties as a buyer's agent. The verb 'add' is specific, and the resource 'bridge page' distinguishes it from sibling tools like rental_session_create or rental_session_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool: when recommending a property the agent truly believes fits the human's needs. It emphasizes the agent's role as a buyer's agent and instructs to include a score and notes. However, it does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools target distinct actions, but the presence of both 'search' and 'rental_search' could cause confusion, and 'fetch' overlaps slightly with 'rental_property'. However, descriptions clarify the differences.
While most tools use a 'rental_' prefix, two tools ('fetch', 'search') lack it, and the naming style varies between verb-noun and noun-only (e.g., 'rental_availability' vs 'rental_search'). This inconsistency could confuse an agent.
With 16 tools, the set covers a comprehensive range for a Caribbean rental assistant, including search, property details, pricing, availability, licensing, market intelligence, and session management. Each tool serves a clear purpose.
The tool set covers the core lifecycle (search, view details, create sessions, add picks), but lacks session update/delete functionality. Also, 'fetch' and 'search' seem redundant with rental-focused tools. Overall, the domain is well-covered for an agent workflow.