Stop opening several tools to answer one business question.

ChatGPT, Claude or Grok can be the conversational interface.

AlefOS provides the authorized operational memory behind the answer.

That means a user can ask real work questions instead of searching separate tools:

• Who should I call back?
• What happened with this customer?
• What did the meeting decide?
• What was promised on WhatsApp?
• What should I prepare before my next appointment?
• Which mission needs approval?

The assistant should answer from AlefOS context that is available, authorized and scoped to the current user.

It should not guess when information is missing.

MCP Cockpit is the controlled AlefOS surface for supported AI assistants.

It is not a raw API, a debug panel or an unrestricted database browser.

The assistant asks through MCP.

AlefOS checks identity, plan, workspace, permissions and available memory.

AlefOS returns scoped business context and, when useful, prepares the next action for review.

The user remains responsible for protected execution.

AlefOS does not hand the assistant every workspace record.

It exposes usable context through permission-aware tool families.

The answer can include what is known, what is missing, why the item matters and which action can be prepared.

This matters for business data because the user usually needs context, not tables.

For example, a customer question may require a previous WhatsApp promise, a call summary, a meeting decision, a calendar appointment and an open mission.

MCP Cockpit helps the assistant query that connected memory without turning AlefOS into a generic data dump.

Depending on the current user, plan, workspace and available integrations, the assistant can query:

• contacts and customer context
• missions, callbacks and pending approvals
• groups and shared decisions
• call context when available
• authorized WhatsApp Business context when available
• meeting notes, summaries or transcripts when available
• calendar appointments and preparation context
• follow-ups and customer commitments
• manager-visible signals inside authorized Team scope

Each surface remains scoped.

The assistant should only see what the user or manager is allowed to access.

AlefOS can help an assistant prepare work without executing it silently.

Examples:

• a customer message draft
• a follow-up mission
• a meeting preparation brief
• a calendar action for review
• a group summary or update
• a manager briefing
• a list of customers waiting for a reply
• a next-step recommendation based on available context

Preparation is not execution.

The assistant can help draft, summarize, structure and suggest. Protected actions still require user confirmation.

Protected actions must not happen silently.

Examples:

• prepare a WhatsApp message, but do not send it
• prepare a group post, but do not publish it
• prepare a calendar event, but do not create it without approval
• prepare a mission or assignment, but keep it inside the authorized workflow
• prepare a company-memory update, but do not change shared context silently

The working rule is simple:

memory first, action second, validation for protected actions.

A customer history rarely lives in one tool.

One answer may require:

• the WhatsApp request
• the call that clarified the objection
• the meeting decision
• the calendar appointment
• the contact context
• the open mission
• the manager signal

A user can ask:

"What should I know before replying to this customer?"

AlefOS can assemble the authorized context that exists across those sources.

If a source is missing, unavailable or outside scope, the assistant should say so.

AlefOS publishes connection endpoints for supported assistants.

Documented endpoints:

• ChatGPT: https://alefos.org/mcp/gpt
• Claude: https://alefos.org/mcp/claude

Grok access may use an authenticated personal AlefOS MCP URL when available for the user.

The documentation can describe the supported assistant path, but the runtime still controls authentication, onboarding, workspace access and permissions.

An assistant connection is not useful until AlefOS knows whose memory it is allowed to query.

AlefOS exposes two MCP surfaces.

The public product MCP is for public product understanding:

• AlefOS public product assistant: https://alefos.ai/mcp/public

It can explain AlefOS, recommend a plan, search public documentation and show safe demo scenarios without user account data.

Private MCP access is for authenticated users and supported assistants.

It can require:

• user authentication
• workspace selection
• onboarding completion when required
• plan verification
• permission checks
• confirmation that the assistant connection is allowed

Private endpoints are not debug URLs and not public database endpoints.

MCP access depends on plan, role, workspace configuration, permissions and available integrations.

Free may expose limited personal AlefOS access.

Solo gives one user personal operational memory.

Team gives companies shared memory, manager visibility and permission-based scopes.

The assistant should never assume every module, source or action is available.

When access is limited, AlefOS should answer clearly rather than inventing data or exposing something outside scope.

A raw API exposes endpoints.

MCP Cockpit exposes an assistant-ready business surface.

The difference matters.

An assistant does not only need data. It needs context, permissions, action rules and safe workflows.

MCP Cockpit gives supported assistants a way to ask operational questions and prepare work while respecting AlefOS boundaries.

A provider MCP may let an assistant search or act inside one provider.

That can be useful, but its scope may remain limited to that provider.

AlefOS MCP Cockpit is different: it lets the assistant query authorized operational memory that can connect several sources:

• calls
• WhatsApp
• meetings
• calendar
• contacts
• groups
• missions

AlefOS should not describe a provider MCP as automatic AlefOS ingestion.

The question is whether authorized data can become connected operational context inside AlefOS.

Public documentation should describe what users and assistants can do without exposing internal implementation names.

Useful public families include:

• memory search and retrieval
• contact context
• mission and approval review
• group decisions
• call context when available
• calendar context and prepared calendar actions
• draft preparation
• confirmation workflows
• manager-visible operational signals

Internal method names, raw IDs and private implementation details should stay out of the public documentation unless they are intentionally published as a stable API.

Documentation explains product behavior.

The MCP runtime is the live operational surface used by authenticated assistants.

They should not be confused.

Public documentation can describe:

• product behavior
• public endpoints
• module concepts
• plan-safe capabilities
• assistant usage patterns

The MCP runtime should not expose:

• Private tenant data outside scope.
• Secrets.
• Debug responses.
• Internal-only tools.
• Unfinished features.
• Raw database structures.

Documentation helps AI systems understand AlefOS.

Runtime MCP lets authorized assistants work with AlefOS.

The assistant should not fill gaps with generic guesses.

If a transcript is missing, it should say the transcript is unavailable.

If a WhatsApp conversation is outside scope, it should say that context is not available.

If a calendar action requires confirmation, it should prepare the action for review.

If a manager lacks permission, AlefOS should keep the data outside that scope.

Trust depends on clear boundaries.

A user asks:

"Who should I call back today?"

The assistant can ask AlefOS through MCP.

AlefOS can inspect visible contacts, missions, calls and calendar context.

The answer may include:

• Customers waiting for a callback.
• Why each callback exists.
• What was promised.
• Which follow-ups are late.
• Which message can be prepared.

If a message or action is prepared, the user validates before it is sent or executed.

A manager asks:

"Which cases are blocked this week?"

The assistant can query AlefOS memory inside the manager authorized scope.

AlefOS can combine visible missions, group decisions, call signals, contact context and pending approvals.

The result should help the manager understand:

• Which customers are blocked.
• Which actions are waiting.
• Which users need attention.
• Which decisions are pending.
• Which follow-ups should be reviewed.

This is not a generic dashboard.

It is operational memory queried through natural language.

A user asks:

"What should I know before my next meeting?"

The assistant can ask AlefOS for calendar context, contact history, open missions, previous calls, related group decisions and missing documents.

AlefOS can return a preparation brief:

• Who is involved.
• Why the meeting exists.
• What was discussed before.
• What is still open.
• What should be prepared.
• What action may be needed after the meeting.

The calendar stops being only a date.

It becomes operational context.

MCP Cockpit should expose public product behavior and authorized user memory, not private internals.

It must not expose:

• Secrets.
• Environment variables.
• Debug routes.
• Admin-only tools.
• Tenant data outside the user scope.
• Private groups outside permissions.
• Internal logs.
• Unfinished integrations.

The MCP surface is powerful because it connects assistants to work.

That power requires strict boundaries.

MCP Cockpit is how supported AI assistants talk to AlefOS.

ChatGPT, Claude or Grok can become the conversational interface.

AlefOS provides authorized operational memory.

The assistant can ask, search, summarize and prepare.

AlefOS checks identity, scope, permissions and action rules.

The user keeps control.

The simple idea:

Connect the assistant to authorized business context.

Nothing sensitive should happen silently.

It is a controlled interface that lets a supported AI assistant query authorized business context. In AlefOS, MCP access is scoped by user identity, plan, workspace and permissions.

ChatGPT can use the documented AlefOS MCP endpoint after authentication and authorization. AlefOS then returns the context the user is allowed to access.

Yes. Claude has a documented AlefOS MCP endpoint, subject to authentication, onboarding, plan and permissions.

Grok access may use an authenticated personal AlefOS MCP URL when it is available for the user. Availability still depends on runtime access and permissions.

Depending on access, it can query contacts, missions, groups, calls, WhatsApp context, meeting context, calendar context and follow-ups when those sources are available and authorized.

No. AlefOS returns scoped operational context, not an unrestricted copy of the workspace database.

No. AlefOS can prepare a message or follow-up, but protected execution requires user review and validation.

It can prepare calendar actions or missions when supported by the plan and context. Protected actions remain subject to confirmation.

Customer messages, group posts, calendar creation or updates, company-memory changes and other protected actions should remain behind confirmation.

AlefOS checks the user, workspace, plan, role, source availability and integration permissions before returning context or preparing work.

A raw API exposes endpoints. MCP Cockpit exposes assistant-ready operational context, permission rules and preparation workflows.

The assistant should say the information is unavailable or outside scope instead of inventing a transcript, conversation, decision or action.