Avoid service fanout in large context requests

[ChiragAgg5k]

Summary

• make appwrite_get_context skip per-project service summaries for large project sets unless project_id is provided
• add service_detail with a fast totals default and samples opt-in
• include serviceSummary metadata so callers can tell whether service summaries were included or skipped

Context

The current default context call can fan out across many projects and services. In a large org, the live appwrite_get_context({}) call was still running after ~169s, while include_services=false returned in ~3.9s. This change keeps the default orientation workflow useful while avoiding large-org service fanout.

Testing

• uv run --group dev ruff check src tests
• uv run --group dev black --check src tests
• uv run --group dev pyright
• uv run python -m unittest discover -s tests/unit -v

[greptile-apps]

Greptile Summary

This PR introduces a fanout guard for appwrite_get_context: when more than 5 projects are discovered and no project_id is given, per-project service summaries are skipped and a serviceSummary metadata block explains why. A new service_detail parameter ("totals" / "samples") controls whether item previews are included, and the threshold/detail values are surfaced in the metadata so callers can self-orient.

• Org path optimised end-to-end: project clients are now created lazily after effective_include_services is decided, so a large org no longer fans out at all for the default call.
• serviceSummary metadata is attached to every response with included, reason, detail, and projectCount fields that make the throttling decision observable.
• Test coverage is comprehensive: five new scenarios cover large-org suppression, small-org samples mode, focused-project override, explicit disable, and invalid-value fallback.

Confidence Score: 5/5

Safe to merge; the throttling logic is correct for all documented code paths and the new tests confirm the expected behaviour end-to-end.

The org-path refactor (deferring client creation until after the count check) is correct and well-tested. The service_detail parameter, _normalize_service_detail guard, and serviceSummary metadata are all internally consistent. No existing behaviour is regressed: API-key-project mode is unaffected, and services are still fetched whenever project_id is specified or the project set is small.

The accessible-resources fallback in context.py (lines 102–112) still creates project clients eagerly before the count threshold is evaluated — a minor inconsistency worth a follow-up, but not a blocker.

Important Files Changed

Filename	Overview
src/mcp_server_appwrite/context.py	Core change: defers project-client creation to after candidate collection for the org path, computes effective_include_services based on project count, adds service_detail parameter and serviceSummary metadata. Logic is correct; the accessible-resources fallback still creates clients eagerly (pre-existing pattern).
src/mcp_server_appwrite/operator.py	Adds service_detail enum field to the tool schema and updates include_services / sample_limit descriptions to clarify the new throttling behaviour.
src/mcp_server_appwrite/server.py	Wires service_detail through _get_context_for_request, normalizing it with _normalize_service_detail before forwarding to get_appwrite_context.
tests/unit/test_context.py	Adds five new test cases covering: large-org fanout suppression, small-org samples mode (oauth_console), focused project in large org, explicit include_services=False, and invalid service_detail fallback. Existing tests updated to assert items absence and check new serviceSummary shape.

_{Reviews (2): Last reviewed commit: "Address context review feedback" | Re-trigger Greptile}