Your first request

Start with a question that names one repository and one small task: “Find open bugs in acme/sdk.” The agent should use search_issues rather than guessing from memory or claiming to search all repositories.

Inspect the call

search_issues({
  repo: "acme/sdk",
  state: "open",
  label: "bug",
  limit: 50
})

This notation shows the tool name and its arguments. It is not a complete JSON-RPC message and is not a shell command. All filters are combined: an issue must belong to acme/sdk, be open and carry the exact bug label.

Read the example result

{
  "repo": "acme/sdk",
  "issues": [
    {
      "number": 412,
      "title": "Retry loop continues after cancellation",
      "state": "open",
      "labels": [
        "bug"
      ],
      "milestone": "v2.0"
    }
  ],
  "returned_count": 1,
  "truncated": true
}

This shortened example deliberately sets truncated to true because it shows one of seven matching issues. In the complete seven-record fixture, returned_count is 7 and truncated is false. The field counts records returned by this call; it is not a total repository issue count.

Narrow the result

Ask for the same open bugs in milestone v2.0. Add milestone: “v2.0” while keeping the other filters. The canonical fixture contains four matches: #412, #409, #405 and #398. Use list_milestones if you do not know the exact title.

Read one issue in full

get_issue({ repo: "acme/sdk", issue_number: 412 })

The follow-up returns the description, labels and milestone for #412. It still does not include comments or attachments. Keep the repository explicit when using an issue number: numbers are scoped to repositories.

If something differs

Live repositories change. Compare tool arguments, access and filters before comparing counts to this fixture. An empty result is a valid result. A tool error requires the recovery step in the Error reference.

Understand result limits