Bucky
Server Details
Zoning, parcel, and development feasibility for a street address in Canada and the US.
- 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
Scored across 15 tools
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.
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.
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.
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 toolscityInventorySee what Bucky has mapped for a cityARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| context | Yes | 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." | |
| cityName | No | ||
| llm_model | Yes | 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. | |
| geoDivisionId | No | ||
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 statusARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | 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. | |
| context | Yes | 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." | |
| llm_model | Yes | 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. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 guideARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Who is asking. Answers "Developer, GC, or municipal reviewer?". | |
| scale | No | One site or several. Answers "Single parcel, or a portfolio?". | |
| market | No | Which country the site is in. Answers "US or Canada?". | |
| context | Yes | 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." | |
| llm_model | Yes | 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. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 textARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| zoneCode | No | zone.code from getFeasibilitySnapshot, for example C-2. | |
| llm_model | Yes | 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. | |
| sectionIds | No | Copy citations.*.knowledgeSectionId from getFeasibilitySnapshot. 1 to 4 ids. | |
| geoDivisionId | No | coverage.geoDivisionId from getFeasibilitySnapshot. | |
| sectionNumbers | No | Section numbers to read, for example 3.1 or 3.2. 1 to 4 numbers. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 addressARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Which question the caller is answering. Used for attribution and to pick the link back; the payload is the same either way. | full |
| address | Yes | Street address to analyse, e.g. "4170 Sophia St, Vancouver BC". | |
| context | Yes | Explain 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_model | Yes | 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. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 bundleARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| include | Yes | 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. | |
| project | No | 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. | |
| llm_model | Yes | 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. | |
| projectId | No | Project UUID. Omit if you pass `project`. | |
| evidenceLimit | Yes | ||
| documentsLimit | Yes | ||
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 addressARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Street address to analyse, e.g. "4170 Sophia St, Vancouver BC". | |
| context | Yes | 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." | |
| llm_model | Yes | 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. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 PDFAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | Yes | detailed | |
| confirm | Yes | When true, compose (if needed), save, export PDF, and return a download URL. Required when preview is false. Spends records.exports and cannot be undone. | |
| context | Yes | 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." | |
| preview | Yes | When true, compose only — no export meter spend and no download URL. | |
| project | No | 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. | |
| request | No | ||
| audience | Yes | owner | |
| planName | No | ||
| llm_model | Yes | 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. | |
| projectId | No | Project UUID. Omit if you pass `project`. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| project | No | 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. | |
| llm_model | Yes | 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. | |
| projectId | No | Project UUID. Omit if you pass `project`. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 projectAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude from getFeasibilitySnapshot. Supplied coordinates are never re-geocoded. | |
| lng | No | Longitude from getFeasibilitySnapshot. | |
| name | No | ||
| role | No | build is the lot being developed; context is surrounding land. Default build. | |
| action | Yes | create: 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. | |
| address | No | 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. | |
| context | Yes | 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." | |
| preview | Yes | When true, return the field-level diff and write nothing. | |
| project | No | 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. | |
| radiusM | No | Search half-width in metres when resolving parcel ids. Default 150. | |
| llm_model | Yes | 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. | |
| projectId | No | Existing project UUID. Required by attach_parcels and attach_reference unless you pass `project`; ignored by create. | |
| externalRef | No | 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. | |
| sectionUuid | No | ||
| idempotencyKey | No | ||
| conversation_id | No | 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. | |
| parcelExternalIds | No | 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. |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City as the user said it, e.g. "Laval" or "Bedford, MA". Omit when you pass geoDivisionId or profileId. | |
| save | No | true saves the buy box to the account. Default false: nothing is written. | |
| limit | No | Lots to return. Default 10. The total match count is always returned. | |
| thesis | No | The buy box in plain words, e.g. "industrial lots over half an acre outside the floodplain". | |
| context | Yes | 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." | |
| criteria | No | Structured criteria. A field set here replaces the same field read from thesis. | |
| saveName | No | Name for a saved box. | |
| llm_model | Yes | 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. | |
| profileId | No | Saved buy box id. Runs the saved city and criteria. Do not combine with city, thesis, or criteria. | |
| geoDivisionId | No | Division id, from an earlier screenLots or cityInventory result. | |
| conversation_id | No | 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. |
setProjectMapListingList or unlist a project on the public mapAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| listed | Yes | true 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. | |
| context | Yes | 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." | |
| preview | Yes | When true, return the current listing state, the pin that would be published, and any privacy warning, and write nothing. | |
| project | No | 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. | |
| llm_model | Yes | 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. | |
| projectId | No | Project UUID. Omit if you pass `project`. | |
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 BuckyAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| llm_model | Yes | 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. | |
| submissionId | No | 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. | |
| conversation_id | No | 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. | |
| affectedToolName | No | Tool the user is commenting on, when already known |
TDQS
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.
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.
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.
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.
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.
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 statusARead-onlyIdempotentInspect
Return only the analysis agentStatus for a project. Cheap enough to poll. Used by the Bucky app view; the model should call getProjectContext instead.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | 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." | |
| llm_model | Yes | 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. | |
| projectId | Yes | ||
| conversation_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 fieldsAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| context | Yes | 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." | |
| preview | Yes | When true, return the field-level diff and write nothing. Combined with undoOperationId, returns the stored receipt. | |
| project | No | 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. | |
| llm_model | Yes | 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. | |
| projectId | No | Project UUID. Omit if you pass `project`. | |
| externalRef | No | Provenance of an imported project. Canonical form is `<system>:<id>` (e.g. `notion:<page-id>`). Unique per creator when set. Pass null to clear. | |
| conversation_id | No | 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. | |
| lifecycleStatus | No | ||
| undoOperationId | No | Receipt id from a prior updateProject write. Restores the captured prior fields. With preview=true, inspects the receipt instead. |
TDQS
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.
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.
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.
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.
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.
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 tool update
- Changed
screenLots2 fields changed- added
Input schema / properties / criteria / properties / hydrant_distanceAdded 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" +} - changed
Input schema / properties / criteria / properties / stories / descriptionPrevious 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 }."
1 tool update
- Changed
screenLots6 fields changed- added
Input schema / properties / criteria / properties / building_useAdded 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" +} - added
Input schema / properties / criteria / properties / exterior_materialAdded 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" +} - added
Input schema / properties / criteria / properties / register_statusAdded 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" +} - added
Input schema / properties / criteria / properties / storiesAdded 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" +} - added
Input schema / properties / criteria / properties / streetAdded 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" +} - changed
Input schema / properties / thesis / maxLengthPrevious value: -500New value: +1500
1 tool update
- Changed
screenLots2 fields changed- added
Input schema / properties / criteria / properties / frequent_transit_distanceAdded 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" +} - changed
Input schema / properties / criteria / properties / zone_family / descriptionPrevious 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."
1 tool update
- Changed
screenLots3 fields changed- changed
Input schema / properties / criteria / properties / improvement_land_ratio / descriptionPrevious 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 }." - changed
Input schema / properties / criteria / properties / overlayExcludeKinds / descriptionPrevious 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." - changed
Input schema / properties / criteria / properties / overlayKinds / descriptionPrevious 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."
1 tool update
- Changed
screenLots3 fields changed- changed
Input schema / properties / criteria / properties / existing_use_class / descriptionPrevious 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." - added
Input schema / properties / criteria / properties / subdivision_yieldAdded 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" +} - added
Input schema / properties / criteria / properties / zone_familyAdded 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" +}
1 tool update
- Changed
screenLots2 fields changed- changed
Input schema / properties / criteria / properties / existing_use_class / descriptionPrevious 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." - added
Input schema / properties / criteria / properties / place_of_worshipAdded 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" +}
1 tool update
- Changed
screenLots7 fields changed- added
Input schema / properties / criteria / properties / contamination_riskAdded 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" +} - added
Input schema / properties / criteria / properties / existing_coverage_pctAdded 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" +} - added
Input schema / properties / criteria / properties / existing_use_classAdded 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" +} - added
Input schema / properties / criteria / properties / improvement_land_ratioAdded 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" +} - added
Input schema / properties / criteria / properties / ownership_formAdded 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" +} - added
Input schema / properties / criteria / properties / titled_unit_countAdded 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" +} - added
Input schema / properties / criteria / properties / year_builtAdded 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" +}
2 tool updates
- Added
getBylawSection - Added
screenLots
2 tool updates
- Changed
cityInventory3 fields changed- removed
Input schema / anyOfRemoved 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" - } -] - added
Input schema / propertiesAdded 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" + } +} - added
Input schema / requiredAdded value: +[ + "context", + "llm_model" +]
- Changed
getProjectContext2 fields changed- added
Input schema / properties / includeAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "documentsLimit", - "evidenceLimit", - "context", - "llm_model" -]New value: +[ + "documentsLimit", + "evidenceLimit", + "include", + "context", + "llm_model" +]
13 tool updates
- Added
cityInventory - Changed
explainFeasibilityStatus5 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / properties / status / descriptionPrevious 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." - changed
Input schema / requiredPrevious value: -[ - "status", - "context" -]New value: +[ + "status", + "context", + "llm_model" +]
- Changed
getBuckyMcpGuide4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "context" -]New value: +[ + "context", + "llm_model" +]
- Changed
getFeasibilitySnapshot4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "address", - "source", - "context" -]New value: +[ + "address", + "source", + "context", + "llm_model" +]
- Changed
getProjectContext4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "documentsLimit", - "evidenceLimit", - "context" -]New value: +[ + "documentsLimit", + "evidenceLimit", + "context", + "llm_model" +]
- Changed
previewSiteCoverage4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "address", - "context" -]New value: +[ + "address", + "context", + "llm_model" +]
- Changed
produceProjectReport4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "audience", - "detail", - "preview", - "confirm", - "context" -]New value: +[ + "audience", + "detail", + "preview", + "confirm", + "context", + "llm_model" +]
- Changed
runFeasibilityAnalysis4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "context" -]New value: +[ + "context", + "llm_model" +]
- Changed
saveToProject5 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / properties / parcelExternalIds / descriptionPrevious 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." - changed
Input schema / requiredPrevious value: -[ - "action", - "preview", - "context" -]New value: +[ + "action", + "preview", + "context", + "llm_model" +]
- Changed
setProjectMapListing4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "listed", - "preview", - "context" -]New value: +[ + "listed", + "preview", + "context", + "llm_model" +]
- Changed
submitBuckyFeedback4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "context" -]New value: +[ + "context", + "llm_model" +]
- Changed
uiGetAnalysisStatus4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "projectId", - "context" -]New value: +[ + "projectId", + "context", + "llm_model" +]
- Changed
updateProject4 fields changed- changed
Input schema / properties / context / descriptionPrevious 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.\"" - added
Input schema / properties / conversation_idAdded 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" +} - added
Input schema / properties / llm_modelAdded 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" +} - changed
Input schema / requiredPrevious value: -[ - "preview", - "context" -]New value: +[ + "preview", + "context", + "llm_model" +]
1 tool update
- Added
previewSiteCoverage
1 tool update
- Changed
getBuckyMcpGuide3 fields changed- added
Input schema / properties / marketAdded value: +{ + "description": "Which country the site is in. Answers \"US or Canada?\".", + "enum": [ + "US", + "CA" + ], + "type": "string" +} - added
Input schema / properties / roleAdded value: +{ + "description": "Who is asking. Answers \"Developer, GC, or municipal reviewer?\".", + "enum": [ + "developer", + "gc", + "reviewer" + ], + "type": "string" +} - added
Input schema / properties / scaleAdded value: +{ + "description": "One site or several. Answers \"Single parcel, or a portfolio?\".", + "enum": [ + "single_parcel", + "portfolio" + ], + "type": "string" +}
7 tool updates
- Changed
explainFeasibilityStatus2 fields changed- changed
Input schema / properties / status / descriptionPrevious 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." - changed
Input schema / properties / status / enumPrevious 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" +]
- Changed
getProjectContext2 fields changed- added
Input schema / properties / projectAdded 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" +} - changed
Input schema / properties / projectId / descriptionPrevious value: -"Project UUID to load. Omit to have the user pick from their projects."New value: +"Project UUID. Omit if you pass `project`."
- Changed
produceProjectReport3 fields changed- added
Input schema / properties / projectAdded 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" +} - added
Input schema / properties / projectId / descriptionAdded value: +"Project UUID. Omit if you pass `project`." - changed
Input schema / requiredPrevious value: -[ - "projectId", - "audience", - "detail", - "preview", - "confirm", - "context" -]New value: +[ + "audience", + "detail", + "preview", + "confirm", + "context" +]
- Changed
runFeasibilityAnalysis3 fields changed- added
Input schema / properties / projectAdded 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" +} - changed
Input schema / properties / projectId / descriptionPrevious value: -"Project UUID to analyse."New value: +"Project UUID. Omit if you pass `project`." - changed
Input schema / requiredPrevious value: -[ - "projectId", - "context" -]New value: +[ + "context" +]
- Changed
saveToProject2 fields changed- added
Input schema / properties / projectAdded 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" +} - added
Input schema / properties / projectId / descriptionAdded value: +"Existing project UUID. Required by attach_parcels and attach_reference unless you pass `project`; ignored by create."
- Changed
setProjectMapListing3 fields changed- added
Input schema / properties / projectAdded 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" +} - added
Input schema / properties / projectId / descriptionAdded value: +"Project UUID. Omit if you pass `project`." - changed
Input schema / requiredPrevious value: -[ - "projectId", - "listed", - "preview", - "context" -]New value: +[ + "listed", + "preview", + "context" +]
- Changed
updateProject3 fields changed- added
Input schema / properties / projectAdded 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" +} - added
Input schema / properties / projectId / descriptionAdded value: +"Project UUID. Omit if you pass `project`." - changed
Input schema / requiredPrevious value: -[ - "projectId", - "preview", - "context" -]New value: +[ + "preview", + "context" +]
5 tool updates
- Changed
explainFeasibilityStatus2 fields changed- changed
Input schema / properties / status / descriptionPrevious 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." - changed
Input schema / properties / status / enumPrevious 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" +]
- Changed
saveToProject4 fields changed- added
Input schema / properties / address / descriptionAdded 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." - added
Input schema / properties / externalRefAdded 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" +} - added
Input schema / properties / lat / descriptionAdded value: +"Latitude from getFeasibilitySnapshot. Supplied coordinates are never re-geocoded." - added
Input schema / properties / lng / descriptionAdded value: +"Longitude from getFeasibilitySnapshot."
- Added
setProjectMapListing - Changed
submitBuckyFeedback2 fields changed- changed
Input schema / properties / submissionId / descriptionPrevious 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." - changed
Input schema / requiredPrevious value: -[ - "submissionId", - "context" -]New value: +[ + "context" +]
- Changed
updateProject1 field changed- added
Input schema / properties / externalRefAdded 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." +}
10 tool updates
- First observed
explainFeasibilityStatus - First observed
getBuckyMcpGuide - First observed
getFeasibilitySnapshot - First observed
getProjectContext - First observed
produceProjectReport - First observed
runFeasibilityAnalysis - First observed
saveToProject - First observed
submitBuckyFeedback - First observed
uiGetAnalysisStatus - First observed
updateProject
Related MCP Connectors
Zoning, ADU eligibility, flood zone, setbacks, and buildability intelligence for U.S. parcels.
Zoning, homes per lot, short-term rentals, tax and flood for any property in Austin and Nashville.
Property intelligence: 180M+ US parcels — lookup, search, owners, hazards, permits, deeds.
Human-reviewed zoning answers with ordinance citations for covered US municipalities.
Related MCP Servers
- AlicenseAqualityDmaintenanceAI-powered property intelligence for instant zoning analysis, buildability assessments, ADU eligibility, flood risk, and development feasibility reports for any US address.51MIT
- AlicenseNot gradedqualityBmaintenanceEnables 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 npmMIT
- FlicenseNot gradedqualityBmaintenanceProvides 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.-
- FlicenseNot gradedqualityDmaintenanceProperty 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.-
Glama MCP Gateway
Add one secure layer between your agents and this server.