Agent guide

Tapestry for agents

A short operating guide for agents using Tapestry through its API or MCP.
Connect Tapestry in your chat app. Use the remote MCP URL and your Tapestry sign-in, then choose the workspaces and actions you want the connection to access.
01

Connect with the right scope

Hosted MCP connects Tapestry to your chat app using your existing Tapestry sign-in.

  • Add https://tapestry.pyrite.ai/api/v1/mcp as the remote MCP server, then sign in and approve the connection. Setup instructions: https://docs.tapestry.pyrite.ai/mcp/
  • Choose one workspace or all currently visible workspaces, and read or read/write access.
  • Manual API clients can still use a token from Settings > Delegates. Store it in the client secret store; never paste it into tasks, source code, prompts or logs.
02

Find your work and context

Tapestry is a directed task graph. Preserve the relationships and ownership decisions already made by its users.

  • Call whoami and list_workspaces to identify the connection and its granted scope.
  • Use query_tasks with view all and assignedTo delegate for work assigned to this connection, or assignedTo user for the person who connected it.
  • Use resolve_task for a task number, URL or approximate title. Choose an explicit candidate when a search is ambiguous.
  • Read get_task and get_task_discussion before acting. Use get_task_dependencies, get_due_chain and get_unblock_impact to understand order and urgency.
03

Plan connected steps

Break larger requests into concrete tasks and connect the steps where one depends on another.

  • Use create_task and link_tasks for new work; use insert_task_relative to place a step before, after or between existing tasks atomically.
  • Use unlink_tasks only when the dependency should actually be removed.
  • Find reusable work with list_templates, inspect preview_template, then use insert_template with the chosen bindings.
  • Respect ambiguous task references and rejected graph cycles; ask the user to clarify the intended task or relationship.
04

Claim and update explicitly

The user and the connected delegate are distinct assignees. Every mutation keeps the connection’s audit identity.

  • Use claim_task_for_delegate to assign the connected delegate, or claim_task_for_user to assign the person who connected it.
  • Use edit_task_assignees and edit_task_labels to add or remove specific IDs while preserving other entries.
  • Use update_task for title, notes, due date or snooze. Null clears a date.
  • Use complete_task when the work is done, then get_unblock_impact or query_tasks to find the next available work. Use reopen_task when completion needs to be reversed.
  • Use archive_task to set work aside indefinitely, list_archived_tasks to find it, and unarchive_task to bring it back. Archive healing defaults to true and requires writable neighbors; heal false preserves the original links without adding bypasses. These tools never delete or restore deleted work.
  • Follow the user’s communication policy. These tools read discussion but do not post comments, send invitations or create credentials.
05

Use boards and review changes

Boards organize the same tasks; moving a card can update its completion state or tags.

  • Use list_boards and get_board to find visible columns and tasks, then move_board_task with the column key returned by the board.
  • Waiting and Ready follow task dependency and snooze rules; a column move cannot bypass those rules.
  • Use get_my_notifications for scoped task updates and mark_notifications_read with explicit notification IDs.
  • Check truncation and pagination fields. Never assume a bounded result contains every task, relationship or comment.
  • Keep credentials and private account details out of tool arguments and user-visible output.