{
  "title": "MCP Cockpit",
  "internal_name": "MCP Cockpit",
  "slug": "mcp-cockpit",
  "url": "https://alefos.ai/documentation/mcp-cockpit",
  "json_url": "https://alefos.ai/documentation/mcp-cockpit.json",
  "summary": "Ask your AI assistant what is happening in your business and get the authorized context and next action.",
  "description": "Ask ChatGPT, Claude or Grok what is happening in your business. AlefOS brings the authorized customer context, pending follow-ups and prepared actions, without sending anything silently.",
  "category": "Core",
  "last_updated": "2026-07-23",
  "keywords": [
    "MCP",
    "AI assistant",
    "operational cockpit",
    "ChatGPT",
    "Claude",
    "Grok"
  ],
  "sections": [
    {
      "heading": "MCP endpoints",
      "content": "These are the public MCP connection endpoints for supported AI assistants:\n\n- ChatGPT: https://alefos.org/mcp/gpt\n- Claude: https://alefos.org/mcp/claude\n- Grok: https://alefos.org/mcp/grok\n\nThese endpoints are connection surfaces for supported assistants.\n\nThey are not public database endpoints.\n\nThey are not debug URLs.\n\nThey are the controlled entry points through which an assistant can ask AlefOS what the user is allowed to know or prepare."
    },
    {
      "heading": "Purpose",
      "content": "MCP Cockpit exists because AlefOS is designed to be used through natural language.\n\nThe user should be able to talk to an assistant and ask real operational questions:\n\n- Who should I call back?\n- What happened with this customer?\n- What did the team decide?\n- What missions need approval?\n- What should I prepare before this meeting?\n- Which calls created follow-ups?\n\nMCP Cockpit is not a debug panel and not a raw database browser.\n\nIt is the operational cockpit used by AI assistants to work with AlefOS from the user point of view."
    },
    {
      "heading": "What assistants can do",
      "content": "When connected and authorized, assistants can use AlefOS tools to:\n\n- Search contacts.\n- Open contact context.\n- List visible missions.\n- Inspect groups.\n- Read call context and transcripts when available.\n- View calendar context.\n- Prepare message drafts.\n- Prepare follow-ups.\n- Prepare meeting context.\n- Route protected actions through confirmation.\n- Help managers understand visible operational signals.\n\nThe assistant does not answer from generic knowledge.\n\nIt answers from AlefOS memory and from the user permissions."
    },
    {
      "heading": "What assistants should not do",
      "content": "MCP Cockpit must not turn the assistant into an uncontrolled operator.\n\nAssistants should not silently:\n\n- Send customer messages.\n- Publish in groups.\n- Create calendar events.\n- Change important business information.\n- Trigger customer-facing actions.\n- Expose private data outside the authorized scope.\n- Bypass plan limits or permissions.\n\nAlefOS is useful because it can prepare work.\n\nIt stays trustworthy because execution remains controlled."
    },
    {
      "heading": "Validation rule",
      "content": "AlefOS can prepare work, but protected actions must not be executed silently.\n\nMessages, group posts, calendar creation, product creation and other engaging actions must go through confirmation.\n\nThe principle is simple:\n\nAlefOS prepares.\n\nThe user decides.\n\nThe assistant can help draft, summarize, structure, suggest and prepare. But when an action affects another person, a customer, a group, a calendar or the company memory, the user must remain in control."
    },
    {
      "heading": "Memory surfaces",
      "content": "MCP Cockpit can expose different AlefOS memory surfaces depending on permissions and plan:\n\n- Contacts: people, companies, relationship context, history and open follow-ups.\n- Missions: callbacks, reminders, prepared messages, documents, approvals and actions to complete.\n- Groups: shared decisions, procedures, meeting summaries, objections, scripts and team knowledge.\n- Calls: important call context, summaries, transcripts when available, callbacks and promises.\n- Calendar: appointments, meeting context, preparation, follow-up and planned actions.\n- Integrations: connected and authorized business sources such as WhatsApp, Call Providers, Meeting Providers or other activated professional sources when available.\n\nEach surface remains scoped.\n\nThe assistant should only see what the user or manager is allowed to access."
    },
    {
      "heading": "Typical assistant flow",
      "content": "A typical interaction looks like this:\n\n1. The user asks ChatGPT, Claude or Grok a work question.\n2. The assistant calls the relevant AlefOS MCP tool.\n3. AlefOS checks scope, plan, permissions and available memory.\n4. AlefOS returns structured context.\n5. The assistant explains the answer in natural language.\n6. If an action is needed, AlefOS prepares it.\n7. The user validates before execution.\n\nThis is what makes AlefOS different from a normal chatbot.\n\nThe assistant is not guessing. It is connected to operational memory."
    },
    {
      "heading": "Connection lifecycle",
      "content": "MCP Cockpit is designed to support a clear assistant connection lifecycle.\n\nThe usual lifecycle is:\n\n1. The user connects an assistant to AlefOS.\n2. AlefOS verifies the user identity and workspace access.\n3. AlefOS exposes only the tools and memory surfaces allowed for that user.\n4. The assistant can query memory through MCP.\n5. AlefOS returns scoped context, not the whole database.\n6. If an action is prepared, the user keeps control before execution.\n\nThis lifecycle matters because MCP access is not only technical connectivity.\n\nIt is business access to operational memory."
    },
    {
      "heading": "Authentication and onboarding",
      "content": "Assistant access should be tied to the AlefOS user account and onboarding state.\n\nThe assistant should not receive operational memory before the user is properly identified and allowed to access the workspace.\n\nDepending on the product flow, AlefOS may require onboarding steps before assistant access is fully active.\n\nThis can include:\n\n- User authentication.\n- Workspace selection.\n- Phone or identity verification when required.\n- Plan verification.\n- Permission checks.\n- Confirmation that the assistant connection is allowed.\n\nThe goal is simple:\n\nAn assistant can be powerful only when AlefOS knows whose memory it is allowed to query."
    },
    {
      "heading": "Tool families",
      "content": "MCP Cockpit should be understood as a set of tool families, not one generic endpoint.\n\nPublic documentation should describe the families without exposing internal implementation details:\n\n- Memory tools: search visible memory and retrieve operational context.\n- Contact tools: inspect people, companies, relationship history and follow-ups.\n- Mission tools: list actions, approvals, callbacks and pending work.\n- Group tools: read shared decisions, procedures, meeting summaries and team knowledge.\n- Call tools: inspect important call context when available.\n- Calendar tools: retrieve appointment context and prepare calendar-related actions.\n- Draft tools: prepare messages, summaries and follow-ups without sending them silently.\n- Confirmation tools: route protected actions through user validation.\n\nEach tool family should respect plan limits, permissions and available integrations."
    },
    {
      "heading": "Response model",
      "content": "MCP responses should be useful to assistants, not just technically correct.\n\nA good AlefOS response should usually include:\n\n- A clear answer.\n- The relevant context.\n- The related contact, mission, group, call or calendar item when available.\n- What is known.\n- What is missing.\n- What action can be prepared.\n- Whether validation is required.\n\nThe assistant should be able to turn the response into a clear user-facing answer.\n\nThe user should not need to understand raw IDs, internal tables or implementation details."
    },
    {
      "heading": "Confirmation flow",
      "content": "Confirmation is one of the most important ideas in AlefOS.\n\nThe assistant can prepare an action, but protected actions should not happen silently.\n\nExamples:\n\n- Prepare a WhatsApp message, but do not send it.\n- Prepare a group post, but do not publish it.\n- Prepare a calendar event, but do not create it without approval.\n- Prepare a product or service update, but do not change the company memory silently.\n\nThe confirmation flow lets AlefOS be useful without becoming dangerous.\n\nThe assistant becomes a preparation layer.\n\nThe user remains the decision layer."
    },
    {
      "heading": "Assistant behavior guidelines",
      "content": "An assistant connected through MCP Cockpit should behave like a careful operator.\n\nIt should:\n\n- Ask AlefOS before guessing about work context.\n- Mention when information is unavailable or outside scope.\n- Distinguish facts from suggestions.\n- Prepare actions without executing protected actions silently.\n- Keep the user in control.\n- Avoid exposing internal implementation details unless they are relevant.\n- Respect the current user plan and permissions.\n\nIt should not pretend to know the company state if AlefOS did not provide the context.\n\nThe value of MCP Cockpit is trust: real memory, scoped access and controlled execution."
    },
    {
      "heading": "Limited access states",
      "content": "Not every user has the same AlefOS access.\n\nMCP Cockpit should handle limited access clearly.\n\nExamples:\n\n- A Discovery user may only have limited AlefOS access.\n- A Solo user may have personal operational memory but no manager cockpit.\n- A Team manager may see only the users, groups and signals inside their authorized scope.\n- A connected integration may not be available for the current plan.\n- A protected action may be prepared but require validation.\n\nWhen access is limited, AlefOS should answer clearly instead of pretending that data does not exist or exposing something incorrectly."
    },
    {
      "heading": "Public documentation vs MCP runtime",
      "content": "The documentation pages explain what AlefOS does.\n\nThe MCP runtime is the live operational surface used by assistants.\n\nThey should not be confused.\n\nPublic documentation can describe:\n\n- Product behavior.\n- Public endpoints.\n- Module concepts.\n- Plan-safe capabilities.\n- Assistant usage patterns.\n\nThe MCP runtime should not expose:\n\n- Private tenant data outside scope.\n- Secrets.\n- Debug responses.\n- Internal-only tools.\n- Unfinished features.\n- Raw database structures.\n\nThe documentation helps AI systems understand AlefOS.\n\nThe MCP runtime lets authorized assistants work with AlefOS."
    },
    {
      "heading": "Examples",
      "content": "Examples of useful MCP Cockpit questions:\n\n- What missions do I need to validate?\n- Who is waiting for a callback?\n- What did we decide in the team group?\n- Which client needs a follow-up?\n- What happened in the last call?\n- Prepare a message draft, but do not send it yet.\n- Which customers are blocked?\n- Which sales objections came back this week?\n- What should I know before my next appointment?\n- Which manager needs to review pending actions?\n\nThese are not generic AI questions.\n\nThey are business questions over the company memory."
    },
    {
      "heading": "Example workflow: customer follow-up",
      "content": "A user asks:\n\n\"Who should I call back today?\"\n\nThe assistant can ask AlefOS through MCP.\n\nAlefOS can inspect visible contacts, missions, calls and calendar context.\n\nThe answer may include:\n\n- Customers waiting for a callback.\n- Why each callback exists.\n- What was promised.\n- Which follow-ups are late.\n- Which message can be prepared.\n\nIf a message or action is prepared, the user validates before it is sent or executed."
    },
    {
      "heading": "Example workflow: manager visibility",
      "content": "A manager asks:\n\n\"Which cases are blocked this week?\"\n\nThe assistant can query AlefOS memory inside the manager authorized scope.\n\nAlefOS can combine visible missions, group decisions, call signals, contact context and pending approvals.\n\nThe result should help the manager understand:\n\n- Which customers are blocked.\n- Which actions are waiting.\n- Which users need attention.\n- Which decisions are pending.\n- Which follow-ups should be reviewed.\n\nThis is not a generic dashboard.\n\nIt is operational memory queried through natural language."
    },
    {
      "heading": "Example workflow: meeting preparation",
      "content": "A user asks:\n\n\"What should I know before my next meeting?\"\n\nThe assistant can ask AlefOS for calendar context, contact history, open missions, previous calls, related group decisions and missing documents.\n\nAlefOS can return a preparation brief:\n\n- Who is involved.\n- Why the meeting exists.\n- What was discussed before.\n- What is still open.\n- What should be prepared.\n- What action may be needed after the meeting.\n\nThe calendar stops being only a date.\n\nIt becomes operational context."
    },
    {
      "heading": "Manager use cases",
      "content": "For managers, MCP Cockpit is especially important.\n\nA manager can ask AlefOS about visible operational state without requesting manual reports from everyone.\n\nExamples:\n\n- Which follow-ups are late?\n- Which users have open missions?\n- Which customers are waiting for a reply?\n- Which calls created important signals?\n- Which group decisions still need action?\n- Which deals look warm but blocked?\n\nThe goal is not surveillance.\n\nThe goal is operational visibility with permissions and context."
    },
    {
      "heading": "Plan and permission boundaries",
      "content": "MCP access depends on the user plan, role, workspace configuration and permissions.\n\nDiscovery may expose only limited AlefOS access.\n\nSolo gives one user personal operational memory.\n\nTeam gives companies shared memory, manager visibility and permission-based scopes.\n\nThe assistant should never assume that every module, integration or action is available.\n\nIt should use what AlefOS exposes for the current user and context."
    },
    {
      "heading": "Security model",
      "content": "MCP Cockpit should expose public product behavior and authorized user memory, not private internals.\n\nIt must not expose:\n\n- Secrets.\n- Environment variables.\n- Debug routes.\n- Admin-only tools.\n- Tenant data outside the user scope.\n- Private groups outside permissions.\n- Internal logs.\n- Unfinished integrations.\n\nThe MCP surface is powerful because it connects assistants to work.\n\nThat power requires strict boundaries."
    },
    {
      "heading": "Difference from a raw API",
      "content": "A raw API exposes endpoints.\n\nMCP Cockpit exposes an assistant-ready operating surface.\n\nThe difference matters.\n\nAn assistant does not only need data. It needs context, permissions, action rules and safe workflows.\n\nMCP Cockpit gives assistants a way to ask operational questions and prepare work while respecting the AlefOS rule:\n\nmemory first, action second, validation always for protected actions."
    },
    {
      "heading": "What AlefOS is and is not",
      "content": "AlefOS is a work operating system, an operational memory, an AI cockpit for real business context and a protected execution system.\n\nAlefOS is not a generic chatbot, a manual CRM, a social network, a phone operator, a WhatsApp replacement or a replacement for the user existing scheduling tools.\n\nMCP Cockpit is the bridge between AlefOS memory and the assistant the user already uses."
    },
    {
      "heading": "Team ownership tools",
      "content": "Protected Team tools make responsibility explicit across contacts, missions and calendar work.\n\nAvailable ownership tools include:\n\n- contacts.assign\n- contacts.collaborators_list\n- contacts.collaborator_set\n- contacts.collaborator_remove\n- missions.assign\n- calendar.assign\n\nAn assistant can prepare an assignment, reassignment, return to the company queue or section-level collaboration change only within the authorized scope.\n\nPermission checks and audit trails still apply. A collaborator never silently takes over or impersonates the primary owner."
    },
    {
      "heading": "Key takeaway",
      "content": "MCP Cockpit is how AI assistants talk to AlefOS.\n\nIt turns ChatGPT, Claude or Grok into a controlled interface for work memory.\n\nThe assistant can ask, search, summarize and prepare.\n\nAlefOS checks memory, permissions and action rules.\n\nThe user keeps control.\n\nThe simple idea:\n\nTalk to your assistant.\n\nAlefOS knows the work.\n\nNothing sensitive should happen silently."
    }
  ],
  "typical_questions": [
    "What missions do I need to validate?",
    "Who is waiting for a callback?",
    "What did we decide in the team group?",
    "Which client needs a follow-up?",
    "What happened in the last call?",
    "Prepare a message draft, but do not send it yet."
  ],
  "related_pages": [
    "contacts",
    "missions",
    "ibox",
    "groups",
    "calls",
    "calendar",
    "solo",
    "team",
    "team-ownership",
    "contact"
  ],
  "important_notes": [
    "AlefOS prepares. The user decides.",
    "Protected actions must go through confirmation before execution."
  ],
  "markdown": "# MCP Cockpit\n\nLast updated: 2026-07-23\n\nAsk ChatGPT, Claude or Grok what is happening in your business. AlefOS brings the authorized customer context, pending follow-ups and prepared actions, without sending anything silently.\n\n## MCP endpoints\n\nThese are the public MCP connection endpoints for supported AI assistants:\n\n- ChatGPT: https://alefos.org/mcp/gpt\n- Claude: https://alefos.org/mcp/claude\n- Grok: https://alefos.org/mcp/grok\n\nThese endpoints are connection surfaces for supported assistants.\n\nThey are not public database endpoints.\n\nThey are not debug URLs.\n\nThey are the controlled entry points through which an assistant can ask AlefOS what the user is allowed to know or prepare.\n\n## Purpose\n\nMCP Cockpit exists because AlefOS is designed to be used through natural language.\n\nThe user should be able to talk to an assistant and ask real operational questions:\n\n- Who should I call back?\n- What happened with this customer?\n- What did the team decide?\n- What missions need approval?\n- What should I prepare before this meeting?\n- Which calls created follow-ups?\n\nMCP Cockpit is not a debug panel and not a raw database browser.\n\nIt is the operational cockpit used by AI assistants to work with AlefOS from the user point of view.\n\n## What assistants can do\n\nWhen connected and authorized, assistants can use AlefOS tools to:\n\n- Search contacts.\n- Open contact context.\n- List visible missions.\n- Inspect groups.\n- Read call context and transcripts when available.\n- View calendar context.\n- Prepare message drafts.\n- Prepare follow-ups.\n- Prepare meeting context.\n- Route protected actions through confirmation.\n- Help managers understand visible operational signals.\n\nThe assistant does not answer from generic knowledge.\n\nIt answers from AlefOS memory and from the user permissions.\n\n## What assistants should not do\n\nMCP Cockpit must not turn the assistant into an uncontrolled operator.\n\nAssistants should not silently:\n\n- Send customer messages.\n- Publish in groups.\n- Create calendar events.\n- Change important business information.\n- Trigger customer-facing actions.\n- Expose private data outside the authorized scope.\n- Bypass plan limits or permissions.\n\nAlefOS is useful because it can prepare work.\n\nIt stays trustworthy because execution remains controlled.\n\n## Validation rule\n\nAlefOS can prepare work, but protected actions must not be executed silently.\n\nMessages, group posts, calendar creation, product creation and other engaging actions must go through confirmation.\n\nThe principle is simple:\n\nAlefOS prepares.\n\nThe user decides.\n\nThe assistant can help draft, summarize, structure, suggest and prepare. But when an action affects another person, a customer, a group, a calendar or the company memory, the user must remain in control.\n\n## Memory surfaces\n\nMCP Cockpit can expose different AlefOS memory surfaces depending on permissions and plan:\n\n- Contacts: people, companies, relationship context, history and open follow-ups.\n- Missions: callbacks, reminders, prepared messages, documents, approvals and actions to complete.\n- Groups: shared decisions, procedures, meeting summaries, objections, scripts and team knowledge.\n- Calls: important call context, summaries, transcripts when available, callbacks and promises.\n- Calendar: appointments, meeting context, preparation, follow-up and planned actions.\n- Integrations: connected and authorized business sources such as WhatsApp, Call Providers, Meeting Providers or other activated professional sources when available.\n\nEach surface remains scoped.\n\nThe assistant should only see what the user or manager is allowed to access.\n\n## Typical assistant flow\n\nA typical interaction looks like this:\n\n1. The user asks ChatGPT, Claude or Grok a work question.\n2. The assistant calls the relevant AlefOS MCP tool.\n3. AlefOS checks scope, plan, permissions and available memory.\n4. AlefOS returns structured context.\n5. The assistant explains the answer in natural language.\n6. If an action is needed, AlefOS prepares it.\n7. The user validates before execution.\n\nThis is what makes AlefOS different from a normal chatbot.\n\nThe assistant is not guessing. It is connected to operational memory.\n\n## Connection lifecycle\n\nMCP Cockpit is designed to support a clear assistant connection lifecycle.\n\nThe usual lifecycle is:\n\n1. The user connects an assistant to AlefOS.\n2. AlefOS verifies the user identity and workspace access.\n3. AlefOS exposes only the tools and memory surfaces allowed for that user.\n4. The assistant can query memory through MCP.\n5. AlefOS returns scoped context, not the whole database.\n6. If an action is prepared, the user keeps control before execution.\n\nThis lifecycle matters because MCP access is not only technical connectivity.\n\nIt is business access to operational memory.\n\n## Authentication and onboarding\n\nAssistant access should be tied to the AlefOS user account and onboarding state.\n\nThe assistant should not receive operational memory before the user is properly identified and allowed to access the workspace.\n\nDepending on the product flow, AlefOS may require onboarding steps before assistant access is fully active.\n\nThis can include:\n\n- User authentication.\n- Workspace selection.\n- Phone or identity verification when required.\n- Plan verification.\n- Permission checks.\n- Confirmation that the assistant connection is allowed.\n\nThe goal is simple:\n\nAn assistant can be powerful only when AlefOS knows whose memory it is allowed to query.\n\n## Tool families\n\nMCP Cockpit should be understood as a set of tool families, not one generic endpoint.\n\nPublic documentation should describe the families without exposing internal implementation details:\n\n- Memory tools: search visible memory and retrieve operational context.\n- Contact tools: inspect people, companies, relationship history and follow-ups.\n- Mission tools: list actions, approvals, callbacks and pending work.\n- Group tools: read shared decisions, procedures, meeting summaries and team knowledge.\n- Call tools: inspect important call context when available.\n- Calendar tools: retrieve appointment context and prepare calendar-related actions.\n- Draft tools: prepare messages, summaries and follow-ups without sending them silently.\n- Confirmation tools: route protected actions through user validation.\n\nEach tool family should respect plan limits, permissions and available integrations.\n\n## Response model\n\nMCP responses should be useful to assistants, not just technically correct.\n\nA good AlefOS response should usually include:\n\n- A clear answer.\n- The relevant context.\n- The related contact, mission, group, call or calendar item when available.\n- What is known.\n- What is missing.\n- What action can be prepared.\n- Whether validation is required.\n\nThe assistant should be able to turn the response into a clear user-facing answer.\n\nThe user should not need to understand raw IDs, internal tables or implementation details.\n\n## Confirmation flow\n\nConfirmation is one of the most important ideas in AlefOS.\n\nThe assistant can prepare an action, but protected actions should not happen silently.\n\nExamples:\n\n- Prepare a WhatsApp message, but do not send it.\n- Prepare a group post, but do not publish it.\n- Prepare a calendar event, but do not create it without approval.\n- Prepare a product or service update, but do not change the company memory silently.\n\nThe confirmation flow lets AlefOS be useful without becoming dangerous.\n\nThe assistant becomes a preparation layer.\n\nThe user remains the decision layer.\n\n## Assistant behavior guidelines\n\nAn assistant connected through MCP Cockpit should behave like a careful operator.\n\nIt should:\n\n- Ask AlefOS before guessing about work context.\n- Mention when information is unavailable or outside scope.\n- Distinguish facts from suggestions.\n- Prepare actions without executing protected actions silently.\n- Keep the user in control.\n- Avoid exposing internal implementation details unless they are relevant.\n- Respect the current user plan and permissions.\n\nIt should not pretend to know the company state if AlefOS did not provide the context.\n\nThe value of MCP Cockpit is trust: real memory, scoped access and controlled execution.\n\n## Limited access states\n\nNot every user has the same AlefOS access.\n\nMCP Cockpit should handle limited access clearly.\n\nExamples:\n\n- A Discovery user may only have limited AlefOS access.\n- A Solo user may have personal operational memory but no manager cockpit.\n- A Team manager may see only the users, groups and signals inside their authorized scope.\n- A connected integration may not be available for the current plan.\n- A protected action may be prepared but require validation.\n\nWhen access is limited, AlefOS should answer clearly instead of pretending that data does not exist or exposing something incorrectly.\n\n## Public documentation vs MCP runtime\n\nThe documentation pages explain what AlefOS does.\n\nThe MCP runtime is the live operational surface used by assistants.\n\nThey should not be confused.\n\nPublic documentation can describe:\n\n- Product behavior.\n- Public endpoints.\n- Module concepts.\n- Plan-safe capabilities.\n- Assistant usage patterns.\n\nThe MCP runtime should not expose:\n\n- Private tenant data outside scope.\n- Secrets.\n- Debug responses.\n- Internal-only tools.\n- Unfinished features.\n- Raw database structures.\n\nThe documentation helps AI systems understand AlefOS.\n\nThe MCP runtime lets authorized assistants work with AlefOS.\n\n## Examples\n\nExamples of useful MCP Cockpit questions:\n\n- What missions do I need to validate?\n- Who is waiting for a callback?\n- What did we decide in the team group?\n- Which client needs a follow-up?\n- What happened in the last call?\n- Prepare a message draft, but do not send it yet.\n- Which customers are blocked?\n- Which sales objections came back this week?\n- What should I know before my next appointment?\n- Which manager needs to review pending actions?\n\nThese are not generic AI questions.\n\nThey are business questions over the company memory.\n\n## Example workflow: customer follow-up\n\nA user asks:\n\n\"Who should I call back today?\"\n\nThe assistant can ask AlefOS through MCP.\n\nAlefOS can inspect visible contacts, missions, calls and calendar context.\n\nThe answer may include:\n\n- Customers waiting for a callback.\n- Why each callback exists.\n- What was promised.\n- Which follow-ups are late.\n- Which message can be prepared.\n\nIf a message or action is prepared, the user validates before it is sent or executed.\n\n## Example workflow: manager visibility\n\nA manager asks:\n\n\"Which cases are blocked this week?\"\n\nThe assistant can query AlefOS memory inside the manager authorized scope.\n\nAlefOS can combine visible missions, group decisions, call signals, contact context and pending approvals.\n\nThe result should help the manager understand:\n\n- Which customers are blocked.\n- Which actions are waiting.\n- Which users need attention.\n- Which decisions are pending.\n- Which follow-ups should be reviewed.\n\nThis is not a generic dashboard.\n\nIt is operational memory queried through natural language.\n\n## Example workflow: meeting preparation\n\nA user asks:\n\n\"What should I know before my next meeting?\"\n\nThe assistant can ask AlefOS for calendar context, contact history, open missions, previous calls, related group decisions and missing documents.\n\nAlefOS can return a preparation brief:\n\n- Who is involved.\n- Why the meeting exists.\n- What was discussed before.\n- What is still open.\n- What should be prepared.\n- What action may be needed after the meeting.\n\nThe calendar stops being only a date.\n\nIt becomes operational context.\n\n## Manager use cases\n\nFor managers, MCP Cockpit is especially important.\n\nA manager can ask AlefOS about visible operational state without requesting manual reports from everyone.\n\nExamples:\n\n- Which follow-ups are late?\n- Which users have open missions?\n- Which customers are waiting for a reply?\n- Which calls created important signals?\n- Which group decisions still need action?\n- Which deals look warm but blocked?\n\nThe goal is not surveillance.\n\nThe goal is operational visibility with permissions and context.\n\n## Plan and permission boundaries\n\nMCP access depends on the user plan, role, workspace configuration and permissions.\n\nDiscovery may expose only limited AlefOS access.\n\nSolo gives one user personal operational memory.\n\nTeam gives companies shared memory, manager visibility and permission-based scopes.\n\nThe assistant should never assume that every module, integration or action is available.\n\nIt should use what AlefOS exposes for the current user and context.\n\n## Security model\n\nMCP Cockpit should expose public product behavior and authorized user memory, not private internals.\n\nIt must not expose:\n\n- Secrets.\n- Environment variables.\n- Debug routes.\n- Admin-only tools.\n- Tenant data outside the user scope.\n- Private groups outside permissions.\n- Internal logs.\n- Unfinished integrations.\n\nThe MCP surface is powerful because it connects assistants to work.\n\nThat power requires strict boundaries.\n\n## Difference from a raw API\n\nA raw API exposes endpoints.\n\nMCP Cockpit exposes an assistant-ready operating surface.\n\nThe difference matters.\n\nAn assistant does not only need data. It needs context, permissions, action rules and safe workflows.\n\nMCP Cockpit gives assistants a way to ask operational questions and prepare work while respecting the AlefOS rule:\n\nmemory first, action second, validation always for protected actions.\n\n## What AlefOS is and is not\n\nAlefOS is a work operating system, an operational memory, an AI cockpit for real business context and a protected execution system.\n\nAlefOS is not a generic chatbot, a manual CRM, a social network, a phone operator, a WhatsApp replacement or a replacement for the user existing scheduling tools.\n\nMCP Cockpit is the bridge between AlefOS memory and the assistant the user already uses.\n\n## Team ownership tools\n\nProtected Team tools make responsibility explicit across contacts, missions and calendar work.\n\nAvailable ownership tools include:\n\n- contacts.assign\n- contacts.collaborators_list\n- contacts.collaborator_set\n- contacts.collaborator_remove\n- missions.assign\n- calendar.assign\n\nAn assistant can prepare an assignment, reassignment, return to the company queue or section-level collaboration change only within the authorized scope.\n\nPermission checks and audit trails still apply. A collaborator never silently takes over or impersonates the primary owner.\n\n## Key takeaway\n\nMCP Cockpit is how AI assistants talk to AlefOS.\n\nIt turns ChatGPT, Claude or Grok into a controlled interface for work memory.\n\nThe assistant can ask, search, summarize and prepare.\n\nAlefOS checks memory, permissions and action rules.\n\nThe user keeps control.\n\nThe simple idea:\n\nTalk to your assistant.\n\nAlefOS knows the work.\n\nNothing sensitive should happen silently.\n\n## Typical questions\n\n- What missions do I need to validate?\n- Who is waiting for a callback?\n- What did we decide in the team group?\n- Which client needs a follow-up?\n- What happened in the last call?\n- Prepare a message draft, but do not send it yet.\n\n## Important notes\n\n- AlefOS prepares. The user decides.\n- Protected actions must go through confirmation before execution."
}