MCP访问工具

Requirements

• Windows (COM automation is Windows-only)
• Microsoft Access installed (any version that supports VBE, 2010+)
• Python 3.9+
• "Trust access to the VBA project object model" enabled in Access Trust Center

Installation

pip install mcp pywin32

Screenshot & UI automation

Screenshot & UI interaction

1. access_screenshot(db, "form", "myForm")  → capture form as PNG
2. (LLM reads the image and identifies UI elements)
3. access_ui_click(db, x=850, y=120, image_width=1920)  → click a button
4. access_ui_type(db, text="search term")  → type in a field
5. access_ui_type(db, key="enter")  → press Enter
6. access_screenshot(db)  → verify the result

Startup options

Environment variables

All three are read from the server process, so they go in the env block of your MCP client config and take effect on restart.

About the SHIFT bypass (v0.7.53). Holding SHIFT is how the server skips a database's AutoExec macro and startup form, but the key-down is a global OS event — it is not scoped to Access, so anything you type anywhere on the machine while it is held arrives capitalised (~0.3 s on every database switch, ~3 s per decompile). Turn it off if that bothers you and your databases guard their own startup, which is the cleaner fix and belongs in the database:

If Not Application.UserControl Then
  Exit Function
End If

Application.UserControl is False when Access was started via COM, so the database opts itself out under automation and needs no bypass at all. With the bypass off, AutomationSecurity and the dialog watchdog still apply — but an unguarded AutoExec macro object will run.

About exclusive opens (v0.7.55). Shared opens — the default, and what every version before this one did — cannot take a design lock. Attaching Data Macros via SaveAsText/LoadFromText, or anything routing through DoCmd.OpenTable acViewDesign, is refused for any table another Access session has open, one table at a time and without stopping the run: it finishes, reports success, and nothing changed. Turn the switch on and that becomes a single visible failure when the database is opened.

It is off by default because it is genuinely exclusive: the session holds the database between tool calls, so while the server is connected nobody else can open it. That is right for a build or a development machine and wrong for a shared front-end. access_close releases the database without stopping the server.

The switch also verifies the mode instead of trusting it. Access treats Exclusive:=True as a request: with the file already in use it opens it shared without a word, and when someone else holds it exclusively it raises nothing and leaves the session with no database at all. So the server checks the lock file before opening (refusing without touching the session), checks it again afterwards (closing the database if Access downgraded it), and names the sessions holding it in the error. A stale lock file left by a crashed Access is not mistaken for a live one. With the switch on the server also stops attaching to an already-running Access instance, which would hold the file shared.

When the switch is off, you still get told (v0.7.56). The default stays shared and nothing is refused, but if the database is already open in another Access session the server says so on the result of the call that opened it, naming the sessions holding it. Design work is what silently half-lands in that state, and the person most likely to point the server at a live front-end is the one least likely to know that. A database another process holds exclusively is also reported as a lock conflict now — Access refuses that open without an error and it used to be diagnosed as a broken AutoExec, which sent people hunting through startup code for a locking problem.

VBA References

Cross-reference

Typical workflows

Full object replacement (forms, reports, modules)

1. access_get_code   → export to text
2. (edit the text)
3. access_set_code   → reimport — binary sections are restored automatically

Troubleshooting