Skip to main content
Glama

Rekvira: EU regulation pinpoints for compliance AI

Connect, or sign in (step 1 of 2)

connect

Connect. With no arguments: the keyless trial — no email, no key; returns trial_id for record_assessment / list_assessments and the private playbook tools. Call start_here next. With the user's email and the language you speak with them (e.g. 'en', 'de', 'lt'): sign in to a free account that keeps their assessments and playbooks across chats. Rekvira sends ONE email in that language with a Confirm link and a six-digit code, valid 15 minutes, and returns request_id. Tell the user to click Confirm; then IMMEDIATELY call connect_verify(request_id) — it waits for the click. Nothing is charged and no card is needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoOnly to sign in: the user's email. Omit for the keyless trial
languageNoThe language you speak with the user (en, de, lt, fr, es, pl); the email uses it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / email
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Only to sign in: the user's email. Omit for the keyless trial",
      +  "title": "Email"
      +}
    • addedInput schema / properties / language
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The language you speak with the user (en, de, lt, fr, es, pl); the email uses it",
      +  "title": "Language"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although annotations indicate this is not read-only, the description carries the behavioral detail: it sends exactly one email in the chosen language, the confirm link/code is valid for 15 minutes, connect_verify blocks until the click, and nothing is charged. This exceeds what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that contains no filler, but it could be better structured into two modes or bullets. Every sentence earns its place and the most important distinction appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still names the return values (trial_id, request_id), the email validity window, and the next tools to call. An agent has enough information to invoke connect correctly in both modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds mode-dependent meaning: omitting both parameters means trial, while supplying email and language triggers sign-in. It could more explicitly state what happens with a partial combination, but the core semantics are clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives two distinct, concrete modes: no arguments launches a keyless trial and returns trial_id, while email plus language signs in and returns request_id. It explicitly frames the tool as step 1 of 2 and names connect_verify as the next step, so it is not confused with its siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states exact conditions for use: no arguments for the trial, email and language for sign-in, and instructs to call start_here after the trial and connect_verify immediately after the email. This is explicit contextual routing with no ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources