Mark Schreiber
90d · built 2026-09-10
Performance
What Mark Schreiber shipped in the selected window, measured in ETV, and how it compares with the 90 days before it.
Effective capacity
+0.7engineers
delivers like 1.7 (1.7x pre-AI)
Output (ETV)
17.5ETV
+343.0% vs 4.0 prior
Features share
21.8%
+12.9 pp vs prior window
Fixes share
0.1%
−2.9 pp vs prior window
Work mix
21.8% Features0.4% Maintenance72.2% Tests5.5% Docs0.1% Fixes
3 commits over 90 days, ending 2026-09-10.
Where this dev ranks
Percentile against the global top-100 leaderboard (all-time totals).
- By commits
- Top 100 %
- By Features share
- Top 89 %
Daily performance
Daily ETV, stacked by Features, Maintenance, Tests, Docs and Fixes.
Repository spread
Where this developer's commits land. Concentrated work (top1 > 80%) vs polymath spread (top1 < 30%).
Most impactful commits
Top 10 by ETV in the last 90 days.
- 16.5ETVfeat(healthomics): remote transport & multi-tenant credentials (#4269) * feat(transport): add HTTP/SSE transport selection and credential-resolution seam (Phase 1) Phase 1 of remote-transport-multi-tenant. Purely additive: with no new configuration the server behaves exactly as today (stdio + default credential chain + identical tool signatures). - Transport selection (stdio/streamable-http/sse) via CLI flags and env vars with CLI-over-env precedence and case-sensitive normalization. - Network bind configuration (host/port/path) with loopback defaults (127.0.0.1:8000/mcp) and host/port validation. - Secure-by-default: single warning before binding to a non-loopback host; no inbound auth performed in Phase 1. - CredentialResolver seam + DefaultCredentialResolver in utils/aws_utils.py; all tool sessions/clients routed through the active resolver. - Docs (README) and Dockerfile network transport support via env vars. - Property and unit tests for config, transport, exposure, credential seam routing, resolution failure, and tool-surface preservation. * feat(multi-tenant): add request-scoped credential resolution, identity middleware, and inbound mechanisms (Phase 2) Adds Phase 2 multi-tenant credential resolution on the Phase 1 seam: - RequestScopedCredentialResolver deriving fresh per-request credentials from a contextvars-carried CredentialContext (no fallback, no process-level reuse) - ASGI IdentityMiddleware that sets/resets the context around dispatch and rejects unauthenticated requests with 401 before any tool or AWS call - Inbound mechanisms with deterministic precedence sigv4 > jwt > explicit: forwarded-SigV4, JWT-to-STS AssumeRole with ABAC session tags, explicit headers - Multi-tenant config parsing (--multi-tenant/--inbound-auth), incompatible with stdio; fail-closed startup guard when no mechanism is enabled - Per-identity, bounded partition cache keyed by (identity_key, region) - Credential material never logged (redacted CredentialContext repr) Review hardening: bounded partition cache; pyright-visible get_partition.cache_clear via a callable Protocol; startup rejection of multi-tenant with zero mechanisms. Docs: README multi-tenant section and CHANGELOG entry. * feat(healthomics): add multi-tenant identity resolution with JWT and SigV4 support (Phase 3) - Add role resolver mechanism with static and DynamoDB registry sources for per-request credential resolution - Implement JWT exchange mechanism with external ID enforcement and backward compatibility - Add multi-tenant server wiring with request-scoped credential isolation and identity propagation - Introduce inbound authentication mechanisms (SigV4, JWT, explicit) with fixed precedence ordering - Add comprehensive security property tests covering tenant isolation, secret leakage prevention, freshness validation, and registry consistency - Update MCP_INSPECTOR_SETUP.md with transport modes and multi-tenant configuration documentation - Add conftest fixtures for multi-tenant test infrastructure and DynamoDB mock registry - Validate credential material is never logged and request identities are properly propagated across AWS service calls * docs(healthomics): clarify multi-tenant security model and fronting layer requirements - Expand security documentation to clarify that multi-tenant mode adds per-request identity without changing inbound authentication responsibility - Explain that the server trusts forwarded credentials and does not validate SigV4 signatures or verify JWT signatures cryptographically - Clarify the difference between non-loopback binding (expected in orchestrated deployments) and unsafe unauthenticated exposure - Document that non-loopback binding requires external access control at the fronting layer, not within the server process - Update AgentCore Runtime references to remove "(Phase 2)" notation and reflect production-ready multi-tenant support - Refactor role resolver to implement deterministic precedence order for inbound mechanisms (sigv4 > jwt > explicit) - Add detailed precedence documentation for mechanism selection when multiple are enabled - Clarify that SigV4 mechanism requires trusted headers forwarded by fronting layer and fails closed if absent - Document JWT mechanism expectations around token exchange, role assumption, and fronting layer signature verification responsibility * feat(integration): add remote-deployment integration test harness * fix(pricing): build pricing client per request for multi-tenant isolation PricingCache cached the AWS Pricing client on the class, so in multi-tenant mode the first cost-analysis caller's request-scoped credentials were frozen into the client and reused for every subsequent caller -- violating the documented per-request credential isolation guarantee ('no process-level or prior-request session is ever reused'). Build the pricing client per call instead (it is only built on a price cache miss). The public, non-tenant-specific price *values* remain cached, so overhead is negligible while each request's AWS calls stay scoped to that request's identity. Remove the now-unused _pricing_client class attribute and the test lines that reset it. Also correct integration/README.md: AgentCore container port 8080 -> 8000 (the fixed MCP port), document the injected server env accurately (MCP_INBOUND_AUTH jwt|explicit, injected AWS_REGION, and the entrypoint's stateless/DNS-rebinding/ header-forwarding adaptations), and clarify the sts:AssumeRole/TagSession IAM row for jwt vs --inbound explicit. * docs(changelog): release pending items as v0.0.41; add remote MCP integration harness as Unreleased * security(integration): keep provisioning capability out of deployed artifacts The integration harness can create AWS infra and shells out via subprocess, so it must never be reachable from a deployed MCP server. Harden isolation: - Slim the harness AgentCore image: copy only the runtime entrypoint and shared header constants into the container, not the deploy/ provisioning modules (agentcore, apigateway, cli, iam, cognito, registry, common) or the test suites. A compromise of the running server can no longer reach infra-provisioning code. - Add a fail-closed opt-in guard to the deploy CLI: provision/teardown/e2e refuse to run unless RUN_REMOTE_INTEGRATION_TESTS is truthy, so provisioning cannot be triggered incidentally by an automated or compromised context. - Add an offline regression test asserting the image Dockerfile never bundles the provisioning/test modules and the entrypoint imports only integration.harness.headers. - Document the isolation posture and the CLI opt-in requirement in the README. Note: the published wheel already excludes integration/ (packages=['awslabs']) and the production ./Dockerfile ships only the installed venv, so pip/uvx and the production image were already free of the harness; this closes the test-image and source-run gaps. * ci: exclude integration test artifacts from Trivy and Bandit - Skip integration/ Dockerfiles in Trivy workflow (not needed in CI) - Add integration/ to bandit exclude_dirs to prevent false positives from deployment/provisioning code breaking the build * test: add edge-case tests for transport, mechanisms, and multi-tenant config Cover previously uncovered branches in PR-changed source files: - transport.py: normalize whitespace-only, select None/valid mode - mechanisms/explicit.py: malformed header decode exception path - mechanisms/jwt_exchange.py: STS client creation, malformed token claims - mechanisms/role_resolver.py: parse_registry_source edge cases, DynamoDB client - config.py: hostname validation edges, multi-tenant invalid value, inbound mechanisms - utils/aws_utils.py: FieldInfo coercion, partition cache hit/miss/eviction, client wrappers * test: stop tests reaching real AWS, narrow tool-surface guard Fix an effective hang in the test suite. generate_run_timeline and the run-analysis manifest parsers compute per-task cost, which reaches PricingCache.get_price -> _fetch_price_from_api and issued a real AWS Pricing API request. The autouse mock_environment fixture supplies dummy credentials, so resolution succeeded and the call proceeded to the network rather than failing fast. get_price caches only successful lookups, so a failed fetch was retried for every task, and the property-based timeline tests generate up to 500 tasks per Hypothesis example. Add an opt-in stub_pricing_lookup fixture in conftest.py and apply it to the affected modules. get_price is the single seam every network-bound pricing path funnels through, so stubbing it keeps the real cost arithmetic exercised while guaranteeing no AWS call leaves the process. Kept opt-in so test_pricing_cache.py and test_cost_analyzer.py retain control of PricingCache. Also stub get_run_manifest_logs_internal in two troubleshooting tests that left it unmocked and passed only because the real CloudWatch Logs call failed and degraded gracefully. Replace the frozen tool-surface snapshot with assertions on the invariant the credential-resolver seam could actually break: every AWS-calling tool exposes aws_profile and aws_region as optional nullable strings defaulting to None, never required, with the set of static/local tools lacking them asserted exactly. The 3818-line baseline compared full equality, so it failed on any unrelated tool change anywhere in the server (it broke on the workflow_type filter added upstream for Ready2Run discovery). Measured with AWS_ENDPOINT_URL=http://127.0.0.1:1 to prove isolation: - test_run_timeline_output.py: did not finish in 600s -> 46 tests in 1.5s - full suite: 107.67s -> 57.11s, slowest test 29.58s -> 2.00s * fix(test): resolve pyright errors in transport/multi-tenant edge tests CI runs pyright over the package and reported 12 errors in this file. Fixes, none of which reduce branch coverage (still 98% on the PR-changed sources): - Drop the two tests passing None to parameters typed str (ServerConfig.transport and _is_valid_hostname). Both were outside the declared contract; the empty and whitespace-only cases already exercise the same branches, and normalize(None) is still covered directly since it accepts Optional[str]. - Use a real pydantic FieldInfo via Field(default=None) instead of a bare object() for the FastMCP coercion tests. Field() is annotated as returning Any so it type-checks, and it is what the defensive coercion actually guards against. - Remove the redundant mock.__class__ assignments. MagicMock(spec=...) already satisfies the isinstance() check that _get_partition branches on. - Replace set_credential_context(None) with the real token-based API: reset_credential_context(token) for teardown, and _credential_context.set(None) where the test needs to assert the no-identity precondition explicitly. Verified locally: pyright 0 errors across the package, ruff check/format clean, bandit medium/high 0, full suite 2794 passed offline. * fix(healthomics): rename integration Dockerfile to avoid touching trivy.yml Renaming integration/deploy/image/Dockerfile to mcp.Dockerfile means the trivy workflow's `find . -name Dockerfile` no longer matches it, so the integration harness image is naturally excluded from Dockerfile-detection without editing .github/workflows/trivy.yml. That keeps this PR from touching a workflow file, which otherwise requires a maintainer to re-approve CI on every push. * fix(healthomics): port transport/multi-tenant serving and the integration harness to mcp SDK v2 main's mcp SDK v2 migration (#4452) moved host/port/streamable_http_path/sse_path off FastMCP.settings and onto run()/streamable_http_app()/sse_app() keyword arguments, renamed FastMCP -> MCPServer, and renamed a few other v1 names this branch's new code depended on before the merge conflict in server.py could be resolved cleanly: - transport.py: TransportSelector no longer mutates mcp.settings; it passes host/port/path straight through as mcp.run() keyword arguments. - server.py: _run_multi_tenant calls streamable_http_app()/sse_app() with host/path kwargs instead of mutating settings; _serve_asgi_app takes the resolved config for host/port (log_level is still read from mcp.settings, which v2 keeps). - tests/test_transport.py, tests/test_transport_exposure.py, tests/test_server_multitenant_wiring.py: updated to assert against the new run()/streamable_http_app()/sse_app() call kwargs instead of settings attributes. - tests/test_tool_surface.py: tool.inputSchema -> tool.input_schema (v2 alias-read asymmetry, same class of fix the mainline migration applied elsewhere). - integration/deploy/image/entrypoint.py: stateless_http/transport_security also moved off settings in v2; replaced the settings-mutation harness glue with a wrapper around mcp.streamable_http_app()/sse_app() that injects them as defaults (covers both the single-tenant mcp.run() path and the multi-tenant direct-call path without touching server-package source). - integration/harness/mcp_client.py: mcp.client.streamable_http.streamablehttp_client -> streamable_http_client, which now takes an httpx2.AsyncClient (for headers/timeout) instead of headers=/timeout= kwargs, and yields a 2-tuple instead of a 3-tuple. - integration/tests/test_unauthenticated_rejected.py: httpx -> httpx2 (v1's httpx is no longer a transitive dependency under mcp[cli]>=2.0.0). tests/ (2794 passed), integration/harness_tests/ (150 passed, offline), ruff, and pyright are all clean on the merged tree.github.com-awslabs-mcp · f6f1a566 · 2026-08-31
- 1.0ETVfeat(healthomics): adds support for start-run and start-batch-run scratch storage modes (#4041)github.com-awslabs-mcp · 4fdc3bcf · 2026-06-29
- 0.0ETVfix(healthomics): use batchName parameter in StartRunBatch call (#4089) The start_run_batch tool passed the batch name to the boto3 StartRunBatch API under the key 'name', which is not a valid parameter. The API expects 'batchName'. This caused parameter validation errors whenever a batch name was supplied. Update the parameter key and the corresponding test assertion.github.com-awslabs-mcp · 18ba73c0 · 2026-07-06