# Missing capabilities and verification gaps

Reviewed 8 November 2026 against local `connect-api` source and its MCP verification ledger. “Missing” below means no established external/MCP contract was found; related internal application functionality may exist. Website changes do not implement these backend capabilities.

## Missing or partial MCP tools

| Requested capability | Current gap / dependency |
| --- | --- |
| `get_employee_schedule` | No external planned-shift mapping; worked shifts are not planned schedules. |
| `get_employee_availability` | No established availability/date/department contract; absences alone do not prove availability. |
| `get_unfilled_shifts` | No bounded external unassigned-shift contract. |
| `get_scheduling_conflicts` | No existing conflict-result contract exposed; gateway must not invent scheduling rules. |
| `get_employee_time_reports` | Partial REST candidate: worked shifts and summary exist, but pay exclusion, actual filter behavior, date semantics and bounds need verification. No MCP tool. |
| `get_overdue_work_orders` | Generic list does not establish canonical overdue rules/filter. |
| `get_work_order_history` | No dedicated bounded operational-history contract. |
| `get_field_worker_status` | No current operational-status contract; employee lists and shifts do not establish status or GPS permission. |
| `get_contractor_availability` | No contractor/date availability projection. |
| `list_contractor_assignments` | Agreements/general work orders do not establish assignments by contractor/date. |
| `list_property_defects` | Partial: REST has act-level defects, not bounded property-level traversal/filtering under current actor scope. |
| `get_property_defect_details` | No direct external defect-ID detail contract found. |
| `list_supplier_bids_for_property` | Internal procurement exists; external delegated property/audience-safe projection is absent. Supplier tools only expose invited opportunities and own status. |
| `get_property_maintenance_history` | Inspection history and work-order lists exist separately; no unified authorized chronology. |
| Operational write tools | No MCP create/update/delete operations. REST writes do not imply MCP write availability. |

Source: sibling `docs/mcp-gateway-api-mapping.md`. New tools need exact endpoint, schemas, minimized fields, current authorization, pagination/time semantics and passing persistence/protocol/security evidence before discovery.

## API documentation gaps still present upstream

The fresh local audit passes route/method/scope parity for 144 business methods (146 including metadata). That audit does not certify every response field or handler semantic.

- Several JSON reads have unspecified success fields, including GET `/time/worked-shifts`, `/time/summary`, `/expenses`, `/absences`, `/absences/{absenceId}`, `/compensations`, `/work-orders/{workOrderId}`, `/inspections/acts/{actId}`, `/inspections/acts/{actId}/versions`, and `/attachments`. See the complete generated [response schema review](integration-schema-gaps.md). Local copies preserve the source rather than invent fields.
- Report downloads intentionally use binary responses. PDF upload success statuses have no response content schema; upstream should document whether each response is empty or returns metadata. A response without a JSON schema alone is not a missing method.
- Worked-shift shared query fields include filters that its SQL does not all apply; count is page length. Pagination is not uniform across REST operations. MCP adapters document their own normalized pagination.
- Delegated OpenAPI projections mainly describe success; error shape/status coverage is incomplete. Use MCP catalogue error semantics and do not assume the API-key error description applies to OAuth tokens.
- This snapshot documents the external API and MCP supporting routes, not every internal application route or every API Portal management action. Staff administration remains in the authenticated staff application.

## Open deployment and release gates

The source ledger reports local HTTP/SDK/PostgreSQL/Redis and rendered consent component coverage for all ten tools. Its fixtures do not certify full production migrations/triggers, provider-backed resident/supplier login or a deployed browser journey.

Outstanding evidence: hosted CI; actual image build/publication; production-like startup with full migrations; stable HTTPS gateway/issuer and exact external-client registration/callback interoperability; proxy/egress/TLS policy; measured load and replica limits; alerts; secret rotation; rollback. Dynamic client registration and client metadata documents are not implemented. There is no verified deployed gateway URL or client connection result from this website task. No app listing, review or production enablement is claimed.

The upstream ledger records 11 supplier dependency audit findings (9 moderate, 2 high). This is a reported historical local result, not a fresh dependency audit from this website task.

## Website follow-up

The previous feasibility document incorrectly described the now-implemented gateway as absent; it is marked superseded. Integration highlights are translated in all 13 site languages; technical method/schema documentation remains English and the developer page says so. A full technical-reference translation remains future work. Local snapshots must be refreshed when the backend changes; normal website builds deliberately do not depend on sibling repositories.