> ## Documentation Index > Fetch the complete documentation index at: https://docs.substrate.42.pe/llms.txt > Use this file to discover all available pages before exploring further. # Substrate MCP Read Tools: Orient and Inspect Boards > The 13 Substrate MCP read tools — whoami, get_board_substrate, list_tasks, check_transition, and more. All return raw data, never an envelope. Read tools return raw data directly, never a write envelope. None of them require `agent_name`. Use them to orient a session, inspect boards and tasks, validate gate logic, and surface pending human approvals before committing to any write. *** ## Orientation ### `whoami` No parameters. **Call this first.** Returns project metadata, a summary of every board with its `id`, and hints. One call is enough to orient a session that has no memory of the previous one. ### `get_project` No parameters. Returns the full project record — `name`, `description`, and `version`. It is a cheap call; reach for it after `whoami` when you need fields beyond the summary. The `version` returned here is exactly what `update_project` requires. ### `list_boards` Board summaries. Because `whoami` already returns these, reach for `list_boards` only when you need a fresh paginated view or want to include archived boards. When `true`, return archived boards instead of active ones. Pagination cursor and page size. Pass the previous response's `pagination.next_cursor` to continue. ### `get_board_substrate` The board's complete operating context in one payload — the call that stops an agent guessing. Returns `groups`, `field_schema`, `policies`, and the resolved `team`. Call it once per board before doing any work there, then cache the result for the session. The id of the board to retrieve. **What the payload contains:** * `field_schema.task` and `field_schema.comments` each map a field name to `{ type, required?, values?, human_only? }`. * Each policy carries `{ type, definition, enabled, priority, … }`. * `team[]` entries are `{ member, groups, unresolved }` — member identity joined from the project registry, `groups` is advisory, and `unresolved: true` marks a reference with no corresponding registry file. *** ## Tasks ### `list_tasks` Returns a paginated list of tasks. All filters are top-level parameters. An unrecognized filter key is **ignored**, not rejected. If a filter fails to narrow the result, the most likely cause is a misspelled parameter name. Restrict results to a specific board. Restrict to a single group. Sugar for `in_groups` with one entry. Return tasks in any of these group ids. Exclude tasks in any of these group ids. Filter by parent task id. Pass `null` to return only top-level tasks. When `true`, return only tasks that have at least one subtask. When `true`, return archived tasks instead of active ones. ISO 8601 timestamp. Return tasks created before this time. ISO 8601 timestamp. Return tasks created after this time. ISO 8601 timestamp. Return tasks last updated before this time. ISO 8601 timestamp. Return tasks last updated after this time. Filter by a custom field value. Runs against the full task regardless of `view`. When `true`, return only tasks missing one or more required custom fields. Free-text search across title and description. Controls result projection. Defaults to `summary`. Use `titles` for the leanest rows; use `full` when you genuinely need every field value. Sort specification. Pagination cursor and page size. **Projection details:** Default `summary` rows include `id`, `title`, `group_id`, `version`, timestamps, a `description_excerpt` (with a `description_truncated` flag), and `custom_data` trimmed to small scalars — bulky keys are named in `custom_data_omitted`. Filtering is unaffected by projection: `custom_field` and `missing_required_fields` always run against the full task. ### `get_task` Returns one task in full — complete `description`, all `custom_data`, and the current `version` you must echo back on `update_task`. The task id. ### `get_task_history` The event log for a task in chronological order. Event types include `created`, `updated`, `archived`, `comment_added`, `move_blocked`, and others. `move_blocked` records a guard that rejected a move. `created` and `updated` events carry a `policies_fired` list in `changes` when a policy engaged. The task id. Optional event-type or time-window filters. Pagination cursor and page size. *** ## Comments ### `list_comments` The task whose comments to list. Optional `parent_id` to scope to one thread, or a time window. Pagination cursor and page size. ### `get_comment` The comment id. *** ## Gates ### `check_transition` Dry-run: would this move be allowed by the board's guards — without writing anything or creating a throwaway task? Returns `{ allowed, from_group, to_group, blocked_by? }`. Use it to confirm a gate is actually live before relying on it, or to see exactly what a move requires. The task you want to move. The target group id. ### `list_pending_approvals` Every task whose move is gated on an unset `human_only` field. Returns `{ project_name, count, items[] }`. Each item carries the board, the task, its current group, the gate (policy plus target group), and `awaiting_fields` — exactly what a human must set. Agent-set gates and already-approved tasks are excluded. Optional. Restrict results to one board. *** ## Meta ### `submit_feedback` Returns a prefilled GitHub issue URL for `42pe/substrate` that a human opens and submits. Nothing is sent automatically — no network call, no credentials required, nothing stored. The issue title. The issue body, in Markdown. Identifies the submitting agent in the issue body. ### `reverse_captcha` An easter egg: a timed puzzle for agents. Call with no arguments to receive a challenge, then call again with the `challenge_id` and your `answer`. Not part of normal work. The id returned by the initial no-argument call. Your answer to the challenge.