Resources

What this is: things a client can read as context, by URI. When you need it: attaching a particular task or saved view to a conversation.

URI	Returns	Type	Scope	Same as
taskadence://task/{task_id}	The task as `GET /v1/tasks/{task_id}` returns it: title, description, status, priority, assignee, dates, project / team / sprint / milestone / goal, tags, subtasks, dependencies and type fields.	application/json	tasks:read	GET /v1/tasks/{task_id}
taskadence://view/{view_id}	`{view, rows, next_cursor}`: the view's definition (`GET /v1/views/{view_id}`: name, resource, scope, query, display) and the first page of the rows it shows now (`GET /v1/views/{view_id}/rows`, 25 rows: tasks or projects per the view's `resource`); `next_cursor` continues with the `view_rows` tool.	application/json	tasks:read	GET /v1/views/{view_id}GET /v1/views/{view_id}/rows

A client finds them as resource templates, and only when the connection’s groups include tasks (the task) or views (the view). A bad or unknown URI is a protocol error naming the two forms.

Read, or call a tool?

• Read a resource when you already know which task or view you mean and want it in front of the model — for example, attaching taskadence://task/T123456 to the chat before asking about it.
• Call a tool when the model has to find, filter or change something: search_tasks, list_my_tasks, update_task.

Resources are read-only; everything that changes data is a tool. Reading one needs the same scope as the API read behind it, and sees only what your access sees there.