How a website vendor reads Title II tickets over MCP

Who this is for

Website vendors and city IT partners who already file work from an agent, and clerks who need to hand them the tickets without a second login.

What you are connecting

MCP is Model Context Protocol. Here it is a read of the same tickets already in the Title II file. ADA Title II is the rule that city and township public websites must work for people with disabilities. We look at public pages and public PDFs. We do not stamp conformance.

The clerk turns it on. The vendor reads it. It stays off until someone on the paid file turns it on.

Connect

1. Clerk opens Account and turns on MCP.
2. Clerk copies the note. The full key is in that note only once.
3. Vendor adds an MCP server named ActaPack MCP.
4. URL is the app address plus /api/mcp.
5. Header is Authorization: Bearer <your key>.

If the agent cannot add a server itself, the person adds that URL and header in the agent settings, then continues.

{
  "mcpServers": {
    "actapack-mcp": {
      "url": "https://app.actapack.com/api/mcp",
      "headers": {
        "Authorization": "Bearer <your key>"
      }
    }
  }
}

Read, then file

1. Call list_tickets for open tickets.
2. For each ticket you will act on, call get_ticket.
3. Create the issue in the tracker, board, or mail already connected in that chat.
4. Put the ticket id (for example T-ABCD) on the issue so a second run does not file a duplicate.
5. Use the Fix it steps as the issue body. Do not turn them into a legal conclusion.

An empty list means the latest file has no open tickets. Say so and stop. An unknown id means the ticket was not found. Never use this key for another city.

What this is not

This is not a conformance stamp. There is no score. Method still applies: automated checks cover only part of the work. The city attorney stays the city’s attorney. The clerk still attaches the dated file for council.