--- name: government-context description: >- Research U.S. federal government activity through the Government Context MCP server (mcp.governmentcontext.com): rulemakings and their public comments (with stance/campaign analytics), agency press releases, grants, bills, amendments, roll-call votes, hearings, committees, legislators, organizations' lobbying/awards/FEC activity. Use when asked who supports or opposes a regulation, what an agency/committee/organization has been doing, how a legislator voted, or to monitor a policy area. --- # Government Context MCP server Government Context mirrors federal policy data and enriches it (comment stance, commenter types, form-letter campaign detection, issue tagging, policy-topic classification). You interact through 23 `gc_*` tools. A free account works for the core workflows below; free-tier data runs one release cycle behind and permits 25 active follows (details in "Gating" — always relay the `gated` tail to your user instead of retrying). ## The mental model (3 concepts) - **Views** are followable contexts: a rulemaking document, policy topic, agency, organization, legislator, bill, or committee. `gc_search` marks them `followable: true`; they are valid `gc_list_activity` scopes and `gc_follow` targets. - **Activity groups** are kinds of happenings: `rulemaking`, `press`, `grants`, `legislative`, `lobbying`, `awards`, `fec`. - Every activity question is *which View × which groups*. "What has the EPA done lately?" → scope EPA, default groups. "Who lobbied on AI?" → topic scope + facets, then organization scopes. ## Core workflows **Research a regulation end to end** 1. `gc_search {query: "PFAS drinking water", types: ["rulemaking"]}` → pick the id. 2. `gc_get_rulemaking {id}` → status, deadline, stance overview. 3. `gc_list_comments {rulemaking_id, stances: ["oppose"], commenter_types: ["trade_association", "business"]}` → who opposes. 4. `gc_get_comment {id}` for full text; add `include_attachment_text: true` only when you need attachment contents (they're long). 5. `gc_analyze_comments {rulemaking_id, sections: ["campaigns"]}` (paid) → form-letter campaigns vs organic; `["position_map"]` → org × issue positions with evidence quotes. You narrate; the numbers come from here. **Monitor a policy area** 1. `gc_search {types: ["topic"]}` (browse) or a keyword search → topic slug. 2. `gc_list_activity {scope: {type: "topic", id}, include_facets: true}` → what's actually happening there. 3. `gc_follow {target: {type: "topic", id}, cadence: "daily"}` — email digests. Anything `followable: true` in search results works the same way (agencies, organizations, bills, legislators, committees, and individual rulemakings). **Legislative research** - Bill: `gc_get_bill {id: "119/hr/3076"}` → stage, sponsor, cosponsor split, recent actions, votes, hearings, amendments. Complete action history: `gc_list_activity {scope: {type: "bill", id}}`. - **A legislator's complete voting record**: `gc_list_activity {scope: {type: "legislator", id: "S000033"}, event_types: ["legislator.voted"]}` — the narrowing is what switches from the recent-activity feed to the complete roll-call record (the `coverage` field confirms: `complete` vs `since`). - Committee roster history: same trick with `event_types: ["committee.member_joined", "committee.member_left"]`. - **A bill's actual text**: `gc_get_bill_text {id: "119/hr/3076"}` → the official Congress.gov XML as Markdown, plus an outline of its sections. For anything longer than a few pages, work by section instead of paging: `gc_list_bill_sections {id}` → ids like `sec-101` with their headings and place in the title/division hierarchy → `gc_get_bill_text {id, sections: ["sec-101"]}`. Section ids belong to one text version (numbers change between prints), and simple resolutions have none — those come back whole. When a bill has no mirrored text yet the result says so and links to congress.gov; don't retry. - Amendments: `gc_list_bill_amendments {id: "119/hr/3076"}` for every amendment offered to a bill, or `gc_get_amendment {id: "119/samdt/2137"}` for one. When `has_text` is true, use `gc_get_amendment_text` and its cursor to retrieve the complete text. Congress publishes amendment text as Congressional Record pages, so it arrives as plain text (`representation: "plain_text"`), not Markdown. - Hearings: `gc_search {types: ["hearing"]}` (browse lists upcoming first) → `gc_get_hearing` for witnesses (with organization links) and related bills. Hearings can't be followed — follow their committee or topic instead. Watch for `hearing.updated` activity items whose `facts.change` is `rescheduled`, `postponed`, or `canceled`. **Organization intelligence** `gc_search {query: "", types: ["organization"]}` → `gc_get_organization {id: slug}` (comment stats, lobbying, awards, political giving) → `gc_list_activity {scope: {type: "organization", id}, groups: ["lobbying"]}` for the complete filing history (same for `["awards"]`, `["fec"]`). ## Rules of the road - **Ids are natural keys** from `gc_search` — never invent them. Bills: `congress/type/number`. Press releases: `AGENCY/slug`. Legislators: bioguide id. Committees: system code. Hearings: Congress.gov event id. - **Search takes keywords, not sentences** (Postgres websearch: quoted phrases, OR, `-exclusion`). No pagination in query mode — refine the query. Browse mode (no query, exactly one type) paginates. - **Rulemaking search defaults to open comment periods.** Pass `filters: {open_for_comment: false}` only when the user explicitly asks for closed comment periods; do not broaden a rulemaking search to closed periods preemptively. - **Trust `coverage`**: `complete` means the full record; `since` means the tracked feed (Government Context is recent-focused, not an archive). - **Gating (free tier)**: continuous data is 7 days delayed; the latest quarterly lobbying/FEC period is withheld; grants and deep comment analytics are paid. Current overview aggregates may include comments whose underlying evidence is still delayed. Gated responses still answer with what's visible plus a `gated` tail — tell your user what was withheld and that the paid plan includes it. An embargoed comment returns its existence, not a 404. - **Errors tell you the next call** — follow them literally. - **When data is missing or wrong, file it**: `gc_submit_feedback` with `category: "missing_data"` (+ `desired_source`) or `"data_error"`. Include `user_goal` when your user consents — it directly shapes the roadmap. This is expected behavior, not a failure state.