> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iqrush.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrieve page evidence and technical recommendations

> Use the page and source interfaces to help a developer or content team understand what to inspect next. Keep measured page evidence separate from an assistant's proposed edits.

Use the page and source interfaces to help a developer or content team understand what to inspect next. Keep measured page evidence separate from an assistant's proposed edits.

## Read a cited page's evidence

Use `analyze_page_performance` with the project, run, and a URL drawn from the run's source results. It returns `data.chunks`, `data.statements`, `data.chunks_source`, `data.n_chunks`, and `data.n_statements` when available.

The chunks describe captured page content. The statements are AI answer statements that cited the page in that measurement. An assistant can compare the two and explain which claims have clear support. That explanation is an assessment of retrieved evidence, not a new measured score.

If `chunks_source` is `unavailable`, say that captured page content is unavailable. The citing statements may still be useful, but they do not supply the missing page sections. The tool does not promise to crawl a fresh version of any URL on demand.

## Read technical features

`get_technical_features` reads the selected page's recorded features. Inspect `matched_url` because a domain or partial URL can match a page. The result includes feature keys, values, and sometimes an observed `run_spread` across pages.

Do not turn an observed range into a universal target. These data describe pages present in the run; they do not establish what separates cited pages from every uncited page. A null `normalized_score` is unavailable, not a zero quality score.

`feature_group` filters by the returned feature-key text on this route. The MCP argument `feature_domain` is not applied by the current HTTP route; omit it for this edition.

## Read technical recommendations over HTTP

Configured HTTP integrations can request:

```text theme={null}
GET /projects/{project_id}/runs/{run_id}/technical-recommendations
```

Optional parameters are `url`, `impact`, and `effort`. Use impact and effort labels returned in your data rather than inventing categories. Returned `data.recommendations` can contain `url`, `domain`, `title`, `description`, `effort`, `impact`, and `implementation_steps`. `current_score` and `feature` can be null.

`data.n_recommendations` counts returned recommendations. Despite its name, `data.n_urls` currently counts distinct domains in this response; do not label it “distinct page URLs.”

There is no equivalent named external MCP tool in the 43-tool catalog covered here. Content recommendations, briefs, and the Content Playground remain product workflows unless a separate supported integration is provided. Do not advertise content editing or publishing through these read tools.

## Hand work to the right team

A useful handoff includes the exact page, observed evidence, recommendation text, implementation steps when provided, and what to measure after a change. Preserve a link to the source run so the team can review the original scope.

Next: [Choose a report](/developers/guides/16-report-recipes).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.