Connectors Turn Advice Into Work—and Add Dependencies

The connector layer is where the knowledge-work-plugins repository’s role instructions meet an organization’s actual systems. This chapter focuses on the difference between a portable workflow category and a configured vendor endpoint, and on the judgment that follows: what can the plugin safely observe or change when a connector is available, incomplete, or absent? The answer is not “whatever the category name suggests.” It depends on the live tool’s schema, permissions, coverage, and failure behavior.

Portability starts with a category, not a vendor

A plugin can describe a workflow in terms such as ~~chat, ~~project tracker, or ~~data warehouse. These placeholders name the kind of work the workflow needs without hard-coding one company’s product into every instruction. A skill can say to check the project tracker for open work, or post a summary to chat, while a connector map explains which services are included and which alternatives may be substituted.

This abstraction protects the durable part of a workflow. The reason to search a project tracker does not disappear when one organization moves from Asana to Linear or Jira. The reason to consult a data warehouse does not depend on whether the company uses Snowflake, Databricks, or BigQuery. By keeping the work category stable, the repository can distribute a role pattern that is not tied to one procurement decision.

But a category is not an interface specification. “Project tracker” does not tell us whether the connected service exposes the same status names, hierarchy, permissions, custom fields, or search behavior. “Chat” does not tell us whether a message can be posted to a private channel, whether a thread can be addressed, or whether the user has the right to speak as the account. “Data warehouse” does not tell us which tables exist, what their freshness is, or which SQL dialect applies.

The repository’s connector maps make this limit visible. The productivity package lists chat, email, calendar, knowledge-base, project-tracker, and office-suite categories with included servers and alternatives. The legal package maps categories such as cloud storage, CRM, email, e-signature, and project tracking to different possible services. The finance package marks some categories as having no supported MCP server yet, while still identifying plausible alternatives such as ERP, accounting, and analytics tools. A placeholder preserves intent; it does not erase the gap between intent and implementation.

That gap is why portable skills need to use categories carefully. A workflow that assumes every project tracker has a field called “stage” may work in one environment and fail in another. A workflow that says “read the live schema and use the labels it provides” is more portable because it moves the vendor-specific decision to the point where the system can be inspected. Portability is therefore produced by a combination of abstraction and grounding: abstract the category, then verify the concrete service.

The connector maps serve as the visible bridge between those two levels. They tell a potential user which services are included, which alternatives are plausible, and where no supported server is configured. That information is more useful than a long list of vendor names because it exposes the assumptions behind installation.