Skip to main content
Glama

Bucky

by com.buckybuild
OverviewDiscussionsAdmin

Find places by their rental market

findPlacesByMarket
Read-onlyIdempotent

Find which places to look at by their rental market: filter and rank the places Bucky sells (reviewed catalogue places) on market facts and signals. Signed-in only; read scope. Pass country (CA has data today) and a preset (CA: tight-rental, fast-rent-growth, undersupplied, mli-select-headroom), filters ({ key, min, max }, inclusive), or both; optional region (province code or name), sort, limit (default 20, max 50) and offset. An unknown key returns the filterable keys. Returns counts { places, matched, excluded, unknown }, matched places with their values, and the unknown places with their missing keys. Report the unknown count: a place missing a filtered value is not a match and not a fail. Places are compared on one survey period. truncation says what was left out: places pages with truncation.places.nextOffset as the next offset; unknown lists at most 50 places by name, counts.unknown is the total. Cite every figure with the sources lines (CMHC licence). Market data filters places, not lots: use screenLots for lots inside a place.

Input Schema

NameRequiredDescriptionDefault
sortNoDefaults to the preset sort, else the first filter key
limitNo
offsetNoMatched places to skip. Copy truncation.places.nextOffset for the next page.
presetNoA preset id for the country; its filters apply first, then `filters` by key
regionNoProvince or state, as a code (AB) or a name (Alberta)
contextYesExplain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution."
countryYesISO country code. Places are filtered and ranked only within this country.
filtersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"ISO country code. CA has market data today; US follows."New value: +"ISO country code. Places are filtered and ranked only within this country."
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Matched places to skip. Copy truncation.places.nextOffset for the next page.",
+  "maximum": 10000,
+  "minimum": 0,
+  "type": "integer"
+}
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare the safety profile, yet the description adds auth requirements, the fact that places are compared on a single survey period, pagination behavior via 'truncation.places.nextOffset', the 50-name cap on unknown lists, and the licensing/citation obligation. It also explains a non-obvious semantic: a place missing a filtered value is 'not a match and not a fail'.

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 purpose and the sibling exclusion before descending into parameters and return semantics. Dense and mostly earning its place, though a few sentences pack multiple facts and the parameter enumeration is longer than strictly necessary.

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?

With no output schema, the description fully specifies the return shape: counts { places, matched, excluded, unknown }, matched places with values, unknown places with missing keys, and truncation details. Nothing an agent needs to call or interpret results is missing.

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?

Adds real meaning beyond the 75%-covered schema: the concrete preset ids (tight-rental, fast-rent-growth, undersupplied, mli-select-headroom), 'CA has data today' for country, region as 'province code or name', and inclusive bounds for filters. Some of it repeats schema facts (limit default 20 / max 50), which 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?

Opens with a specific verb+resource ('Find which places to look at by their rental market') and clarifies the scope as 'the places Bucky sells (reviewed catalogue places)'. The closing line 'Market data filters places, not lots: use screenLots for lots inside a place' explicitly separates it from the nearest sibling.

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?

States access conditions ('Signed-in only; read scope') and names the alternative for a common confusion ('use screenLots for lots inside a place'). It also tells the agent how to discover valid filter keys ('An unknown key returns the filterable keys'). It does not cover when to prefer presets over filters or when other siblings apply, so not a full 5.

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

All Bucky 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