Bucky

Get feasibility snapshot for an address

getFeasibilitySnapshot

Read-onlyIdempotent

Look up what can be built at a specific street address in Canada or the US. Returns the lot (area, width, depth), its zone and permitted uses, and the building envelope (height, storeys, site coverage, FSR, and front/rear/side/flanking setbacks) in one call. Use when someone asks what they can build, how tall, how close to the property line, how big their lot is, or what their property is zoned for. Do not use for questions that are not about a specific address — it resolves one address at a time and cannot search or compare. Every envelope value carries a status. A null value with status no_limit_in_bylaw means the bylaw sets no limit; a null value with status not_extracted means the value is unknown to Bucky. Never report not_extracted as "no limit" or as zero.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`source`	Yes	Which question the caller is answering. Used for attribution and to pick the link back; the payload is the same either way.	full
`address`	Yes	Street address to analyse, e.g. "4170 Sophia St, Vancouver BC".
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds critical interpretive context beyond annotations: every envelope value carries a `status`, and null values must be interpreted differently depending on whether the status is `no_limit_in_bylaw` versus `not_extracted`, with an explicit warning not to report `not_extracted` as zero or no limit.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then the return payload, then usage guidance, then the crucial null-status warning. Every sentence contributes essential information, and the exclusion and status semantics are placed where they will be noticed.

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?

Even without an output schema, the description explains both the high-level return contents (lot, zone, envelope) and the nuanced `status` semantics needed to interpret values correctly. It also sets geographic scope and single-address limitation, covering what an agent needs to invoke the tool correctly and use its output accurately.

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?

The input schema already provides descriptions for all three parameters, including the `source` enum and an example address, so the description doesn't need to explain them. The description adds no parameter-specific detail beyond saying it resolves 'one address at a time,' which aligns with the address parameter.

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?

The description opens with a specific verb and resource: 'Look up what can be built at a specific street address in Canada or the US.' It lists the exact returned data (lot, zone, permitted uses, building envelope), and explicitly scopes itself away from search/compare tasks, making it easy to distinguish from siblings.

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

Usage Guidelines5/5

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

It provides explicit when-to-use guidance with concrete user questions ('what they can build, how tall, how close to the property line...'), and a direct when-not-to-use instruction ('Do not use for questions that are not about a specific address — it resolves one address at a time and cannot search or compare').

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

All Bucky tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: explanation, guide, snapshot, context, report, analysis run, save, feedback, status check, and update. The only overlap is between getProjectContext and uiGetAnalysisStatus, but the description explicitly clarifies that getProjectContext is preferred, making the distinction unambiguous.

Naming Consistency5/5

All tool names follow a consistent lowerCamelCase verb_Noun pattern (e.g., getFeasibilitySnapshot, runFeasibilityAnalysis, produceProjectReport). Minor variations like saveToProject and uiGetAnalysisStatus still adhere to the same structural style, so naming is predictable and uniform.

Tool Count5/5

With 10 tools, the server covers the full project lifecycle—lookup, creation, analysis, reporting, status, updates, and feedback—without redundancy or bloat. The count is well-scoped for the stated domain of property feasibility analysis.

Completeness4/5

Core workflows are covered: create project, attach lots/references, run analysis, retrieve context, update metadata, and generate reports. Major gaps include no list-projects operation and no delete/archive capability, though the documentation explicitly notes these are unsupported on this surface, making them expected limitations rather than operational dead ends.

Resources

Need Help?