Skip to main content
Glama

Server Details

Zoning, parcel, and development feasibility for a street address in Canada and the US.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 41 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
markbucky/bucky-plugin
GitHub Stars
0
Server Listing
Bucky

TDQS

A4/5.0

Scored across 15 tools

Disambiguation4/5

Most tools have distinct resource+action boundaries (cityInventory for city coverage, previewSiteCoverage for unauthenticated previews, getFeasibilitySnapshot for signed-in envelope numbers, screenLots for buy-box matching). The main overlap is uiGetAnalysisStatus vs getProjectContext, plus multiple project-scoped tools (runFeasibilityAnalysis, updateProject, setProjectMapListing) that share the same project-resolution pattern, but descriptions clearly steer selection in each case.

Naming Consistency4/5

All names are camelCase with a mostly predictable verb_noun pattern (getBylawSection, getFeasibilitySnapshot, updateProject, screenLots, produceProjectReport). Minor deviations exist: cityInventory is noun-only and uiGetAnalysisStatus carries a ui prefix, but the convention is largely readable and consistent.

Tool Count4/5

Fifteen tools sit at the high end of the well-scoped range but each covers a distinct facet of a genuinely rich domain (coverage, provenance, bylaw text, feasibility, projects, reports, analysis, listing, feedback). No tool feels obviously redundant except the intentionally cheap uiGetAnalysisStatus poller, which is explicitly framed as a UI-support alias.

Completeness4/5

The surface covers lookup (city/place/address), provenance explanation, bylaw text, project read/write, analysis triggering, reporting, map listing, and feedback — a full lifecycle. The one visible gap is deletion/archival of projects (updateProject explicitly does not archive or delete), and there is no bulk/list-only project listing tool, but these are workable gaps.

Available Tools

15 tools
cityInventorySee what Bucky has mapped for a cityA
Read-onlyIdempotent
Inspect

Public city catalogue inventory. Pass exactly one of: cityName, lat and lng together, or geoDivisionId. A city name with multiple matches returns choices; after the user chooses, call again with that candidate geoDivisionId. Never pass a slug. Shows datasets grouped by topic as on file, not loaded yet, unavailable, or not confirmed. This is city coverage, not lot feasibility or operator health. If Bucky has not mapped the place, the result points to recording demand. It does not record demand by itself.

ParametersJSON Schema
NameRequiredDescriptionDefault
latNo
lngNo
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."
cityNameNo
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
geoDivisionIdNo
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already carry the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavior: ambiguous city names return a candidate list that must be re-called with geoDivisionId, results classify datasets as on-file/not-loaded/unavailable/unconfirmed, and an unmapped place points to demand recording without performing it. This re-invocation loop and the 'does not record by itself' boundary are non-obvious traits not present in the annotations.

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 critical constraint (exactly one selector) is front-loaded in the second sentence, followed by the retry rule, output shape, and scope boundaries. Every sentence carries a distinct constraint or boundary; nothing is filler.

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 no output schema, the description supplies the input contract, the disambiguation loop, the shape and meaning of the result statuses, the scope boundary, and the fallback behavior. An agent could call and correctly handle this tool end-to-end from the description alone.

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 only 43% and no mutual-exclusion constraint is encoded in the schema, so the description carries meaningful weight: it states the exactly-one-of rule among cityName/lat+lng/geoDivisionId, that lat and lng must be passed together, and that slugs are invalid. That compensates for the gap on the geo parameters, though the analytics plumbing parameters (context, llm_model, conversation_id) are left entirely to the schema.

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 ('Public city catalogue inventory') and immediately scopes what it returns (datasets grouped by topic with coverage statuses). It contrasts itself against adjacent concerns ('not lot feasibility or operator health'), so an agent can separate it from previewSiteCoverage, getFeasibilitySnapshot, and explainFeasibilityStatus without opening a 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 an explicit input-selection rule ('Pass exactly one of: cityName, lat and lng together, or geoDivisionId'), a multi-match retry protocol, and an exclusion ('Never pass a slug'), plus the scope exclusion against feasibility tools. It stops short of naming the specific sibling tool an agent should call when feasibility is the actual need, so routing is implied rather than fully resolved.

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

explainFeasibilityStatusExplain a Bucky feasibility statusA
Read-onlyIdempotent
Inspect

Explain one Bucky coverage or per-fact provenance status and the safe next action. This is a pure static lookup: it does not inspect an address, retrieve property data, or call a database, geocoder, AI model, or third-party API. Accepts exactly one of: live, live_unavailable, planned_not_live, geo_division_uncatalogued, unseeded_place, geocode_failed, cited, cited_conditional, conditional_unresolved, no_limit_in_bylaw, not_extracted, site_specific_schedule, unverified_default, derived_from_cited, defaulted, missing. Copy the status verbatim from a feasibility result. An unknown status returns this list instead of failing.

ParametersJSON Schema
NameRequiredDescriptionDefault
statusYesA Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Copy it verbatim. Do not paraphrase or invent a status.
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint: true, idempotentHint: true, destructiveHint: false, and openWorldHint: false, covering safety. The description adds non-obvious behavior beyond these annotations: it is a 'pure static lookup' making no external calls, and critically, 'an unknown status returns this list instead of failing'. This error-handling detail and the explicit absence of side effects are valuable and go beyond what annotations convey.

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 compact and efficiently structured. It front-loads the core purpose in the first sentence, clarifies the non-behavior in the second, lists all valid inputs in the third, and closes with the error behavior. Every sentence earns its place; even the long enum list is necessary for correctness. No redundant or filler sentences exist.

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 static lookup tool with rich annotations and 100% schema coverage, this description is complete. It states the purpose, the exact valid inputs, the copying instruction, the lack of external calls, and the behavior for unknown statuses. Since there is no output schema, the description's phrase 'Explain ... and the safe next action' adequately hints at the return value. Nothing an agent needs to invoke it correctly is missing.

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 has 100% description coverage: each parameter (status, context, llm_model, conversation_id) is fully documented with detailed descriptions including enum values, length constraints, and privacy instructions. The tool description mainly reinforces the 'copy verbatim' instruction for the status parameter, which is already present in the schema. With such complete schema coverage, the description adds no meaning beyond the schema, so the baseline of 3 is appropriate.

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: 'Explain one Bucky coverage or per-fact provenance status' and adds 'and the safe next action'. It explicitly says 'pure static lookup' and lists what it does NOT do (address inspection, property data, database, geocoder, AI, third-party API), which sharply distinguishes it from siblings like runFeasibilityAnalysis or getBuckyMcpGuide. The enumeration of accepted inputs leaves no ambiguity about scope.

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?

The description provides clear usage context by stating it is a static lookup and instructing to 'Copy the status verbatim from a feasibility result', which tells the agent exactly how to obtain the input. It also hints at when to use this tool (when an explanation of a status is needed) versus others that perform analysis. However, it never names sibling tools or gives explicit conditions for when NOT to use this tool, so routing guidance is implied rather than stated.

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

getBuckyMcpGuideGet the Bucky MCP guideA
Read-onlyIdempotent
Inspect

Call with no arguments on first contact. Optional role, market, and scale answer the first-call questions on a second call. Returns what this session should do next.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleNoWho is asking. Answers "Developer, GC, or municipal reviewer?".
scaleNoOne site or several. Answers "Single parcel, or a portfolio?".
marketNoWhich country the site is in. Answers "US or Canada?".
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the first-call/second-call sequencing and how the optional parameters relate to the first-call questions. It does not describe the output format, but the annotations lower the burden here.

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 two sentences, front-loads the most important usage instruction, and contains no filler. Every sentence contributes either call sequencing or return-value context.

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

Completeness3/5

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

For a read-only guide tool, the description covers the key call pattern and high-level return value. However, with no output schema, the return format is left vague, and the 'no arguments' phrasing obscures the two required analytics parameters, so the description is not fully complete for correct invocation.

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

Parameters2/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, and the description does add useful meaning by labeling role, market, and scale as optional second-call arguments. However, 'Call with no arguments on first contact' directly contradicts the schema's required context and llm_model, creating real risk that an agent invokes the tool without required parameters.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Returns what this session should do next,' naming a specific resource and the expected output. It does not explicitly distinguish itself from sibling tools, but its role as a session-orientation/guide tool is evident from the name and the sibling set.

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

Usage Guidelines3/5

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

The description gives explicit timing guidance: 'Call with no arguments on first contact' and use optional role/market/scale on a second call. However, it offers no alternatives or exclusions, and the 'no arguments' instruction conflicts with the schema's required context and llm_model parameters, making the guidance partially misleading.

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

getBylawSectionGet cited bylaw section textA
Read-onlyIdempotent
Inspect

Return the stored bylaw section text behind a snapshot citation. Pass sectionIds copied from citations.*.knowledgeSectionId on getFeasibilitySnapshot. Or pass geoDivisionId from coverage.geoDivisionId, zoneCode from zone.code, and sectionNumbers such as 3.1 or 3.2. The markdown is the schedule text. A number in the snapshot can still be conditional on frontage, tenure, or adjoining district. Ids or section numbers with no active chunk come back in missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
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."
zoneCodeNozone.code from getFeasibilitySnapshot, for example C-2.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
sectionIdsNoCopy citations.*.knowledgeSectionId from getFeasibilitySnapshot. 1 to 4 ids.
geoDivisionIdNocoverage.geoDivisionId from getFeasibilitySnapshot.
sectionNumbersNoSection numbers to read, for example 3.1 or 3.2. 1 to 4 numbers.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds real behavioral context beyond them: the returned content is markdown schedule text, cited numbers may be conditional on frontage/tenure/adjoining district, and unresolvable ids/section numbers surface in a `missing` field.

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?

Five tight sentences, front-loaded with what is returned and then the two lookup routes. Every sentence carries distinct information — source paths, return format, the conditional caveat, and the `missing` behavior — with no filler.

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 7-parameter, two-mode lookup tool with no output schema, the description covers the return shape (markdown text plus a `missing` field), the alternative input routes, and the semantic caveat about conditional numbers. The plumbing parameters (context, llm_model, conversation_id) are self-documented in the schema.

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, but the description adds meaning the schema does not: it identifies the exact source paths for `sectionIds`, `geoDivisionId`, and `zoneCode`, gives examples like 3.1/3.2 for `sectionNumbers`, and frames the uuid group versus the geo/zone/numbers group as alternatives.

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 ('Return the stored bylaw section text') and ties it to a concrete upstream source ('behind a snapshot citation'). This clearly distinguishes it from getFeasibilitySnapshot, which produces the citations it consumes.

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 two explicit invocation paths: either pass `sectionIds` copied from getFeasibilitySnapshot's citations, or pass the geoDivisionId/zoneCode/sectionNumbers trio. It does not state whether the two paths can be combined or what happens if neither matches, so the 'when-not' case is left implicit.

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

getFeasibilitySnapshotGet feasibility snapshot for an addressA
Read-onlyIdempotent
Inspect

Look up lot, zone, and building envelope for one street address in Canada or the US. Pass address. One address per call; cannot search or compare. Every envelope value carries a status. Never report not_extracted or site_specific_schedule as no limit or as zero — call explainFeasibilityStatus first. Envelope numbers are extracted ceilings. Call getBylawSection with a citation knowledgeSectionId, or with coverage.geoDivisionId, zone.code, and the section number, before treating a number as available on this lot. Do not fetch zone.bylawSourceUrl.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesWhich question the caller is answering. Used for attribution and to pick the link back; the payload is the same either way.full
addressYesStreet address to analyse, e.g. "4170 Sophia St, Vancouver BC".
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial behavior beyond them: every envelope value carries a status, envelope numbers are 'extracted ceilings' rather than authoritative limits, and there are required follow-up calls before the data can be relied upon. This is exactly the kind of caveat an agent cannot infer from annotations.

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-loaded purpose followed by tightly packed, actionable constraints. Slightly dense and list-like, but every sentence carries a distinct behavioral rule, so little is wasted.

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

Completeness4/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 does the heavy lifting on return-value semantics (status on every envelope value) and cross-tool workflow. It stops short of describing the full payload shape, but the critical gotchas an agent needs to avoid misreporting numbers are all present.

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 adds a little ('Pass address') but its main value is naming output-side fields (knowledgeSectionId, coverage.geoDivisionId, zone.code, zone.bylawSourceUrl) that drive sibling calls, which gives the agent context beyond the input schema without fully documenting the structured parameters.

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+scope: 'Look up lot, zone, and building envelope for one street address in Canada or the US.' An agent can immediately tell this is a per-address feasibility lookup rather than a batch/search tool, and the scope constraint ('one address, cannot search or compare') further distinguishes it from siblings like runFeasibilityAnalysis or screenLots.

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?

Explicit routing: call explainFeasibilityStatus before treating not_extracted or site_specific_schedule as a limit, and call getBylawSection with specific keys before treating a number as available. Also states a clear exclusion ('Do not fetch zone.bylawSourceUrl') and the one-address-per-call constraint.

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

getProjectContextGet project context bundleA
Read-onlyIdempotent
Inspect

Load one project with analysis envelope, compact agentStatus, document summaries, evidence summaries, the project memory digest, and external_ref when the project was imported from another system. Pass include for optional sections: tasks, members, insights, capital, visualEvidence. Default is none, so the payload stays the same as a call without include. Writes to those sections stay on the Bucky CLI. You do not need a UUID: pass project with the name the user said, or call with neither and the result lists their projects to choose from. Use before composing reports or after scheduling analysis.

ParametersJSON Schema
NameRequiredDescriptionDefault
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."
includeYesOptional extra sections. Default is none, so the payload matches a call without include. tasks, members, insights, capital, and visualEvidence each reuse the matching product read — they are not separate tools. Writes stay on the Bucky CLI.
projectNoProject name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoProject UUID. Omit if you pass `project`.
evidenceLimitYes
documentsLimitYes
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new behavioral facts: default `include` yields a stable payload, writes to those sections stay on the Bucky CLI, and name matching prefers exact over partial and lists candidates on ambiguity. It omits rate/limit or auth behavior.

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-loaded with the returned payload then the parameter guidance, and every sentence carries information. It is on the long side but not padded, with no restatement of the name or title.

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

Completeness4/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 compensates by enumerating exactly what the bundle contains, and it covers the optional include sections and identity fallback. Only the odd required telemetry parameters (context, llm_model) are left entirely to the schema.

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 75%, and the description adds real meaning for the two ambiguous parameters: `include` semantics (default none, sections reuse matching product reads rather than separate tools) and `project` matching rules. It does not explain the telemetry-style required fields, which the schema handles.

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 ('Load one project') and enumerates the exact bundle contents (analysis envelope, agentStatus, document/evidence summaries, memory digest, external_ref). An agent can distinguish this from siblings like produceProjectReport or runFeasibilityAnalysis without reading 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 explicit timing ('Use before composing reports or after scheduling analysis') and handles the identity ambiguity ('pass `project` with the name the user said, or call with neither and the result lists their projects'). It does not name an alternative sibling by name, keeping it short of a 5.

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

previewSiteCoveragePreview what Bucky has on file for an addressA
Read-onlyIdempotent
Inspect

Free preview, no sign-in needed. For one street address in Canada or the US, it says whether Bucky covers the place and which zoning facts it holds for the lot (lot boundary, zone, height, density, setbacks, permitted uses, overlays, parking): found, partly on file, or not on file. It returns no values: no zone code, heights, setbacks or areas. The lot outline is a shape with no scale. Use it when the user is not signed in and asks what they can build at an address. For the numbers, call getFeasibilitySnapshot. That call asks the user to sign in.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesStreet address to analyse, e.g. "4170 Sophia St, Vancouver BC".
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.6/5.0
Behavior5/5

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

The description adds meaningful behavioral context beyond the annotations: no sign-in needed, returns no numerical values, the lot outline has no scale, and the result is a coverage indicator rather than actual zoning data. It goes beyond the readOnly/idempotent hints and does not contradict them.

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 most important facts (free, no sign-in, geographic scope) and then moves to output semantics, use-case, and the alternative tool. Every sentence earns its place; the zoning-facts list is detailed but directly relevant to what the tool returns.

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

Completeness4/5

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

Given the absence of an output schema, the description does a good job explaining the output: coverage statuses, no values, and a shape with no scale. It also covers prerequisites (no sign-in) and the alternative for numeric results. Minor ambiguity remains about the exact structure of the per-fact statuses and error behavior for unsupported or invalid addresses.

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%, so the schema already documents all parameters. The description adds helpful scope constraints for the address (Canada/US, street address) and implies the preview is read-only, but adds no additional meaning for context, llm_model, or conversation_id beyond what the schema provides.

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 names a specific verb, resource, and scope: it previews what Bucky has on file for one US/Canada street address. It clearly defines the output as coverage statuses (found, partly, not) for a concrete list of zoning facts. This distinguishes it from getFeasibilitySnapshot, which returns numeric values.

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?

The description explicitly says to use this tool when the user is not signed in and asks what they can build at an address. It also names the alternative, getFeasibilitySnapshot, and notes that alternative requires sign-in. This gives an agent a clear decision rule for tool selection.

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

produceProjectReportCompose and export a project report PDFA
Idempotent
Inspect

Compose a project report PDF. Pass projectId or project; with neither, the result lists projects and no meter is spent. preview=true composes without spending. confirm=true exports, spends records.exports, and is irreversible. Returns a signed download URL, never PDF bytes.

ParametersJSON Schema
NameRequiredDescriptionDefault
detailYesdetailed
confirmYesWhen true, compose (if needed), save, export PDF, and return a download URL. Required when preview is false. Spends records.exports and cannot be undone.
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."
previewYesWhen true, compose only — no export meter spend and no download URL.
projectNoProject name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.
requestNo
audienceYesowner
planNameNo
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoProject UUID. Omit if you pass `project`.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A3.5/5.0
Behavior1/5

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

The description claims confirm=true 'spends records.exports, and is irreversible', which directly contradicts the annotations' idempotentHint=true and destructiveHint=false. An irreversible meter-spending operation is neither idempotent nor non-destructive from the caller's perspective. This is a clear annotation contradiction, so the score is minimal.

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 a single, tight paragraph that front-loads the core action and then clarifies the critical decision points (project selection, preview vs confirm, return format). Every sentence carries essential information with no filler.

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

Completeness3/5

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

For an 11-parameter tool with no output schema, the description covers the key control flow (preview/confirm, project matching, URL return) but omits details about several parameters (request, planName, audience, detail, conversation_id). The schema provides some descriptions, but the lack of guidance on how these parameters interact (e.g., how request relates to report content) leaves gaps. An agent would need to infer several parameter meanings from the schema alone.

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 description adds meaning for projectId/project selection, preview, and confirm beyond the schema, particularly the meter-spend and irreversibility of confirm. However, it does not elaborate on request, planName, audience, detail, or conversation_id. Schema coverage is 64%, so the description partially compensates but leaves the remaining parameters to the schema's own descriptions.

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 states a specific action (compose and export a project report PDF) and resource, and distinguishes between preview and confirm modes. It also clarifies the return type (signed URL, not bytes) and the fallback behavior when neither projectId nor project is provided. No sibling tool overlaps with this function, so the purpose is 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?

The description explicitly explains when to use preview=true (compose without spending) vs confirm=true (export, spends meter, irreversible). It also notes that omitting both projectId and project lists projects without spending. However, it does not mention when to avoid using the tool entirely or direct alternatives, though the clear mode guidance suffices for most calls.

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

runFeasibilityAnalysisRun project feasibility analysisAInspect

Enqueue a fresh deterministic analysis run for a saved project. Pass projectId, or project with the name the user said; with neither, the result lists their projects and nothing is queued. Returns immediately with agentStatus (queued, running, current, failed, or none) and a receipt id; does not block on completion. Irreversible: a queued run cannot be un-queued from MCP. Re-check with getProjectContext, but no more than once every 15 seconds — it is a multi-query bundle, not a status endpoint.

ParametersJSON Schema
NameRequiredDescriptionDefault
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."
projectNoProject name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoProject UUID. Omit if you pass `project`.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations provide readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the critical behavioral trait that it returns immediately and does not block on completion, which is beyond the annotations. It also states that a queued run is irreversible, which is important behavioral context. However, it doesn't fully explain the failure modes or what happens if the project is not found, but it does cover the key behavior. The description also adds the deterministic nature, which is useful. Slight deduction for not detailing error handling, but overall strong.

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 compact yet dense, with critical information front-loaded: it starts with the action, then the identification options, then the return behavior, and ends with the polling limitation. Every sentence adds value, and it is appropriately sized for a tool with multiple important caveats.

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?

Given the complexity of the tool (5 parameters, async behavior, irreversible action, polling guidance), the description covers everything an agent needs to know to call it correctly. It explains the return value, the non-blocking nature, the irreversibility, the polling constraint, and the identification logic. No output schema exists, but the description explains the return fields. This is comprehensive.

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 description coverage is 100%, so the schema already documents all five parameters. The description adds guidance on using project vs projectId and the fallback behavior, which is beyond the schema. It also explains the context and llm_model parameters are for analytics only. This adds value, but the schema already covers the basics, so a 3 is appropriate.

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 states a specific verb ('enqueue'), resource ('fresh deterministic analysis run'), and target ('saved project'). It distinguishes from siblings by noting it is a queueing operation that returns immediately, unlike status endpoints like getProjectContext or uiGetAnalysisStatus. It also clarifies the deterministic nature and the project identification alternatives, making it clearly different from other project-related tools.

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?

The description explicitly explains when to use this tool: when you have a projectId or a project name, and states the fallback behavior if neither is given. It also gives guidance on re-checking with getProjectContext but limits to once every 15 seconds, noting it is a multi-query bundle. This provides clear context for when to use versus alternatives.

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

saveToProjectCreate or attach to a projectA
Idempotent
Inspect

Create a project (create), attach lots (attach_parcels), or attach a knowledge reference (attach_reference). Pass projectId or project; with neither, the result lists projects and writes nothing. For attach_parcels, copy lot.parcelExternalId from getFeasibilitySnapshot. preview=true returns the diff and writes nothing. A write returns a receipt. Not reversible on this surface.

ParametersJSON Schema
NameRequiredDescriptionDefault
latNoLatitude from getFeasibilitySnapshot. Supplied coordinates are never re-geocoded.
lngNoLongitude from getFeasibilitySnapshot.
nameNo
roleNobuild is the lot being developed; context is surrounding land. Default build.
actionYescreate: new project from a site. attach_parcels: attach lots to an existing project (use lot.parcelExternalId from getFeasibilitySnapshot). attach_reference: link a knowledge section to an existing project.
addressNoStreet address of the site. On `create` this is geocoded server-side when lat/lng are not supplied, and is what gets recorded as the project address.
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."
previewYesWhen true, return the field-level diff and write nothing.
projectNoProject name to match instead of a UUID, for attach_parcels and attach_reference. Matching more than one lists the candidates instead of guessing. Ignored by create.
radiusMNoSearch half-width in metres when resolving parcel ids. Default 150.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoExisting project UUID. Required by attach_parcels and attach_reference unless you pass `project`; ignored by create.
externalRefNoProvenance of an imported project. Canonical form is `<system>:<id>` (e.g. `notion:<page-id>`). Unique per creator when set. Returned on getProjectContext. Distinct from idempotencyKey.
sectionUuidNo
idempotencyKeyNo
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.
parcelExternalIdsNoSource parcel ids to attach. Copy lot.parcelExternalId from getFeasibilitySnapshot. If they are not in the current area, pass a larger radiusM on attach_parcels.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that listing mode writes nothing, preview=true writes nothing, writes return a receipt, and operations are not reversible on this surface. This goes well beyond readOnlyHint/idempotentHint/destructiveHint and gives agents important side-effect knowledge.

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?

Five dense sentences with no fluff: the action list is front-loaded, then critical conditions (projectId/project, preview, receipt, reversibility) follow. Every sentence carries decision-relevant information.

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

Completeness4/5

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

For a 17-parameter tool with no output schema, the description covers the highest-risk behaviors: write suppression, project resolution, non-reversibility, and source of parcel IDs. It does not discuss sequencing constraints like conversation_id or idempotencyKey, but those are well documented in the schema.

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 high (82%), and the description adds cross-parameter meaning not in the schema: how projectId/project relate to actions, the source of parcelExternalIds, and the preview write-suppression behavior. This exceeds the baseline expected with such coverage.

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 names three concrete operations (create, attach_parcels, attach_reference) and a fallback listing behavior, each tied to a specific action value. This clearly differentiates the tool's multi-purpose behavior from siblings like updateProject and getProjectContext.

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?

It gives actionable routing rules: pass projectId or project for attach actions, and with neither it lists projects and writes nothing. It also tells agents to copy lot.parcelExternalId from getFeasibilitySnapshot and explains preview behavior. It does not explicitly name when to prefer a sibling tool, but the action-level guidance is strong.

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

screenLotsFind lots that match a buy boxInspect

Find the lots in one live Bucky city that match a buy box. Pass city or geoDivisionId with thesis (plain words), criteria (square feet, dollars), or both; or pass a saved profileId. Returns the total match count, the top lots ranked largest first with a pass, fail, or not_available verdict per filter, and every filter this city cannot apply. Report a not_available filter; never present the count as filtered by it. Each lot has address for getFeasibilitySnapshot and parcelExternalId for saveToProject. save=true saves the box (write scope) and returns a CSV link.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoCity as the user said it, e.g. "Laval" or "Bedford, MA". Omit when you pass geoDivisionId or profileId.
saveNotrue saves the buy box to the account. Default false: nothing is written.
limitNoLots to return. Default 10. The total match count is always returned.
thesisNoThe buy box in plain words, e.g. "industrial lots over half an acre outside the floodplain".
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."
criteriaNoStructured criteria. A field set here replaces the same field read from thesis.
saveNameNoName for a saved box.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
profileIdNoSaved buy box id. Runs the saved city and criteria. Do not combine with city, thesis, or criteria.
geoDivisionIdNoDivision id, from an earlier screenLots or cityInventory result.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.
setProjectMapListingList or unlist a project on the public mapA
Idempotent
Inspect

Put a project on the public Bucky map, or take it off. Pass projectId, or project with the name the user said; with neither, the result lists their projects and nothing is published. Listing publishes the build-lot centroid, the project name, its zone category, typology and lifecycle status to anyone — signed in or not. Nothing else about the project is published. The project must have a build lot with a centroid; a project that has only an address and no attached build parcel cannot be pinned. Ask the human before listing a site that is not already public knowledge. A client, a friend, or a private residence is theirs to publish, not yours. preview=true returns the current state, the exact pin that would be published, and any privacy warning, and writes nothing. Unlisting removes the pin but does not un-share anything already collected while it was public.

ParametersJSON Schema
NameRequiredDescriptionDefault
listedYestrue lists the project on the public map; false removes it. Listing publishes the build-lot centroid and the project name to anyone, signed in or not.
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."
previewYesWhen true, return the current listing state, the pin that would be published, and any privacy warning, and write nothing.
projectNoProject name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoProject UUID. Omit if you pass `project`.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint false, destructiveHint false, idempotentHint true), the description discloses exactly what gets published and to whom (centroid, project name, zone category, typology, lifecycle status to anyone), confidently states that nothing else is published, explains preview's no-write guarantee, and warns that unlisting does not un-share previously collected data. This is far richer than the annotations alone.

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 appropriately sized for a privacy-critical tool. Every sentence earns its place: purpose, identification modes, public-leak scope, precondition, human-consent rule, preview behavior, and unlisting nuance. The core purpose is front-loaded, and there is no filler or repetition of schema fields.

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?

Given the tool's complexity and the absence of an output schema, the description covers all essential contextual information: both call modes, the no-identifier fallback, the exact published fields, the prerequisite for pinning, the preview safety valve, and the limitation that unlisting does not retract previously collected data. An agent has everything it needs to decide and invoke correctly.

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 adds important semantic context beyond the schema: it explains how projectId and project relate (use either one), what happens when neither is passed (result lists their projects and publishes nothing), and confirms preview=true writes nothing. This meaningfully clarifies parameter selection and fallback behavior.

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 dual-action verb phrase, 'Put a project on the public Bucky map, or take it off', naming the exact resource (public Bucky map) and operation (list/unlist). This clearly separates it from sibling tools like updateProject or saveToProject, which concern editing or saving rather than map visibility.

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?

The description gives rich usage guidance: pass projectId or project name, the fallback behavior when neither is supplied, a hard prerequisite (build lot with centroid, so projects with only an address cannot be pinned), and the important ethical rule to ask the human before publishing a non-public site. It lacks explicit naming of alternative sibling tools, which is why it is not a 5.

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

submitBuckyFeedbackSubmit feedback to BuckyA
Idempotent
Inspect

Open a human-reviewed feedback form and submit it to the Bucky product team. Call only when the user explicitly asks to send feedback, report a problem, suggest an improvement, or praise something. The server asks the MCP client to show the form; nothing is saved unless the human accepts it. Do not use for silent agent self-reporting.

ParametersJSON Schema
NameRequiredDescriptionDefault
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
submissionIdNoOptional. A UUID for this submission; generated server-side when omitted. Pass the same UUID when retrying this exact feedback so it is not recorded twice.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.
affectedToolNameNoTool the user is commenting on, when already known

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses that the tool opens an interactive form requiring human acceptance, and that nothing is saved unless the human accepts. This goes beyond the annotations (idempotentHint, readOnlyHint, destructiveHint) by explaining the human-in-the-loop nature, which is critical for the agent to understand the tool's behavior.

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 concise and front-loaded: it states the core purpose first, then usage conditions, then the interaction model. Every sentence adds value, with no redundant or generic phrasing. It is appropriately sized for the tool's complexity.

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 tool with no output schema, the description covers the essential interaction (form display, human acceptance) and usage boundaries. Combined with the detailed parameter schema, an agent has everything needed to decide when to call it and what to expect. No critical missing context.

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 100% description coverage for all 5 parameters, including detailed guidance on the required 'context' and 'llm_model' fields. The tool description adds no extra parameter-level meaning, so a baseline score of 3 is appropriate per the rubric.

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 clearly states a specific verb ('Open a human-reviewed feedback form and submit it') and resource ('Bucky product team'), and distinguishes it from silent self-reporting. It makes the tool's purpose unmistakable even without the title.

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?

The description explicitly lists the exact user intents that warrant calling this tool ('send feedback, report a problem, suggest an improvement, or praise something') and gives a hard exclusion ('Do not use for silent agent self-reporting'). This leaves no ambiguity about when to use it.

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

uiGetAnalysisStatusGet analysis statusA
Read-onlyIdempotent
Inspect

Return only the analysis agentStatus for a project. Cheap enough to poll. Used by the Bucky app view; the model should call getProjectContext instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
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."
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdYes
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it's cheap to poll and returns only the agentStatus, which is behavioral context beyond the annotations. No contradictions. It doesn't discuss error handling or rate limits, but those are minor given the safety annotations.

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?

Two sentences with no waste. The core purpose is stated first, followed by usage guidance and the alternative tool. Everything is front-loaded and directly useful.

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

Completeness4/5

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

The tool is simple (returns a single status field), and annotations cover safety. The description specifies purpose, usage context, and the alternative tool. It doesn't describe the range of agentStatus values or response format, but the absence of an output schema makes that less critical. Overall, it's sufficiently complete for an agent to call it correctly.

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 description coverage is 75% (context, llm_model, conversation_id are documented; projectId is not but its name/format are clear). The description adds no parameter-specific information, so it stays at the baseline for high schema coverage. It doesn't repeat schema details, which is appropriate.

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 ('Return'), resource ('analysis agentStatus'), and scope ('for a project'). It also distinguishes itself from siblings by naming getProjectContext as the preferred alternative, making its purpose unambiguous.

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?

Explicitly says it's used by the Bucky app view and instructs the model to call getProjectContext instead, which is clear guidance on when to use this tool vs. the alternative. Also notes it's cheap to poll, giving a concrete usage context.

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

updateProjectUpdate project fieldsA
Idempotent
Inspect

Patch project metadata (name, lifecycle status, externalRef). Pass projectId, or project with the name the user said; with neither, the result lists their projects and nothing is written. preview=true returns the field-level diff and writes nothing. A write returns a receipt; undoOperationId restores the captured prior fields. Does not archive or delete.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo
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."
previewYesWhen true, return the field-level diff and write nothing. Combined with undoOperationId, returns the stored receipt.
projectNoProject name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
projectIdNoProject UUID. Omit if you pass `project`.
externalRefNoProvenance of an imported project. Canonical form is `<system>:<id>` (e.g. `notion:<page-id>`). Unique per creator when set. Pass null to clear.
conversation_idNoEcho the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.
lifecycleStatusNo
undoOperationIdNoReceipt id from a prior updateProject write. Restores the captured prior fields. With preview=true, inspects the receipt instead.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), it reveals fallback listing behavior, preview diff mode with no write, receipt return, undo semantics via undoOperationId, and explicit non-destruction. This gives the agent a trustworthy mental model of side effects.

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?

Four dense sentences, front-loaded with the patchable fields and immediately followed by target selection. Every sentence adds a distinct behavioral fact; there is no filler or redundant repetition of schema content.

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 10-parameter tool with no output schema, it covers return behavior in all operational modes: no match leads to a project list, preview yields a diff, write yields a receipt, and undo restores prior fields. Remaining gaps such as lifecycleStatus allowed values are left to domain knowledge and do not undermine callability.

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 80%, so the baseline is 3. The description adds meaning the schema does not: omitting projectId/project lists projects and writes nothing, and preview can inspect an existing undo receipt. This complements rather than repeats the schema definitions.

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 'Patch project metadata' naming specific fields (name, lifecycle status, externalRef) and closes with 'Does not archive or delete', making the resource and mutation scope clear. This separates it from report, feasibility, and listing tools in the sibling set.

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 explicit selection rules: pass projectId, or project with the name the user said; with neither, it lists projects and writes nothing; preview=true suppresses writes. However, it never names an alternative sibling tool such as saveToProject or states when not to call this one, so exclusions are absent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • ChangedscreenLots2 fields changed
      • addedInput schema / properties / criteria / properties / hydrant_distance
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Metres from the lot line to the nearest fire hydrant.",
        +  "properties": {
        +    "max": {
        +      "maximum": 5000,
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "maximum": 5000,
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • changedInput schema / properties / criteria / properties / stories / description
        Previous value: -"Above-grade stories of the main building as the assessor records them; half stories are decimals (1.5). \"1-2 story\" is { max: 2 }."New value: +"Above-grade stories: the assessor count where recorded (half stories are decimals, 1.5), otherwise estimated from building height at 3 m per storey. \"1-2 story\" is { max: 2 }."
  2. 1 tool update
    • ChangedscreenLots6 fields changed
      • addedInput schema / properties / criteria / properties / building_use
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "What the lot is used for today, read from the assessor's use code: office, mixed_use, retail, hospitality, industrial, multifamily, two_to_four_family, single_family, institutional, civic, religious, parking, vacant_land, other. \"Commercial buildings, not houses or churches\" is { any_of: [\"office\", \"mixed_use\", \"retail\"] } or { none_of: [\"single_family\", \"two_to_four_family\", \"religious\", \"civic\"] }.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 20,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 20,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / exterior_material
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "The assessor's primary exterior wall as a family: masonry, wood, siding, stucco, concrete, metal, glass, other. \"Brick buildings\" is { any_of: [\"masonry\"] }.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / register_status
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Historic register status: individually_listed, contributing, non_contributing, in_district (inside a register district, building not yet mapped), not_listed. \"On the register\" is { any_of: [\"individually_listed\", \"contributing\"] }. Register status is a research lead, not tax-credit eligibility. The federal 20% credit needs a certified historic structure; building age alone qualifies for nothing (the 10% pre-1936 credit was repealed in 2017).",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / stories
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Above-grade stories of the main building as the assessor records them; half stories are decimals (1.5). \"1-2 story\" is { max: 2 }.",
        +  "properties": {
        +    "max": {
        +      "maximum": 200,
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "maximum": 200,
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / street
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Street names as the lot address carries them, upper case with the suffix abbreviated: \"STATE ST\", \"BANK ST\". { any_of: [...] } keeps lots on those streets. Matches the lot's address, not every street it touches: a corner lot counts once.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 50,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 50,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • changedInput schema / properties / thesis / maxLength
        Previous value: -500New value: +1500
  3. 1 tool update
    • ChangedscreenLots2 fields changed
      • addedInput schema / properties / criteria / properties / frequent_transit_distance
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Metres from the lot line to the nearest frequent bus stop or rapid-transit station.",
        +  "properties": {
        +    "max": {
        +      "maximum": 5000,
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "maximum": 5000,
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • changedInput schema / properties / criteria / properties / zone_family / description
        Previous value: -"The zone's dominant use from the Québec zone letter: residential (H), mixed (M), commercial (C), industrial (I), public (P, U), recreation (R), agricultural (A), forest (F). \"Zoned residential or mixed\" is { any_of: [\"residential\", \"mixed\"] }. Québec cities only. The letter names the dominant use; the zone grid still decides which uses are permitted."New value: +"The zone's dominant use: residential, mixed, commercial, industrial, public, recreation, agricultural, forest. \"Zoned residential or mixed\" is { any_of: [\"residential\", \"mixed\"] }. Québec zones read the zone letter (H, M, C, I, P/U, R, A, F); other zones a family classified from the zone name and purpose. The family names the dominant use; the bylaw still decides which uses are permitted."
  4. 1 tool update
    • ChangedscreenLots3 fields changed
      • changedInput schema / properties / criteria / properties / improvement_land_ratio / description
        Previous value: -"Assessed building (improvement) value divided by land value, as a ratio: 0.25 = the building is worth a quarter of the land. A teardown screen is { max: 0.25 }."New value: +"Building (improvement) value divided by land value, assessed or appraised, as a ratio: 0.25 = the building is worth a quarter of the land. A teardown screen is { max: 0.25 }."
      • changedInput schema / properties / criteria / properties / overlayExcludeKinds / description
        Previous value: -"Overlay kinds a lot must be outside."New value: +"Overlay kinds a lot must not overlap. A lot passes only if it was evaluated for every excluded kind; an unevaluated kind is reported not_available."
      • changedInput schema / properties / criteria / properties / overlayKinds / description
        Previous value: -"Overlay kinds a lot must be inside."New value: +"Overlay kinds a lot must overlap by at least 1 m². A kind the city has not evaluated is reported not_available, never applied."
  5. 1 tool update
    • ChangedscreenLots3 fields changed
      • changedInput schema / properties / criteria / properties / existing_use_class / description
        Previous value: -"What stands on the lot: place_of_worship (church, temple, mosque, synagogue…), fuel_station, auto_service (repair, body, car wash), auto_sales (car dealer), else vacant, surface_parking or built. \"Vacant lots or surface parking\" is { any_of: [\"vacant\", \"surface_parking\"] }; \"gas stations\" is { any_of: [\"fuel_station\"] }; \"church sites\" is { any_of: [\"place_of_worship\"] }. Vacant means no building over 20 m² in any footprint source and no assessed building worth over 20% of the land. A mapped business on the lot wins over the footprint class. Fuel and auto-service sites are a contamination risk flag, not a site investigation."New value: +"What stands on the lot: place_of_worship (church, temple, mosque, synagogue…), fuel_station, auto_service (repair, body, car wash), auto_sales (car dealer), else vacant, surface_parking or built. \"Vacant lots or surface parking\" is { any_of: [\"vacant\", \"surface_parking\"] }; \"gas stations\" is { any_of: [\"fuel_station\"] }; \"church sites\" is { any_of: [\"place_of_worship\"] }. Vacant means no building over 20 m² in any footprint source and no assessed building worth over 20% of the land. Québec lots without footprints use the assessment roll land-use code (CUBF 9100 = vacant). A mapped business on the lot wins over the footprint class. Fuel and auto-service sites are a contamination risk flag, not a site investigation."
      • addedInput schema / properties / criteria / properties / subdivision_yield
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Lot area divided by the zone's minimum lot area: how many minimum-size lots the parcel could hold by area. \"Could be subdivided\" is { min: 2 }; \"into 3 lots\" is { min: 3 }. Ignores frontage, streets and lot shape: a candidate, not a subdivision approval.",
        +  "properties": {
        +    "max": {
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / zone_family
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "The zone's dominant use from the Québec zone letter: residential (H), mixed (M), commercial (C), industrial (I), public (P, U), recreation (R), agricultural (A), forest (F). \"Zoned residential or mixed\" is { any_of: [\"residential\", \"mixed\"] }. Québec cities only. The letter names the dominant use; the zone grid still decides which uses are permitted.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
  6. 1 tool update
    • ChangedscreenLots2 fields changed
      • changedInput schema / properties / criteria / properties / existing_use_class / description
        Previous value: -"What stands on the lot: fuel_station, auto_service (repair, body, car wash), auto_sales (car dealer), else vacant, surface_parking or built. \"Vacant lots or surface parking\" is { any_of: [\"vacant\", \"surface_parking\"] }; \"gas stations\" is { any_of: [\"fuel_station\"] }. Vacant means no building over 20 m² in any footprint source and no assessed building worth over 20% of the land. A mapped business on the lot wins over the footprint class. Fuel and auto-service sites are a contamination risk flag, not a site investigation."New value: +"What stands on the lot: place_of_worship (church, temple, mosque, synagogue…), fuel_station, auto_service (repair, body, car wash), auto_sales (car dealer), else vacant, surface_parking or built. \"Vacant lots or surface parking\" is { any_of: [\"vacant\", \"surface_parking\"] }; \"gas stations\" is { any_of: [\"fuel_station\"] }; \"church sites\" is { any_of: [\"place_of_worship\"] }. Vacant means no building over 20 m² in any footprint source and no assessed building worth over 20% of the land. A mapped business on the lot wins over the footprint class. Fuel and auto-service sites are a contamination risk flag, not a site investigation."
      • addedInput schema / properties / criteria / properties / place_of_worship
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "true: a church, temple, mosque, synagogue or other place of worship is mapped on the lot (OpenStreetMap, city heritage registers). { is: false } excludes those lots. Same lots as existing_use_class place_of_worship.",
        +  "properties": {
        +    "is": {
        +      "type": "boolean"
        +    }
        +  },
        +  "required": [
        +    "is"
        +  ],
        +  "type": "object"
        +}
  7. 1 tool update
    • ChangedscreenLots7 fields changed
      • addedInput schema / properties / criteria / properties / contamination_risk
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "true: a gas station or auto-service business (repair, body shop, car wash) is mapped on the lot. { is: false } excludes those lots. A risk flag from OpenStreetMap and city business licences, not a site investigation: it misses former and unmapped businesses.",
        +  "properties": {
        +    "is": {
        +      "type": "boolean"
        +    }
        +  },
        +  "required": [
        +    "is"
        +  ],
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / existing_coverage_pct
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Building footprint area on the lot as a percentage of lot area, 0-100. An underbuilt screen is { max: 20 }. Footprints can be years old: check the city honesty note.",
        +  "properties": {
        +    "max": {
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / existing_use_class
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "What stands on the lot: fuel_station, auto_service (repair, body, car wash), auto_sales (car dealer), else vacant, surface_parking or built. \"Vacant lots or surface parking\" is { any_of: [\"vacant\", \"surface_parking\"] }; \"gas stations\" is { any_of: [\"fuel_station\"] }. Vacant means no building over 20 m² in any footprint source and no assessed building worth over 20% of the land. A mapped business on the lot wins over the footprint class. Fuel and auto-service sites are a contamination risk flag, not a site investigation.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / improvement_land_ratio
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Assessed building (improvement) value divided by land value, as a ratio: 0.25 = the building is worth a quarter of the land. A teardown screen is { max: 0.25 }.",
        +  "properties": {
        +    "max": {
        +      "minimum": 0,
        +      "type": "number"
        +    },
        +    "min": {
        +      "minimum": 0,
        +      "type": "number"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / ownership_form
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Ownership form: fee_simple (land title), strata_condo, co_op, leasehold, mixed. \"Land title only\" is { none_of: [\"strata_condo\", \"co_op\", \"leasehold\", \"mixed\"] }, which keeps lots whose form is unknown; any_of drops them.",
        +  "properties": {
        +    "any_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    },
        +    "none_of": {
        +      "items": {
        +        "maxLength": 256,
        +        "minLength": 1,
        +        "type": "string"
        +      },
        +      "maxItems": 10,
        +      "type": "array"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / titled_unit_count
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Titled units on the parcel: 1 for a land-title lot, the strata unit count otherwise.",
        +  "properties": {
        +    "max": {
        +      "maximum": 100000,
        +      "minimum": 1,
        +      "type": "integer"
        +    },
        +    "min": {
        +      "maximum": 100000,
        +      "minimum": 1,
        +      "type": "integer"
        +    }
        +  },
        +  "type": "object"
        +}
      • addedInput schema / properties / criteria / properties / year_built
        Added value: +{
        +  "additionalProperties": false,
        +  "description": "Year the main building was built, inclusive bounds.",
        +  "properties": {
        +    "max": {
        +      "maximum": 2100,
        +      "minimum": 1600,
        +      "type": "integer"
        +    },
        +    "min": {
        +      "maximum": 2100,
        +      "minimum": 1600,
        +      "type": "integer"
        +    }
        +  },
        +  "type": "object"
        +}
  8. 2 tool updates
    • AddedgetBylawSection
    • AddedscreenLots
  9. 2 tool updates
    • ChangedcityInventory3 fields changed
      • removedInput schema / anyOf
        Removed value: -[
        -  {
        -    "additionalProperties": false,
        -    "properties": {
        -      "cityName": {
        -        "maxLength": 100,
        -        "minLength": 2,
        -        "type": "string"
        -      }
        -    },
        -    "required": [
        -      "cityName"
        -    ],
        -    "type": "object"
        -  },
        -  {
        -    "additionalProperties": false,
        -    "properties": {
        -      "lat": {
        -        "maximum": 90,
        -        "minimum": -90,
        -        "type": "number"
        -      },
        -      "lng": {
        -        "maximum": 180,
        -        "minimum": -180,
        -        "type": "number"
        -      }
        -    },
        -    "required": [
        -      "lat",
        -      "lng"
        -    ],
        -    "type": "object"
        -  },
        -  {
        -    "additionalProperties": false,
        -    "properties": {
        -      "geoDivisionId": {
        -        "format": "uuid",
        -        "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
        -        "type": "string"
        -      }
        -    },
        -    "required": [
        -      "geoDivisionId"
        -    ],
        -    "type": "object"
        -  }
        -]
      • addedInput schema / properties
        Added value: +{
        +  "cityName": {
        +    "maxLength": 100,
        +    "minLength": 2,
        +    "type": "string"
        +  },
        +  "context": {
        +    "description": "Explain 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.\"",
        +    "type": "string"
        +  },
        +  "conversation_id": {
        +    "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +    "type": "string"
        +  },
        +  "geoDivisionId": {
        +    "format": "uuid",
        +    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
        +    "type": "string"
        +  },
        +  "lat": {
        +    "maximum": 90,
        +    "minimum": -90,
        +    "type": "number"
        +  },
        +  "llm_model": {
        +    "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +    "type": "string"
        +  },
        +  "lng": {
        +    "maximum": 180,
        +    "minimum": -180,
        +    "type": "number"
        +  }
        +}
      • addedInput schema / required
        Added value: +[
        +  "context",
        +  "llm_model"
        +]
    • ChangedgetProjectContext2 fields changed
      • addedInput schema / properties / include
        Added value: +{
        +  "default": [],
        +  "description": "Optional extra sections. Default is none, so the payload matches a call without include. tasks, members, insights, capital, and visualEvidence each reuse the matching product read — they are not separate tools. Writes stay on the Bucky CLI.",
        +  "items": {
        +    "enum": [
        +      "tasks",
        +      "members",
        +      "insights",
        +      "capital",
        +      "visualEvidence"
        +    ],
        +    "type": "string"
        +  },
        +  "type": "array"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "documentsLimit",
        -  "evidenceLimit",
        -  "context",
        -  "llm_model"
        -]New value: +[
        +  "documentsLimit",
        +  "evidenceLimit",
        +  "include",
        +  "context",
        +  "llm_model"
        +]
  10. 13 tool updates
    • AddedcityInventory
    • ChangedexplainFeasibilityStatus5 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / properties / status / description
        Previous value: -"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Must be copied verbatim from a feasibility result — one of: live, live_unavailable, planned_not_live, geo_division_uncatalogued, unseeded_place, geocode_failed, cited, cited_conditional, conditional_unresolved, no_limit_in_bylaw, not_extracted, site_specific_schedule, unverified_default, derived_from_cited, defaulted, missing. Do not paraphrase or invent a status."New value: +"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Copy it verbatim. Do not paraphrase or invent a status."
      • changedInput schema / required
        Previous value: -[
        -  "status",
        -  "context"
        -]New value: +[
        +  "status",
        +  "context",
        +  "llm_model"
        +]
    • ChangedgetBuckyMcpGuide4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "context"
        -]New value: +[
        +  "context",
        +  "llm_model"
        +]
    • ChangedgetFeasibilitySnapshot4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "address",
        -  "source",
        -  "context"
        -]New value: +[
        +  "address",
        +  "source",
        +  "context",
        +  "llm_model"
        +]
    • ChangedgetProjectContext4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "documentsLimit",
        -  "evidenceLimit",
        -  "context"
        -]New value: +[
        +  "documentsLimit",
        +  "evidenceLimit",
        +  "context",
        +  "llm_model"
        +]
    • ChangedpreviewSiteCoverage4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "address",
        -  "context"
        -]New value: +[
        +  "address",
        +  "context",
        +  "llm_model"
        +]
    • ChangedproduceProjectReport4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "audience",
        -  "detail",
        -  "preview",
        -  "confirm",
        -  "context"
        -]New value: +[
        +  "audience",
        +  "detail",
        +  "preview",
        +  "confirm",
        +  "context",
        +  "llm_model"
        +]
    • ChangedrunFeasibilityAnalysis4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "context"
        -]New value: +[
        +  "context",
        +  "llm_model"
        +]
    • ChangedsaveToProject5 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / properties / parcelExternalIds / description
        Previous value: -"Source parcel ids to attach. Copy lot.parcelExternalId from getFeasibilitySnapshot, or from bucky parcels search."New value: +"Source parcel ids to attach. Copy lot.parcelExternalId from getFeasibilitySnapshot. If they are not in the current area, pass a larger radiusM on attach_parcels."
      • changedInput schema / required
        Previous value: -[
        -  "action",
        -  "preview",
        -  "context"
        -]New value: +[
        +  "action",
        +  "preview",
        +  "context",
        +  "llm_model"
        +]
    • ChangedsetProjectMapListing4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "listed",
        -  "preview",
        -  "context"
        -]New value: +[
        +  "listed",
        +  "preview",
        +  "context",
        +  "llm_model"
        +]
    • ChangedsubmitBuckyFeedback4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "context"
        -]New value: +[
        +  "context",
        +  "llm_model"
        +]
    • ChangeduiGetAnalysisStatus4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "projectId",
        -  "context"
        -]New value: +[
        +  "projectId",
        +  "context",
        +  "llm_model"
        +]
    • ChangedupdateProject4 fields changed
      • changedInput schema / properties / context / description
        Previous value: -"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.\""New value: +"Explain 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.\""
      • addedInput schema / properties / conversation_id
        Added value: +{
        +  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
        +  "type": "string"
        +}
      • addedInput schema / properties / llm_model
        Added value: +{
        +  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
        +  "type": "string"
        +}
      • changedInput schema / required
        Previous value: -[
        -  "preview",
        -  "context"
        -]New value: +[
        +  "preview",
        +  "context",
        +  "llm_model"
        +]
  11. 1 tool update
    • AddedpreviewSiteCoverage
  12. 1 tool update
    • ChangedgetBuckyMcpGuide3 fields changed
      • addedInput schema / properties / market
        Added value: +{
        +  "description": "Which country the site is in. Answers \"US or Canada?\".",
        +  "enum": [
        +    "US",
        +    "CA"
        +  ],
        +  "type": "string"
        +}
      • addedInput schema / properties / role
        Added value: +{
        +  "description": "Who is asking. Answers \"Developer, GC, or municipal reviewer?\".",
        +  "enum": [
        +    "developer",
        +    "gc",
        +    "reviewer"
        +  ],
        +  "type": "string"
        +}
      • addedInput schema / properties / scale
        Added value: +{
        +  "description": "One site or several. Answers \"Single parcel, or a portfolio?\".",
        +  "enum": [
        +    "single_parcel",
        +    "portfolio"
        +  ],
        +  "type": "string"
        +}
  13. 7 tool updates
    • ChangedexplainFeasibilityStatus2 fields changed
      • changedInput schema / properties / status / description
        Previous value: -"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Must be copied verbatim from a feasibility result — one of: live, live_unavailable, planned_not_live, geo_division_uncatalogued, unseeded_place, geocode_failed, cited, cited_conditional, conditional_unresolved, no_limit_in_bylaw, not_extracted, site_specific_schedule, unverified_default. Do not paraphrase or invent a status."New value: +"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Must be copied verbatim from a feasibility result — one of: live, live_unavailable, planned_not_live, geo_division_uncatalogued, unseeded_place, geocode_failed, cited, cited_conditional, conditional_unresolved, no_limit_in_bylaw, not_extracted, site_specific_schedule, unverified_default, derived_from_cited, defaulted, missing. Do not paraphrase or invent a status."
      • changedInput schema / properties / status / enum
        Previous value: -[
        -  "live",
        -  "live_unavailable",
        -  "planned_not_live",
        -  "geo_division_uncatalogued",
        -  "unseeded_place",
        -  "geocode_failed",
        -  "cited",
        -  "cited_conditional",
        -  "conditional_unresolved",
        -  "no_limit_in_bylaw",
        -  "not_extracted",
        -  "site_specific_schedule",
        -  "unverified_default"
        -]New value: +[
        +  "live",
        +  "live_unavailable",
        +  "planned_not_live",
        +  "geo_division_uncatalogued",
        +  "unseeded_place",
        +  "geocode_failed",
        +  "cited",
        +  "cited_conditional",
        +  "conditional_unresolved",
        +  "no_limit_in_bylaw",
        +  "not_extracted",
        +  "site_specific_schedule",
        +  "unverified_default",
        +  "derived_from_cited",
        +  "defaulted",
        +  "missing"
        +]
    • ChangedgetProjectContext2 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • changedInput schema / properties / projectId / description
        Previous value: -"Project UUID to load. Omit to have the user pick from their projects."New value: +"Project UUID. Omit if you pass `project`."
    • ChangedproduceProjectReport3 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • addedInput schema / properties / projectId / description
        Added value: +"Project UUID. Omit if you pass `project`."
      • changedInput schema / required
        Previous value: -[
        -  "projectId",
        -  "audience",
        -  "detail",
        -  "preview",
        -  "confirm",
        -  "context"
        -]New value: +[
        +  "audience",
        +  "detail",
        +  "preview",
        +  "confirm",
        +  "context"
        +]
    • ChangedrunFeasibilityAnalysis3 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • changedInput schema / properties / projectId / description
        Previous value: -"Project UUID to analyse."New value: +"Project UUID. Omit if you pass `project`."
      • changedInput schema / required
        Previous value: -[
        -  "projectId",
        -  "context"
        -]New value: +[
        +  "context"
        +]
    • ChangedsaveToProject2 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match instead of a UUID, for attach_parcels and attach_reference. Matching more than one lists the candidates instead of guessing. Ignored by create.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • addedInput schema / properties / projectId / description
        Added value: +"Existing project UUID. Required by attach_parcels and attach_reference unless you pass `project`; ignored by create."
    • ChangedsetProjectMapListing3 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • addedInput schema / properties / projectId / description
        Added value: +"Project UUID. Omit if you pass `project`."
      • changedInput schema / required
        Previous value: -[
        -  "projectId",
        -  "listed",
        -  "preview",
        -  "context"
        -]New value: +[
        +  "listed",
        +  "preview",
        +  "context"
        +]
    • ChangedupdateProject3 fields changed
      • addedInput schema / properties / project
        Added value: +{
        +  "description": "Project name to match, when you do not have the UUID. Case-insensitive; an exact name wins over a partial one. Matching more than one lists the candidates instead of guessing.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • addedInput schema / properties / projectId / description
        Added value: +"Project UUID. Omit if you pass `project`."
      • changedInput schema / required
        Previous value: -[
        -  "projectId",
        -  "preview",
        -  "context"
        -]New value: +[
        +  "preview",
        +  "context"
        +]
  14. 5 tool updates
    • ChangedexplainFeasibilityStatus2 fields changed
      • changedInput schema / properties / status / description
        Previous value: -"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result."New value: +"A Bucky coverage resolution status or per-fact provenance status returned by a feasibility result. Must be copied verbatim from a feasibility result — one of: live, live_unavailable, planned_not_live, geo_division_uncatalogued, unseeded_place, geocode_failed, cited, cited_conditional, conditional_unresolved, no_limit_in_bylaw, not_extracted, site_specific_schedule, unverified_default. Do not paraphrase or invent a status."
      • changedInput schema / properties / status / enum
        Previous value: -[
        -  "live",
        -  "live_unavailable",
        -  "planned_not_live",
        -  "geo_division_uncatalogued",
        -  "unseeded_place",
        -  "geocode_failed",
        -  "cited",
        -  "cited_conditional",
        -  "conditional_unresolved",
        -  "no_limit_in_bylaw",
        -  "not_extracted",
        -  "unverified_default"
        -]New value: +[
        +  "live",
        +  "live_unavailable",
        +  "planned_not_live",
        +  "geo_division_uncatalogued",
        +  "unseeded_place",
        +  "geocode_failed",
        +  "cited",
        +  "cited_conditional",
        +  "conditional_unresolved",
        +  "no_limit_in_bylaw",
        +  "not_extracted",
        +  "site_specific_schedule",
        +  "unverified_default"
        +]
    • ChangedsaveToProject4 fields changed
      • addedInput schema / properties / address / description
        Added value: +"Street address of the site. On `create` this is geocoded server-side when lat/lng are not supplied, and is what gets recorded as the project address."
      • addedInput schema / properties / externalRef
        Added value: +{
        +  "description": "Provenance of an imported project. Canonical form is `<system>:<id>` (e.g. `notion:<page-id>`). Unique per creator when set. Returned on getProjectContext. Distinct from idempotencyKey.",
        +  "maxLength": 200,
        +  "minLength": 1,
        +  "type": "string"
        +}
      • addedInput schema / properties / lat / description
        Added value: +"Latitude from getFeasibilitySnapshot. Supplied coordinates are never re-geocoded."
      • addedInput schema / properties / lng / description
        Added value: +"Longitude from getFeasibilitySnapshot."
    • AddedsetProjectMapListing
    • ChangedsubmitBuckyFeedback2 fields changed
      • changedInput schema / properties / submissionId / description
        Previous value: -"A new UUID generated for this submission. Reuse the same UUID when retrying this exact feedback."New value: +"Optional. A UUID for this submission; generated server-side when omitted. Pass the same UUID when retrying this exact feedback so it is not recorded twice."
      • changedInput schema / required
        Previous value: -[
        -  "submissionId",
        -  "context"
        -]New value: +[
        +  "context"
        +]
    • ChangedupdateProject1 field changed
      • addedInput schema / properties / externalRef
        Added value: +{
        +  "anyOf": [
        +    {
        +      "maxLength": 200,
        +      "minLength": 1,
        +      "type": "string"
        +    },
        +    {
        +      "type": "null"
        +    }
        +  ],
        +  "description": "Provenance of an imported project. Canonical form is `<system>:<id>` (e.g. `notion:<page-id>`). Unique per creator when set. Pass null to clear."
        +}
  15. 10 tool updates
    • First observedexplainFeasibilityStatus
    • First observedgetBuckyMcpGuide
    • First observedgetFeasibilitySnapshot
    • First observedgetProjectContext
    • First observedproduceProjectReport
    • First observedrunFeasibilityAnalysis
    • First observedsaveToProject
    • First observedsubmitBuckyFeedback
    • First observeduiGetAnalysisStatus
    • First observedupdateProject

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    AI-powered property intelligence for instant zoning analysis, buildability assessments, ADU eligibility, flood risk, and development feasibility reports for any US address.
    5
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to look up US and Canadian parcel records either by full address string or by lat/lon point, returning parcel number, owner, mailing address, land use, zoning, acreage, and boundary geometry. It can be run as a local stdio server or reached through a hosted gateway endpoint.
    86 npm
    MIT
  • F
    license
    Not graded
    quality
    B
    maintenance
    Provides free property and parcel intelligence using official US government data APIs, county assessor records, and live listings, with tools for hazard risk checks, affordability calculations, and parcel ranking.
    -
  • F
    license
    Not graded
    quality
    D
    maintenance
    Property intelligence API for US real estate. Returns 16+ data points for any US address: noise levels, wetlands, slope, natural light, powerline proximity, crime rates, property facing direction, zoning, public record, radon risk, natural hazards (earthquake, flood, wildfire), neighborhood demographics, falling tree risk, RF/cell tower exposure, and nearby school.
    -
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.