Aptora für KI-Assistenten
Verbinde Aptora mit Claude, ChatGPT oder Cursor und lass deinen Assistenten Lebensläufe erstellen, Jobs durchsuchen und sich für dich bewerben. Alles auf dieser Seite funktioniert mit einem kostenlosen Konto.
Die Server-Adresse
Richte jeden MCP-fähigen Client auf diese URL. Es gibt keine API-Keys: Beim ersten Aufruf öffnet sich ein Browserfenster, in dem du dich anmeldest und auswählst, was du freigibst.
https://app.aptora.io/mcpTransport: Streamable HTTP (JSON-RPC). Autorisierung: OAuth 2.1 mit PKCE und dynamischer Client-Registrierung — die meisten Clients brauchen deshalb nichts außer der URL.
Client verbinden
Wähle den Assistenten, den du nutzt. Jeder dauert unter einer Minute.
Cursor™
- 1Trage die Konfiguration unten in ~/.cursor/mcp.json ein.
- 2Cursor öffnet einmal ein Browserfenster. Melde dich bei Aptora an und bestätige die Rechte, die du vergeben willst.
- 3Frag den Agenten im Chat — die Aptora-Tools erscheinen automatisch.
{
"mcpServers": {
"aptora": {
"url": "https://app.aptora.io/mcp"
}
}
}
Claude™
- 1Öffne in Claude Einstellungen → Connectors → Eigenen Connector hinzufügen und füge die Server-URL ein.
- 2Bestätige mit „Add“ und melde dich bei Aptora an, wenn Claude nach der Autorisierung fragt.
- 3Starte einen neuen Chat — Aptora taucht im Tool-Menü auf.
claude mcp add --transport http aptora https://app.aptora.io/mcp
ChatGPT™
- 1Öffne Aptora mit dem Button unten im App-Verzeichnis von ChatGPT und verbinde die App.
- 2Melde dich bei Aptora an, wenn ChatGPT nach der Autorisierung fragt, und bestätige die Rechte, die du vergeben willst.
- 3Starte einen Chat und bitte ChatGPT, Aptora zu nutzen.
Alternativ: im Entwicklermodus verbinden
- 1Entwicklermodus aktivieren: Einstellungen → Apps und Connectors → Erweitert → Entwicklermodus.
- 2Lege einen neuen Connector an, füge die Server-URL ein und bestätige.
- 3Melde dich bei Aptora an, wenn ChatGPT nach der Autorisierung fragt, und starte dann einen Chat mit aktiviertem Connector.
https://app.aptora.io/mcpInteraktive Komponenten (eine gerenderte Profilkarte statt rohem JSON) setzen voraus, dass der Connector im Entwicklermodus als App geladen ist. Ohne das funktionieren die Tools trotzdem und antworten mit reinen Daten.
Was du fragen kannst
Kopier einen und pass die Details an. Jeder nutzt mehrere Tools zusammen — dein Assistent verkettet sie von allein.
Lebenslauf importieren
Hier ist mein Lebenslauf als PDF-Export. Bau daraus ein Aptora-Profil, behalte jede Position und jedes Projekt, und prüf vor dem Speichern, ob es valide ist.
Jobs finden
Durchsuche das Aptora-Jobboard nach Remote-Freelance-Backend-Rollen, zeig mir die drei besten Treffer mit Tagessätzen und öffne die Details des interessantesten.
Auf einen Job bewerben
Bewirb mich auf diesen Job mit meinem Backend-Profil. Entwirf die Bewerbungsmail zum Gegenlesen — schick noch nichts ab.
Profil aktuell halten
Ergänze meine neue Position bei Nordkapp Systems ab September in meinem Hauptprofil. Lass alle anderen Abschnitte exakt so, wie sie sind.
Kandidaten finden (Team-Workspaces)
Veröffentliche diese Stellenbeschreibung auf unserem Board, such dann passende Kandidaten und setz die besten drei mit einer Begründung auf die Shortlist.
Was dein Assistent kann
Die Tools sind danach gruppiert, was sie anfassen. Dein Client sieht nur die, die du bei der Anmeldung freigegeben hast.
Profile
Lebensläufe lesen, anlegen, aktualisieren und löschen — dazu das vollständige Lebenslauf-Schema und ein Trockenlauf, der meldet, was ein Schreibvorgang speichern würde.
Jobboard
Öffentliche Jobs durchsuchen und filtern, komplette Stellenbeschreibungen lesen — inklusive Ansprechpartner, wo ein Job einen hat.
Bewerbungen
Eine Bewerbung mit einem gewählten Profil einreichen und eine fertige Mail zurückbekommen. Verschickt wird nie etwas für dich.
Recruiting
Für Team-Workspaces: eigene Jobs schreiben und veröffentlichen, Kandidaten suchen, eine Shortlist pflegen und Kontakt aufnehmen. Braucht einen Tarif, der das enthält.
Die Werkzeuge, einzeln
Jedes Werkzeug des Servers, mit Eingaben und der nötigen Freigabe. Die Liste wird aus dem Server selbst generiert — sie kann nichts behaupten, was der Server nicht mehr tut.
Generiert aus der Tool-Registry des MCP-Servers — Namen, Beschreibungen und Eingaben sind die, die ein verbundener Client sieht.
list_cvsnur lesendcv.read
List all of the signed-in user's CVs (id, name, theme).
Nimmt keine Argumente.
get_cvnur lesendcv.read
Fetch a single CV including its full resume data, plus `profile_skills`: the canonical skills detected on it, with the `skill_id` list_jobs filters by.
cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
get_cv_schemanur lesendkeine Freigabe nötig
Return the full AptoraCV resume JSON Schema that CV `data` must conform to. Prefer this over the `aptora://cv-schema` resource — it is a plain tool call and works on every client.
Nimmt keine Argumente.
get_capabilitiesnur lesendkeine Freigabe nötig
What this server can store: the supported AptoraCV sections, the section/field aliases it accepts, the allowed enum values and the supported import features (strict, merge, normalization). Call this before importing a resume from another format.
Nimmt keine Argumente.
create_cvschreibtcv.write
Create a CV from a COMPLETE AptoraCV document; preserve all populated fields and entries. Call `get_cv_schema` and dry-run `validate_cv` first. Aliases normalize automatically; strict=true rejects entry loss. Unknown fields are rejected with a correction hint. PERSONAL workspace identity: firstName/lastName/name always become the signed-in account's name, discarding the submitted candidate name. Other data is preserved; `normalized` reports rule `personal_workspace_identity`. Import into a TEAM workspace to preserve someone else's name.
data· object · erforderlich — Complete AptoraCV document: preserve ALL populated fields and array entries. Stored section counts are echoed for verification. Below is a one-level outline; call `get_cv_schema` for exact nested fields, types and enums, then `validate_cv` to dry-run before writing.strict· boolean — If true, reject the entire import when stored entry counts are lower than received. Default false: write and report differences. Unknown AptoraCV fields are always rejected.normalize· boolean — Normalize section/field aliases and enum wording before validation (work→employment, startDate→start, master→Expert). Default true; every change is listed in `normalized`.name· string · erforderlich — A name/label for the CV.theme· string — Optional theme id. Omitted, the CV starts on the workspace's default profile theme (settings, 'Profiles').
update_cvdestruktivcv.write
Update a CV's name, data and/or theme. Only provided fields change. By default `data` REPLACES the stored document, so any section you omit is lost — pass merge=true to patch the stored CV instead (sections you send replace their counterpart, sections you omit are kept). The response reports received vs. stored counts per section. In a PERSONAL workspace the candidate name is always the signed-in account's — see create_cv.
data· object — Complete AptoraCV document: preserve ALL populated fields and array entries. Stored section counts are echoed for verification. Below is a one-level outline; call `get_cv_schema` for exact nested fields, types and enums, then `validate_cv` to dry-run before writing.strict· boolean — If true, reject the entire import when stored entry counts are lower than received. Default false: write and report differences. Unknown AptoraCV fields are always rejected.normalize· boolean — Normalize section/field aliases and enum wording before validation (work→employment, startDate→start, master→Expert). Default true; every change is listed in `normalized`.cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.name· stringtheme· stringmerge· boolean — Merge `data` into the stored document instead of replacing it. Objects merge recursively; a list or scalar you send replaces the stored one. Default false.
validate_cvnur lesendcv.read
Dry-run: validate a AptoraCV resume document WITHOUT writing anything. Returns whether it is valid, any schema errors, the normalization it would apply, how many entries each section would store versus how many you sent, and any field that is not part of AptoraCV. Use this before create_cv/update_cv to confirm no data is lost. In a PERSONAL workspace the reported normalization includes the identity binding the write would apply, so this dry run and the write agree.
data· object · erforderlich — Complete AptoraCV document: preserve ALL populated fields and array entries. Stored section counts are echoed for verification. Below is a one-level outline; call `get_cv_schema` for exact nested fields, types and enums, then `validate_cv` to dry-run before writing.strict· boolean — If true, reject the entire import when stored entry counts are lower than received. Default false: write and report differences. Unknown AptoraCV fields are always rejected.normalize· boolean — Normalize section/field aliases and enum wording before validation (work→employment, startDate→start, master→Expert). Default true; every change is listed in `normalized`.
delete_cvdestruktivcv.write
Delete (soft-delete) a CV by id.
cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
search_job_rolesnur lesendjobs.read
Find roles and ESCO groups by German/English name or ISCO code. Use job_title_id or esco_uri with list_jobs; ESCO includes descendants.
query· string · erforderlichlimit· integer
list_jobsnur lesendjobs.read
Search jobs using an active job_title_id, esco_uri or at least 1 skill id. search_job_roles supplies selectable roles and ESCO concepts. ESCO includes descendants; role/ESCO and skill filters intersect. Skills match any selected id, ranked by overlap then recency; role-only uses recency. Skill IDs: get_cv profile_skills or listing required_skills. Summaries include skills; do not crawl rows with get_job, which is for a listing the user selected. Bare searches stop at page 10; ESCO keeps this cap even with extra filters. Pages and foreign listing details share account/workspace fair-use budgets across REST and MCP; refusals include retry_after seconds (§17).
skills· array<string> — At least 1 skill id without role/ESCO; otherwise optional. A listing matches when it requires any selected skill.job_title_id· string — Opaque, stable object reference. Use the slug returned by the API.esco_uri· string — ESCO concept from search_job_roles, including descendants.type· enum — Only freelance or only permanent positions.title· string — Substring filter on the job title.company· string — Substring filter on the company.location· string — Substring filter on the location.page· integer — 1-based page number (default 1).page_size· integer — Jobs per page (default 20, max 50).
get_jobnur lesendjobs.read
Fetch one job listing including the full job spec, its `required_skills` (with the `skill_id` list_jobs filters by) and the application contact (contact_email/contact_person) when the listing carries one. For one listing the user singled out: a list_jobs result already opens each of its rows in place, so fetching a page row by row stacks up one card per job and says nothing the list did not. Listings of other workspaces are subject to a fair-use read budget of distinct listings per hour and day; re-reading one is free, and a refusal carries `retry_after` in seconds. Fair use is what the terms of service set out in § 17.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
apply_to_jobdestruktivapplications.write
Apply to a job with one of the user's CVs. The listing's `origin` (from get_job) decides what happens: a `team` listing is DELIVERED into the owning workspace — `email` comes back null, there is nothing left for the user to send, and a contact_email passed for it is ignored. An `external` listing composes an application email (Gmail compose URL + markdown template) addressed to the listing's contact instead — nothing is sent; if it carries no contact_email, ask the user for the recipient and pass contact_email. IMPORTANT: applying PUBLISHES the chosen CV at a public share link anyone can open, and visits to it are tracked. Ask the user for explicit confirmation and pass confirm_publish=true only after they agreed.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.theme· enum — Theme for the shared CV link (default: the CV's theme).day_rate· integer — Offered day rate in EUR (freelance jobs only).contact_email· string — Recipient for an `external` listing — required if it carries no contact_email; ignored for a `team` listing.contact_person· string — Contact person for the salutation (optional).confirm_publish· boolean · erforderlich — Must be true; confirms the user agreed to publishing their CV at a public, visit-tracked link.
list_applicationsnur lesendapplications.write
List the workspace's job applications, newest first, each with its composed application email — null for one delivered into a team workspace, whose `status` says where it stands instead. Readable in every workspace; whether NEW ones may be made is apply_to_job's question (a personal workspace or a consultancy team, never a company/agency team).
Nimmt keine Argumente.
get_job_schemanur lesendkeine Freigabe nötig
The field schema for creating/updating a job listing. Static — call it before the first write instead of guessing field names.
Nimmt keine Argumente.
validate_jobnur lesendjobs.write
Dry-run a listing: what is missing or ignored; writes nothing. Use before create_job. Every plan; detect_skills needs one with skill detection.
title· string · erforderlich — The listing's headline, e.g. 'Platform Engineer'. Write the role — not an ad subject line with location, duration or reference number in it. The role behind the taxonomy is named by the detection run reading the whole spec, so a headline never has to carry it.company· string · erforderlich — Hiring company.type· enum · erforderlich — Engagement type.published_since· string · erforderlich — ISO date the listing went live.job_spec· string — The full job description. This is what the required skills are detected from — a listing without it will not match any candidates.location· stringremote_in_percent· integer — Share of remote work. 0-100.start_date· string — ISO date.end_date· string — ISO date — only when the ad names an actual date. Most ads state a duration instead; that belongs in duration_months, never computed into a date here.duration_months· integer — Stated engagement length in months, e.g. 12 for '12 MM'. 1-60.duration_open_ended· boolean — True when the duration carries a '+'/'++'/'mit Option auf Verlaengerung' — the ad says the length is open upward. It qualifies duration_months and needs one: a create without a duration drops it, an update without one is refused.dayrate· integer — EUR/day (freelance). 0-10000.salary· integer — EUR/year (permanent). 0-10000000.job_url· string — Absolute http(s) URL of the advertisement.contact_email· stringcontact_person· stringexpires_at· string — ISO datetime the listing stops being shown. Omit it and the listing does not expire; send null on an update to remove a deadline set earlier.stated_skills· array<object> — See create_job.detect_skills· boolean — Also report the skills job_spec would be matched on. Runs the detector. Off by default.
create_jobschreibtjobs.write
Create a listing of this team workspace. Starts PRIVATE (off the board, no matching) until publish_job. Free on every team plan; skill detection only if the plan includes it.
title· string · erforderlich — The listing's headline, e.g. 'Platform Engineer'. Write the role — not an ad subject line with location, duration or reference number in it. The role behind the taxonomy is named by the detection run reading the whole spec, so a headline never has to carry it.company· string · erforderlich — Hiring company.type· enum · erforderlich — Engagement type.published_since· string · erforderlich — ISO date the listing went live.job_spec· string — The full job description. This is what the required skills are detected from — a listing without it will not match any candidates.location· stringremote_in_percent· integer — Share of remote work. 0-100.start_date· string — ISO date.end_date· string — ISO date — only when the ad names an actual date. Most ads state a duration instead; that belongs in duration_months, never computed into a date here.duration_months· integer — Stated engagement length in months, e.g. 12 for '12 MM'. 1-60.duration_open_ended· boolean — True when the duration carries a '+'/'++'/'mit Option auf Verlaengerung' — the ad says the length is open upward. It qualifies duration_months and needs one: a create without a duration drops it, an update without one is refused.dayrate· integer — EUR/day (freelance). 0-10000.salary· integer — EUR/year (permanent). 0-10000000.job_url· string — Absolute http(s) URL of the advertisement.contact_email· stringcontact_person· stringexpires_at· string — ISO datetime the listing stops being shown. Omit it and the listing does not expire; send null on an update to remove a deadline set earlier.stated_skills· array<object> — [{name, requirement?, evidence?}] as the ad says; no detection runs. Pick unclear_skills by {skill_id}; unknown_skills are not created.
update_jobdestruktivjobs.write
Update a listing of this workspace; only named fields change, null clears one. Saving never re-detects skills: pass detect_skills=true after a spec change. stated_skills only adds.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.title· string — The listing's headline, e.g. 'Platform Engineer'. Write the role — not an ad subject line with location, duration or reference number in it. The role behind the taxonomy is named by the detection run reading the whole spec, so a headline never has to carry it.company· string — Hiring company.type· enum — Engagement type.published_since· string — ISO date the listing went live.job_spec· string | null — The full job description. This is what the required skills are detected from — a listing without it will not match any candidates.location· string | nullremote_in_percent· integer | null — Share of remote work. 0-100.start_date· string | null — ISO date.end_date· string | null — ISO date — only when the ad names an actual date. Most ads state a duration instead; that belongs in duration_months, never computed into a date here.duration_months· integer | null — Stated engagement length in months, e.g. 12 for '12 MM'. 1-60.duration_open_ended· boolean — True when the duration carries a '+'/'++'/'mit Option auf Verlaengerung' — the ad says the length is open upward. It qualifies duration_months and needs one: a create without a duration drops it, an update without one is refused.dayrate· integer | null — EUR/day (freelance). 0-10000.salary· integer | null — EUR/year (permanent). 0-10000000.job_url· string | null — Absolute http(s) URL of the advertisement.contact_email· string | nullcontact_person· string | nullexpires_at· string | null — ISO datetime the listing stops being shown. Omit it and the listing does not expire; send null on an update to remove a deadline set earlier.stated_skills· array<object> — See create_job.detect_skills· boolean — Also re-detect the skills of the saved spec; spends one detection run. Off by default.
delete_jobdestruktivjobs.write
Delete one of this workspace's job listings. Refused while candidates are still waiting on it — the refusal says how many; repeat the call with reject_open_applications=true to delete anyway.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.reject_open_applications· boolean — Reject every application still waiting on this listing and delete it. Each of those candidates is notified that their application was rejected. Off by default: without it a listing with open applications is not deleted.
publish_jobschreibtjobs.publish
Put one of this workspace's listings on the public board and into candidate matching. Reversible with unpublish_job — the listing keeps its id, its skills and its match history either way.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
unpublish_jobdestruktivjobs.publish
Take one of this workspace's listings back off the public board and out of candidate matching. The listing itself stays.
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
classify_job_skilldestruktivjobs.write
Set how strongly a listing asks for a linked skill: required, optional or unspecified (not stated, or undo). skill_id from get_job's required_skills. Kept as a decision; later detection never replaces it. Weights matching; existing searches keep their scores (see basis_status).
job_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.skill_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.requirement· enum · erforderlichexpected_requirement_revision· string — The requirement_revision you last read for this skill. With it, a classification somebody else changed in between is refused (conflict) instead of overwritten. Optional.
list_team_jobsnur lesendjobs.write
The listings this workspace owns, including expired ones. Different from list_jobs, which is the public board.
page· integerpage_size· integer — Default 20, max 50.
search_candidatesschreibttalent.read
Find candidates for a job (job_id) or for free criteria (filters) across every profile whose owner opted into being found. Ranks them by skill overlap plus a small role bonus and returns the evidence behind each score. Every search needs an anchor: a job_id (one of this workspace's listings, whose detected skills are the requirements) or at least 3 ids of active skills in the filters — those are what a candidate is ranked against. Every filter EXCLUDES on top of that: skills, titles, country, remote share and day rate each narrow the set, and no score buys a candidate back in. Within one list any entry counts, across lists all of them must. Skill ids come from a listing's required skills or a search result; an id that names no active skill is refused. This is DETERMINISTIC — it runs no model and forms no opinion beyond the counted overlap; call refine_search afterwards if you want that. Results never contain contact data — use send_outreach to reach someone. If the run comes back pending, poll get_search with the returned run_id. Runs and delivered profiles are subject to a fair-use read budget — fair use is what the terms of service set out in § 17 — and a refusal carries `retry_after` in seconds.
job_id· string — Opaque, stable object reference. Use the slug returned by the API.filters· objectforce· boolean — Re-run instead of reusing.
refine_searchschreibttalent.read
Have a model estimate how well the candidates a finished search found fit, from their careers: seniority against the role, how central the matching skills are to what someone actually does, whether the role plausibly interests them, and whether the missing skills are the kind one picks up. Re-ranks the SAME candidates — it never adds or removes anyone, and it never re-scores the counted overlap. Optional 'focus' is what matters beyond the listing ("must have worked in a regulated environment"). Costs one AI step from the workspace allowance; asking the same thing of the same run again is free. Poll get_search and read refine_status.
run_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.focus· string — Optional. What to weigh beyond the listing itself.force· boolean — Estimate again instead of reusing.
get_searchnur lesendtalent.read
Status and a page of results for a run started by search_candidates. 'status' is the search itself; 'refine_status' is the optional AI fit estimate and is null until refine_search is called. Results are complete and ranked either way — a failed estimate leaves them untouched. Paging costs no allowance.
run_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.page· integerpage_size· integer — Default 25, max 100.
list_searchesnur lesendtalent.read
This workspace's candidate searches, newest first, one page at a time.
page· integerpage_size· integer — Default 20, max 50.
shortlist_candidateschreibttalent.write
Save a candidate to the workspace shortlist, optionally against a job. The shortlist belongs to the whole team.
cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.job_id· string — Opaque, stable object reference. Use the slug returned by the API.note· string
list_shortlistnur lesendtalent.read
The workspace shortlist, optionally filtered by job, one page at a time.
job_id· string — Opaque, stable object reference. Use the slug returned by the API.page· integerpage_size· integer — Default 20, max 50.
remove_from_shortlistdestruktivtalent.write
Drop one entry from the workspace shortlist.
shortlist_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.
send_outreachdestruktivtalent.outreach
SENDS A REAL MESSAGE TO A REAL PERSON, with optional email. One call, one recipient — no bulk parameter and there will not be one. The message is delivered by Aptora from our address; you never receive the candidate's address, and they can reply in Aptora if they want to or switch outreach off entirely. Each accepted message is metered against the workspace’s current plan allowance. Reuse an idempotency_key for retries of the same draft. Ask the user before calling this.
idempotency_key· string — Stable UUID for this reviewed draft; reuse on retries.cv_id· string · erforderlich — Opaque, stable object reference. Use the slug returned by the API.job_id· string — Opaque, stable object reference. Use the slug returned by the API.request_hourly_rate· boolean — Ask for an hourly rate (EUR net plus VAT); default false.request_availability· boolean — Ask for start date and hours per week; default false.subject· string · erforderlichbody· string · erforderlich — Plain text; no HTML.
Was du freigibst
Die Anmeldeseite zeigt genau, welche davon ein Client angefragt hat, und du kannst jede ablehnen. Tools, die du nicht freigegeben hast, werden dem Assistenten gar nicht erst angeboten.
Unter Einstellungen → Integrationen kannst du jede Verbindung jederzeit einsehen und widerrufen.
Gut zu wissen
- Eine Bewerbung veröffentlicht das gewählte Profil unter einem öffentlichen Link, dessen Aufrufe gezählt werden. Dein Assistent muss dich vorher fragen.
- In einem persönlichen Workspace geht es in einem Profil immer um dich: Der Name eines importierten Kandidaten wird durch deinen Kontonamen ersetzt. Importiere fremde Lebensläufe in einen Team-Workspace, wenn der Name erhalten bleiben soll.
- Kandidaten-Treffer enthalten nie Kontaktdaten. Der Kontakt läuft über Aptora, immer nur zu einer Person, und jeder Kandidat kann ihn abschalten.
- Aptora entwirft Bewerbungsmails. Verschickt wird nie eine in deinem Namen.
Wenn etwas nicht klappt
Der Assistent sagt, er habe keine Aptora-Tools
Die Verbindung ist noch nicht autorisiert, oder du hast weniger Rechte vergeben, als die Aufgabe braucht. Neu verbinden und auf der Anmeldeseite die passenden Haken setzen.
Ich soll mich ständig neu anmelden
Der Zugriff läuft nach einer Stunde ab und erneuert sich still. Wenn nicht, entferne den Connector im Client und füge ihn neu hinzu — die alte Freigabe wurde vermutlich widerrufen.
Ich sehe nur JSON, keine Profilkarte
Interaktive Komponenten rendert der Client, nicht wir. In ChatGPT zeigt sie die Aptora-App aus dem App-Verzeichnis; ein von Hand angelegter Connector muss dafür im Entwicklermodus als App geladen sein. Die Daten selbst stimmen so oder so.
Ein Tool wird angeboten, scheitert aber beim Aufruf
Der Client hält eine zwischengespeicherte Tool-Liste einer älteren Server-Version. Connector neu verbinden, dann wird sie aufgefrischt.