Buildory

View saved version →

---
name: use-buildory
description: Inspect, explain and maintain live Buildory project data through Buildory MCP tools. Use when a user asks about Buildory projects, progress, risks, tasks, parts or BOM items, build logs, knowledge, photo captions, linked resources, blockers, next steps, or explicitly asks to record or update supported project information.
---

# Use Buildory

Use Buildory as the source of truth for the connected user's project facts. Keep factual findings separate from recommendations and distinguish proposed changes from completed writes.

## Choose a read tool

- Call `buildory_list_projects` when the project is not unambiguous or the user asks across projects.
- Call `buildory_project_summary` for status, structure, totals, recent activity, or a general progress review.
- Call `buildory_search_project` for a topic, component, phrase, supplier, linked resource, problem, or cross-section question.
- Call `buildory_get_section` for detailed child sections, tasks, parts, logs, knowledge, photos, and linked resources in one section.
- Call `buildory_get_execution_brief` when the user wants a focused technical handoff for one existing task or section. Treat the returned brief as bounded project context, not as authorization to execute work or mutate Buildory.
- Call `buildory_get_project_activity` when the user asks what changed, when it changed, or whether a change came from a human, MCP client, Codex return, API, or automation.
- When available, call `buildory_list_project_items` before a precise update, archive, restore, or typed inventory request; call `buildory_get_project_item` for one exact returned record.
- When available, use `buildory_list_artifacts` for a file inventory and `buildory_get_artifact` only when full revision history, links, or a temporary download URL is needed.

Use project and section identifiers returned by Buildory. Do not invent identifiers or guess access to projects that were not returned.

## Choose a write tool

- Call `buildory_create_task` to add an agreed task to a specific existing section.
- Call `buildory_update_task` to change an existing task's content, status, priority, or due date.
- Call `buildory_create_bom_item` to record a candidate part or material.
- Call `buildory_update_bom_item` to refine, move, select, order, receive, reject, or obsolete a part.
- Call `buildory_create_knowledge` to preserve a note, decision, research result, specification, or reference.
- Call `buildory_create_build_log` only for work or observations that actually happened, not future plans.

When the connected server exposes the additive Buildory 2.0 tools:

- Call `buildory_update_project` only for supported metadata or active lifecycle changes; it cannot change visibility, publication, billing, MCP settings, or archive state.
- Call `buildory_create_section` or `buildory_update_section` for an explicitly requested section, hierarchy move, or sibling ordering change.
- Call `buildory_manage_task` for blocked state, execution details, or moving an existing task; keep the published `buildory_update_task` behavior unchanged.
- Call `buildory_update_knowledge` or `buildory_update_build_log` only for a genuine correction and include the user's reason. Prefer a new superseding knowledge item for a newer conclusion.
- Call `buildory_create_resource` or `buildory_update_resource` for external references and their project or section placement.
- Use the artifact prepare → direct upload → finalize sequence for versioned deliverable files. Never send file bytes as base64 in tool arguments.
- Call `buildory_archive_items` only for exact records after explicit user intent. Archive is reversible, not permanent deletion. Call `buildory_restore_items` for exact archived records and restore archived parent sections first.

After external execution, use the existing update-task, create-build-log, or create-knowledge tools only when the user asks to return the result to Buildory. Keep the stored outcome con

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.