Documentation

VerifEye MCP Server Release Notes

Version History

Version 1.1.1

Release Date: 2026-10-16

Changes

  • The MCP Registry entry links a public repository: the ai.realeyes/verifeye entry in the MCP Registry now links Realeyes/VerifEye-Mcp-Server, whose README says how to connect a client. The server URL is unchanged, so no client needs reconfiguring. See Server URL.

Version 1.1

Release Date: 2026-09-28

Features

  • Identify a returning person: verifeye_identify_face now takes an optional collectionId, and every face then also comes back with faceId, faceStatus (Existing or NotExisting) and any externalKey you attached. Nothing is onboarded either way: a face the collection does not hold comes back as NotExisting with no faceId, which is what makes this the tool for asking whether a face is already known. See verifeye_identify_face.
  • Onboard a face: verifeye_onboard_face stores the face(s) in an image into a collection you name, optionally labelled with an identifier of your own. It is the only tool that stores biometric data, and what it stores outlives the conversation, so keep your own record of the faceId it returns and of who consented to what. See Consent and retention are your responsibility.
  • Compare against one known face: verifeye_compare_face checks the face(s) in an image against a single onboarded face and returns a similarity score, VerifEye's own match verdict, and a boundingBox for each face — the one tool that says where on the image a face is. A match is evidence of similarity, not an identity check on its own. See verifeye_compare_face.
  • Delete a face: verifeye_delete_face destroys one onboarded face, which is how an erasure request is honoured. See verifeye_delete_face.
  • Manage collections: verifeye_list_collections, verifeye_create_collection, verifeye_set_collection_description, verifeye_reset_collection and verifeye_delete_collection. Deleting a collection first checks whether one of your verification configurations routes face data into it, and refuses if one does — a refusal no tool can override, because the verification has to be pointed elsewhere in the Developer Console first. See Available tools.
  • Use your own identifiers: verifeye_set_face_key, verifeye_get_face_by_key and verifeye_delete_face_key attach your own customer number or member id to an onboarded face and find the face by it, so nothing on your side has to store VerifEye's faceId. A key belongs to exactly one face. See verifeye_get_face_by_key.
  • Upload feeds every image tool: the short-lived form from verifeye_get_upload_url now works with verifeye_onboard_face and verifeye_compare_face as well as the analysis. The image is still deleted the moment the tool call that uses it returns, so an uploadId is good for one call. See verifeye_get_upload_url.
  • Failures carry a code you can branch on: every tool error is one line of JSON with a stable code, a human-readable message, whether retrying could help, and a suggested next step. All fourteen codes are documented, including the ones that mean nothing was changed — collection_exists, external_key_in_use and collection_in_use. See Errors.
  • Agent discovery covers recognition: the agent card advertises the recognition capabilities beside the analysis ones, with four new published skill documents — identify-face, onboard-face, compare-faces and manage-face-collections — under /.well-known/. The agent card and the MCP server card are at version 1.1.0, which is also the version the server reports when a client connects.

Changes

  • A failed call now answers with the error JSON alone: in 1.0 a failure from verifeye_identify_face or verifeye_get_upload_url came back as a sentence of English with the details wrapped inside it, and some failures carried no details at all. Both now answer the way every tool does — isError with one line of JSON carrying code, message, retryable and nextStep. Anything on your side that matched the wording of the old sentence should read the code instead. See Errors.
  • faces[].faceIndex has been removed from the analysis result: it was only the order the faces came back in, which readers took for a position on the image. Refer to a face by faceId where the call named a collection, and use verifeye_compare_face, which returns boundingBox, where a position on the image is what you actually need.

Version 1.0

Release Date: 2026-09-10

Features

  • Initial Release: the VerifEye MCP server, exposing VerifEye analysis to MCP-capable assistants over OAuth 2.1, with no API key in the client. See MCP Server.
  • verifeye_identify_face: one tool for every facial attribute VerifEye reports — apparent age, apparent gender, momentary emotions and momentary attention — in a single call. Age and gender are included; emotions and attention are an add-on that surcharges the faces the call is already charged for, at the rate in your plan, rather than adding a second charge. Requesting either applies it; requesting both does not apply it twice.
  • Emotions and attention: six emotion signals and three attention signals. Each signal is a momentary, single-frame observation, never a score: it comes back as observed, as determined not present, or as undetermined. Where the analysis has nothing to report for a face, the object is left out entirely rather than returned with every signal undetermined. See Absent versus undetermined.
  • The image is a public URL: pass imageUrl and VerifEye fetches the image itself, so nothing in the conversation has to carry image bytes. maxFaces accepts 1 to 4; the higher counts are available on the VerifEye Face API directly.
  • Or upload the image: verifeye_get_upload_url hands back a short-lived, single-use upload form for a client that has an image but nowhere public to put it, and the analysis then takes the returned uploadId instead of imageUrl. The image is stored in the region you ask for and deleted as soon as the first analysis returns. It needs a client that can make an outbound HTTPS request of its own — an assistant whose tools run in a sandbox with no egress cannot upload, and a public URL works everywhere.
  • Data residency per call: one global endpoint, and region (eu/us) chooses where each image is processed. Your account must be authorized in the region you ask for.
  • Connecting a client: a client either uses a pre-registered client ID or publishes a client ID metadata document and sends its URL — the tab for your client says which, and gives the exact value where there is one. Claude, Claude Code, Cursor and the Gemini CLI are covered, and so are ChatGPT, VS Code and Codex, which identify themselves by metadata document and need no client ID entered. See Connecting a client.
  • Consent screen: it shows what VerifEye knows about the application asking for access. One VerifEye recognises is named, with the logo it publishes; one that identified itself with a metadata document from an address VerifEye does not recognise is shown by that address alone, with no name or logo. Either way the screen says where the authorization will be delivered. Approve only a sign-in you have just started yourself.
  • Agent discovery: an agent card, an MCP server card and four published skill documents — estimate-age, detect-gender, detect-emotions and detect-attention — under /.well-known/, so an agent can discover what the server does without reading this page. Each skill's description names the image source, the face limit and the data-residency choice. The agent card and the MCP server card are at version 1.0.0.

For the latest updates, visit the VerifEye Developer Console