Forbind en AI-klient (MCP)

Oprettelse af applikationer og kapabiliteter via MCP har ingen planbaseret antalsgrænse i Atlas under Early Access. Den tilsluttede identitets adgang og arbejdsområdets skrivepolitik afgør stadig, om ændringen oprettes direkte eller sendes til godkendelse.

Model Context Protocol (MCP) giver en AI-klient en struktureret adgang til at kalde værktøjer fra Atlas. Målet er, at du kan arbejde med arkitekturen fra en understøttet AI-klient, mens Atlas håndterer registreringerne og adgangen.

Kontrollér først tilgængeligheden

Atlas har et MCP-endpoint på https://atlas.spekir.com/mcp. Adgang afhænger af loginopsætningen, værktøjerne i dit workspace og din rolle. At endpointet findes, betyder ikke, at alle AI-klienter allerede kan gennemføre login eller bruge alle Atlas-funktioner.

Spørg din Atlas-administrator, hvilken forbindelsesmetode der er aktiveret. En ældre forbindelse med API-token og den nyere OAuth-forbindelse har forskellige opsætningstrin; de kan ikke uden videre erstatte hinanden.

Begynd med at læse

For at undersøge modellen før selve registreringerne kan klienten kalde get_metamodel med scope: "reference". Svaret indeholder samme katalog over faktaarkstyper som Settings, med referencestandarder og den aktuelle tilgængelighed i Atlas. Standardsvaret all og atlas://metamodel indeholder kataloget som reference_profile; planlagte referencetyper holdes adskilt fra de eksisterende entity_types og kan ikke bruges som typer i skrivekald.

Når administratoren har bekræftet en fungerende forbindelse:

1. Bekræft, hvilket workspace klienten bruger.
2. Bed den vise de applikationer, den kan læse.
3. Stil et afgrænset spørgsmål, eksempelvis: ”Hvilke registrerede afhængigheder involverer vores CRM?”
4. Sammenhold svaret med registreringerne i Atlas, og kontrollér kilderne.

Svaret dækker de registreringer og værktøjer, klienten kan tilgå, og ikke nødvendigvis hele landskabet.

En slettet applikation arkiveres i stedet for at blive fjernet. MCP-læsninger som list_applications, get_application, get_app_context og get_application_dependencies returnerer den ikke længere, og en ny applikation kan bruge samme navn. Den kan gendannes i 90 dage, derefter slettes den endeligt. Se Applikationer.

Spørger du til forretningskapabiliteter, kan klienten bruge list_capabilities. Hver kapabilitet kommer med tier, eksternt id og APQC-referencer: den primære reference først, derefter op til tre sekundære, hver med styrke (strong, partial eller thin), en begrundelse og om den stadig skal gennemses. En reference, der skal gennemses, er foreslået af AI og endnu ikke tjekket af en person.

Bed din klient kalde show_cio_brief for at åbne CIO-briefet. En klient, der understøtter MCP Apps, viser det som en visning; andre klienter får det samme brief som tekst. Det er en læsning: den tager ingen parametre, bruger forbindelsens workspace og adgang og følger samme maskering og begrænsninger som get_dataset. Visningen kalder ikke andre værktøjer og ændrer intet i Atlas.

Et spørgsmål som ”Hvilke integrationer og interfaces har vores webshop?” bruger get_application_dependencies. Ud over de registrerede afhængigheder returnerer det applikationens integrationer, hver med det interface, den forlader eller ankommer til, og dens godkendelse, frekvens, leveringsmønster og initiativtager, og applikationens input- og output-interfaces med de integrationer og dataobjekter, der bruger dem.

Tegn et landskab

Et spørgsmål som ”Vis vores ERP-landskab og integrationspunkter” kan besvares med værktøjet export_archimate. Klienten angiver, hvilken applikation der skal være i centrum, og Atlas returnerer de applikationer, den er integreret med, deres interfaces, kapabiliteter, processer, organisationer og teknologi som en ArchiMate Model Exchange File med to færdige views, Integrations og Layered landscape. På forespørgsel returnerer Atlas også en tegning af hvert view, som klienten kan vise, og filen, som Archi og andre ArchiMate-værktøjer kan importere.

Atlas bruger ingen AI til dette svar. Klienten vælger omfanget ud fra dine ord; hvert element i tegningen og filen er en registrering i Atlas med sit Atlas-ID. Svaret siger også, hvad det ikke indeholder, for eksempel beslutninger og initiativer, så et manglende element ikke læses som en manglende registrering.

Vær konkret om skrivninger

Før en klient skal ændre registreringer, bør du bede om de foreslåede ændringer, kilden til hver væsentlig oplysning og de berørte applikationer eller relationer. Bekræft det tilsigtede workspace og omfang.

Hvad en klient må skrive, afhænger af jeres workspaces tilstand for change management og din rolle. Bed klienten kalde get_identity først: den returnerer tilstanden og under change_governance, hvordan dine skrivninger lander. I Simpel skriver en person med skriverolle direkte og kan fortryde. I Review skriver kun ejeren af et element eller en admin direkte; andre ændringer bliver forslag eller change requests, som en anden godkender. Agenter foreslår altid, og du kan ikke fra en klient godkende et forslag, du selv har oprettet fra samme klient. Samme regel gælder for alle slags punkter, også links til dataobjekter (data_object link- og unlink-punkter, der siger, hvad en applikation opretter, læser, opdaterer eller sletter): i Review tæller sådan et link som dit, når du ejer applikationen. En integrations dataobjekter og middleware skrives på samme måde: et data_object-punkt med interface_id i stedet for application_id, og et technology-linkpunkt, hvis mål er IT-komponenten, og hvis payload angiver interface_id; sådan et link tæller som dit, når du ejer integrationen. Et data_object-link kan i stedet bære capability_id for at registrere, hvilken forretningskapabilitet der bruger dataobjektet; det tæller så som dit, når du ejer kapabiliteten. Se Change requests og review. Brug en forbindelse med læseadgang, når det er den nødvendige afgrænsning.

Arbejd med change requests fra din klient

Et forslag fra en connector eller import i en åben change request afgøres gennem den change request: review_populate_proposal afviser det og nævner hvilken.

En klient kan oprette og flytte change requests på samme måde som under Governance › Change requests. Bed den oprette en change request med en titel, der siger hensigten, og punkter, der ændrer en applikations navn, beskrivelse, leverandør eller livscyklus; intet ændres, før change requesten er anvendt eller godkendt. Bed den læse en change request først: svaret viser de handlinger, du må udføre, fx indsend, godkend, afvis med en note eller bed om ændringer med en note. En godkendelse gemmer en beslutning. En change request, du har oprettet fra en klient, kan du ikke selv godkende eller anvende fra en klient; godkend den i Atlas eller bed en reviewer om det.

Kontrollér et udkast, før det sendes

Bed din klient kalde validate_changes med de samme ændringer, som den ville sende til propose_changes. Atlas kontrollerer udkastet og svarer med, om det er gyldigt, det berørte felt og årsagen til hver fejl, eventuelle advarsler og antallet af ændringer. Det opretter intet forslag og ændrer ingen poster. Hvis Atlas har fundet målet for en rettelse eller sletning ud fra navnet, indeholder advarslen postens ID, så du kan kontrollere matchet.

Ret fejlene og gennemgå advarslerne, før ændringerne sendes. Valideringen følger de nuværende forslagskontroller; nogle kontroller sker stadig, når en reviewer accepterer forslaget. Et gyldigt resultat reserverer ikke et navn, garanterer ikke godkendelse og giver ikke skriveret. Dit workspace, din rolle og tilstanden for change management afgør fortsat, hvad der sker, når du sender ændringerne.

Aktive requests i Atlas og MCP

Vælgeren Active change request i Atlas-headeren gælder redigering på fact sheets i webappen. Den vælger ikke en request for en MCP-klient. En agent eller connector sender fortsat forslag via sine MCP-værktøjer; gennemgå de returnerede forslag eller request-punkter i Atlas, før de anvendes. En person, der bruger en MCP-klient, bør kontrollere get_identity for de aktuelle skriverettigheder i stedet for at antage, at valget i web-headeren ændrer klientens session.

Hvis forbindelsen fejler

Kontrollér forbindelsesmetode, adgang og valgt workspace med administratoren. Læg ikke API-tokens i en prompt, en e-mail eller et delt dokument.

Bredere adgang fra Claude, ChatGPT, Copilot og andre klienter kræver fortsat verifikation for hver klient. Navnene beskriver retningen og lover ikke, at alle kombinationer er generelt tilgængelige i dag.

Læs workspacets typede model

Bed din klient kalde pull_workspace for at læse de modeltyper og registrerede relationer, den har adgang til. I læsning af initiativer bruger initiative_type undertyperne Idea, Program, Project eller Epic: gemt Must-Win Battle bliver Program, og gemt Strategic Project eller Initiative bliver Project. Den kan bede om bestemte typer, fx applikationer og capabilities, og udelade relationer, når de ikke er nødvendige. Adgangen følger stadig forbindelsens workspace og læserettigheder. Arkiverede poster udelades, hvor modellen understøtter arkivering, og de eksisterende regler for økonomisk synlighed gælder.

Kontrollér known_gaps, excluded_types og coverage, før du behandler svaret som komplet. En manglende ejer eller et modelfelt, der ikke understøttes, bliver angivet; Atlas finder ikke på det. En tom type på én side betyder ikke, at workspacet mangler poster af den type. Hvis next_cursor er udfyldt, skal klienten fortsætte med after og de samme valg og samle siderne, indtil værdien er null. Ændrede poster eller adgangsrettigheder kan gøre en cursor ugyldig; start da læsningen forfra.

For at læse relationerne for én registrering beder du klienten kalde get_entity_relations. Værktøjet tager også initiativer, interfaces, organisationer og teknologikategorier. En relateret registrering har samme id, uanset hvilken ende du starter fra, og relationer med gyldighedsfelter har active_from, active_until og temporal_state (current, planned, planned_overdue eller ended). En relation uden datoer er aktuel; en afsluttet relation kan stadig læses som historik, men tæller ikke med i aktuelle omkostnings- og understøttelsesopgørelser. pull_workspace angiver de samme datoer og den samme tilstand. En capability og et dataobjekt viser begge, at capabilityen bruger dataobjektet, fra hver sin ende, under fact_sheet_relations med de samme datoer og den samme tilstand. Det er kun læsning: værktøjet kan endnu ikke ændre disse relationer.

Svaret følger det publicerede Atlas workspace-schema. De eksisterende læseværktøjer er fortsat tilgængelige. Workspace-revisionen beskriver et øjebliksbillede; den reserverer ikke noget og garanterer ikke, at intet kan ændre sig før en senere skrivning.

Ved et senere propose_changes-kald kan klienten sende workspace-revisionen som base_revision på kaldets øverste niveau. Atlas kontrollerer dette vejledende øjebliksbillede før nye skrivninger. Er det ændret, får klienten en konflikt og den aktuelle workspace-revision og bør læse igen. Den kan stadig genforsøge et afsluttet kald med samme idempotensnøgle. Workspace-kontrollen erstatter ikke de eksisterende revisionskontroller på det enkelte forslag ved godkendelse og er ikke en atomisk lås; en ændring, der ikke flytter de registrerede antal eller seneste opdatering, kan forblive uopdaget.

Ét element, én ændring, én søgning

Tre læseværktøjer besvarer de spørgsmål en arkitekt oftest stiller, hver med ét kald:

• get_fact_sheet returnerer ét element som tekst med dets relationer, og hvor hvert felt kommer fra (en person, en AI med reviewstatus eller en connector). Dækker en af de tre dele ikke elementets type endnu, siger den del unsupported_entity_type i stedet for at se tom ud. For en applikation returnerer det også relation_explanations: hver relation med retning, hvor den kommer fra (en person, en import, en connector, en AI eller ukendt), korte uddrag af evidens, og hvad der ikke vides. En sikkerhed vises kun, hvor en model har gemt en, og manglende evidens eller oprindelse bliver navngivet i stedet for at stå tom. Se Kilder og evidens for, hvad hver kode betyder.
• get_impact svarer på "hvad sker der, hvis vi ændrer denne applikation": de berørte applikationer og hvorfor, capabilities, de ejere der skal involveres, og hvad der er ukendt, fx en manglende ejer. Værktøjet bruger samme funktion som siden for konsekvensanalyse, så klienten og webappen viser de samme fakta. Det dækker applikationer i dag.
• search finder registreringer og beslutninger ud fra søgeord. Beslutninger findes på det, de siger, ikke kun deres titel. Brug listen over typer til at afgrænse.

get_dataset tilbyder også ai_governance_v1 (tallene for AI-governance, én række pr. måltal) og ai_registry_v1 (de registrerede AI-agentsystemer, én række hver). architecture_policies_v1 viser principper, standarder og mønstre med udsagn og begrundelse. policy_exceptions_v1 viser hver undtagelse med politik, berørt element, godkendelsesstatus og tilknyttet beslutning. Kun approved betyder godkendt; inaktive politikker er synlige med is_active: false. Begge datasæt bruger forbindelsens workspace. Alt dette er kun læsning.

Kontrollér modellen, før du ændrer den

Bed din klient kalde audit_workspace for at kontrollere workspacet mod Atlas' 27 kontrolregler: manglende ejere og klassifikationer, livscyklusdatoer i forkert rækkefølge eller efter end of life, ødelagte interfaces, persondata uden klassifikation, huller i capability-hierarkiet, løse ender i strategi og beslutninger og AI-systemer uden ejer. Hvert fund navngiver elementet, reglen og hvad der skal gøres. Reglerne står i det publicerede katalog.

Klienten kan sende de samme ændringer, som den ville sende til propose_changes. Atlas kontrollerer så modellen, som den ville se ud med ændringerne, uden at skrive noget, så du ser, hvad et ændringsforslag ville ødelægge, før det sendes. Se efter i known_gaps: en regel, modellen endnu ikke kan vurdere, står der i stedet for at bestå i stilhed.

Prøv en første analyse, eller følg arbejdsgangen fra kilde til forslag.

Brug Lav udkast til et landskab fra kilder til at forberede første sæt forslag og Validér ændringer, og gennemgå kvalitet til at kontrollere det.

Læs applikationers fit-scores

Det eksisterende datasæt applications_v1 returnerer business_fit_score og technical_fit_score som tal fra 0 til 10 eller null, når der ikke er registreret en score. En manglende score er ikke nul. Sammenhold værdierne med den gemte TIME-beslutning, når du kontrollerer en rapports placering ud fra scores.