Connecting an account is the beginning

My personal university connectors started from ordinary work: what is due next, where is that lecture, which document changed, and what feedback came back? Answering those questions meant joining course pages, files, calendars, and account-bound sessions. The tool list was not the product. The connected task was.

That is the rule I would bring to other MCP work. Start with the job, then expose the few reads and actions needed to do it. Tool names should be clear, results should include useful source references, and failures should tell the user which connection or permission is missing.

A connector should know which account a session belongs to. Routine reads can try a silent refresh. If the provider needs MFA, a password, or fresh consent, the tool should return that requirement instead of surprising the user with an invisible login flow. Interactive login belongs at the edge where the person asked for it.

MCP authorization and upstream provider sessions are related but different. The MCP server can expose tools and enforce access to them, while the connector still has to handle the real account behind each upstream service. Before a write, the system should check the account again, even when the previous read worked.

For submissions and other writes, preparation and confirmation should be separate. The preview should identify the destination and the literal files, fields, or text involved. Confirmation applies to that exact operation, not to a vague intent hidden somewhere in a previous prompt.

Retries need the same care. A failed read is usually safe to repeat. A write whose response disappeared may already have happened. The connector should keep that distinction visible. The model can then concentrate on the work instead of guessing whether surrounding software is safe, connected, or allowed to act.