Code Review

This pull request introduces a feature to export notebook metadata, including a list of sources. The implementation is well-structured, adding a new NotebookMetadata type, a get_metadata API method, and a corresponding metadata CLI command. My review includes suggestions to improve performance by running asynchronous operations concurrently, and to simplify the CLI implementation for better maintainability and user experience.

Thanks for this contribution! The feature is well-scoped and the CLI placement as a top-level command is consistent with existing conventions. A few suggestions to bring it in line with the project's patterns before merge:

Architecture: SourcesAPI instantiation inside NotebooksAPI

get_metadata() does a local import and creates a standalone SourcesAPI(self._core), which bypasses the client's dependency injection pattern. The project uses constructor injection for cross-API references (e.g., ArtifactsAPI receives notes_api via its constructor).

Suggestion: Either move get_metadata() to NotebookLMClient itself (since it composes two sub-APIs), or inject SourcesAPI into NotebooksAPI via the constructor following the ArtifactsAPI/notes_api pattern.

Type design: sources: list[dict] should be a typed structure

This is the only list[dict] in the entire types.py module — every other collection uses typed elements (list[SuggestedTopic], list[SharedUser], etc.). Using untyped dicts means consumers lose type safety and IDE support.

Suggestion: Define a small dataclass for the source summary:

@dataclass
class SourceSummary:
    kind: SourceType
    title: str | None = None
    url: str | None = None

    def to_dict(self) -> dict[str, str | None]:
        d: dict[str, str | None] = {"type": str(self.kind)}
        if self.title:
            d["title"] = self.title
        if self.url:
            d["url"] = self.url
        return d

Then use sources: list[SourceSummary] in NotebookMetadata.

Additionally, consider composing with Notebook rather than duplicating its fields (id, title, created_at, is_owner). This avoids silent divergence if Notebook gains new fields:

@dataclass
class NotebookMetadata:
    notebook: Notebook
    sources: list[SourceSummary] = field(default_factory=list)

With to_dict() flattening the notebook fields for JSON output.

Source dict schema consistency

Currently, title and url keys are conditionally included — some source dicts will have them and some won't. This makes the JSON output harder to consume programmatically.

Suggestion: Always include all keys, using null for absent values, so the schema is consistent across all source entries.

CLI flags: --json / --no-json convention

Every other CLI command uses --json as an opt-in flag (default False) with human-readable output as the default. This command has --json defaulting to True plus a separate --no-json flag, which is inconsistent.

Suggestion: Follow the existing pattern — --json as opt-in, human-readable as default. Remove the --no-json flag. This also eliminates the unused json_output parameter in the function body.

Silent data loss when source listing fails

SourcesAPI.list() returns [] on various failure conditions (malformed response, API changes) with only a logger.warning. Since get_metadata() passes this through, users could see "sources": [] when the notebook actually has sources.

Suggestion: Cross-check notebook.sources_count against len(sources) and log a warning on mismatch:

if notebook.sources_count > 0 and len(sources) == 0:
    logger.warning(
        "Notebook %s reports %d sources but listing returned empty",
        notebook_id, notebook.sources_count,
    )

str(source.kind) behavior

SourceType is a str enum. On Python versions <3.11, str() on a StrEnum member may produce "SourceType.web_page" instead of "web_page". Consider using source.kind.value explicitly for safety.

Missing tests

The project has thorough test coverage at unit/integration/CLI levels for every comparable feature. Recommended additions:

Overall this is a nice, focused feature — these suggestions are mostly about aligning with existing project conventions. Happy to help if any of these need further clarification!