Bucky

Create or attach to a project

saveToProject

Idempotent

Create a new project from a site (create), attach lots (attach_parcels, using lot.parcelExternalId from getFeasibilitySnapshot), or attach a knowledge reference (attach_reference). Pass lat and lng on create: they resolve the project to a city, and geography.resolved: false on the result means the project has no city context and feasibility analysis will have nothing to resolve against. preview=true returns the field-level diff and writes nothing. A write returns a receipt. Not reversible on this surface: MCP cannot archive a project, detach a parcel, or detach a reference. Create accepts idempotencyKey.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	No
`lng`	No
`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
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`preview`	Yes	When true, return the field-level diff and write nothing.
`radiusM`	No	Search half-width in metres when resolving parcel ids. Default 150.
`projectId`	No
`sectionUuid`	No
`idempotencyKey`	No
`parcelExternalIds`	No	Source parcel ids to attach. Copy lot.parcelExternalId from getFeasibilitySnapshot, or from bucky parcels search.

TDQS

A4.6/5.0

Behavior5/5

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

Beyond annotations, the description discloses write behavior ('A write returns a receipt'), the meaning of `geography.resolved: false`, preview mode's no-write guarantee, non-reversibility, and idempotencyKey support. This adds real context and is consistent with idempotentHint=true and readOnlyHint=false.

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

Conciseness5/5

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

Five focused sentences deliver the action modes, mode-specific guidance, preview behavior, and irreversibility warning in order of importance. No filler.

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

Completeness4/5

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

For a 13-parameter, three-mode mutation tool with no output schema, the description covers core mechanics, safety (preview, irreversibility), and mode-specific input sources. It doesn't enumerate return values for every mode, but the receipt and geography.resolved hints supply the key outputs. Slight gaps remain for the non-action parameters.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 46%, so the description's explanations matter. It adds semantics for lat/lng (city resolution), idempotencyKey (accepted for create), and parcelExternalIds (source field). However, params like name, address, role, radiusM, projectId, and sectionUuid are left to the schema or inference, so it doesn't fully compensate for the coverage gap.

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

Purpose5/5

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

The description opens by naming the three concrete operations (`create`, `attach_parcels`, `attach_reference`) and ties each to its resource (site, lots, knowledge reference). This distinguishes it from sibling updateProject and read-only project tools, and the action enum names align one-to-one with usage.

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

Usage Guidelines4/5

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

It supplies actionable conditions: pass lat/lng only on create, use lot.parcelExternalId from getFeasibilitySnapshot for attach_parcels, and preview=true to avoid writing. It also warns what is not reversible. It stops short of explicitly naming updateProject as the alternative for modifying existing project settings, but the guidance is largely explicit.

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

All Bucky tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness4/5

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

Resources

Need Help?