turva-mcp

Contact and operator details

get_contact

Read-onlyIdempotent

Returns who runs turva.dev and the official ways to reach it: the operator and business details, the email address, the Signal link, the LinkedIn profile, the correspondence languages, the first-reply time and the access an audit needs. Use this when a user asks who is behind turva.dev, how to contact it, how to start an audit or what access has to be granted. For what is sold and what it costs use get_services instead. Read-only: returns static JSON that is compiled into the Worker, so it changes nothing and updates only on deploy.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`email`	Yes	The email address for starting an engagement.
`signal`	Yes	A link that opens a Signal chat with the operator.
`linkedin`	Yes	The URL of the operator's LinkedIn profile.
`location`	Yes	The city and country where the business is based.
`operator`	Yes	Who runs turva.dev and the registered business behind it.
`engagement`	Yes	How an engagement is communicated, async_only for written exchange with no calls.
`business_id`	Yes	The Finnish business ID of the business.
`first_reply`	Yes	How soon the first reply comes and by which channels, and that LinkedIn has no set reply time.
`channel_note`	Yes	Which channel suits which kind of message, and that there are no calls.
`how_to_start`	Yes	The steps to start an engagement and the access an audit needs, one per entry.
`correspondence_languages`	Yes	ISO 639-1 codes of the languages the correspondence is held in.

Schema Changelog

Changes observed during successful MCP inspections.

Changed21 schema fields changedOct 15, 2026

addedOutput schema / properties / business_id / description

Added value: +"The Finnish business ID of the business."

addedOutput schema / properties / channel_note / description

Added value: +"Which channel suits which kind of message, and that there are no calls."

addedOutput schema / properties / correspondence_languages / description

Added value: +"ISO 639-1 codes of the languages the correspondence is held in."

addedOutput schema / properties / correspondence_languages / items / description
```
Added value: +"An ISO 639-1 language code."
```

addedOutput schema / properties / email / description

Added value: +"The email address for starting an engagement."

addedOutput schema / properties / engagement / description

Added value: +"How an engagement is communicated, async_only for written exchange with no calls."

addedOutput schema / properties / first_reply / description

Added value: +"How soon the first reply comes and by which channels, and that LinkedIn has no set reply time."

addedOutput schema / properties / how_to_start / description

Added value: +"The steps to start an engagement and the access an audit needs, one per entry."

addedOutput schema / properties / how_to_start / items / description
```
Added value: +"One step as a sentence."
```

addedOutput schema / properties / linkedin / description

Added value: +"The URL of the operator's LinkedIn profile."

addedOutput schema / properties / location / description

Added value: +"The city and country where the business is based."

addedOutput schema / properties / operator / description

Added value: +"Who runs turva.dev and the registered business behind it."

addedOutput schema / properties / operator / properties / background / description

Added value: +"The professional background of the person who runs the business."

addedOutput schema / properties / operator / properties / business_id / description
```
Added value: +"The Finnish business ID of the business."
```
addedOutput schema / properties / operator / properties / legal_form / description
```
Added value: +"The legal form of the business."
```
addedOutput schema / properties / operator / properties / location / description
```
Added value: +"Where the business is based: city, region and country."
```
addedOutput schema / properties / operator / properties / name / description
```
Added value: +"The trading name of the business."
```
addedOutput schema / properties / operator / properties / run_by / description
```
Added value: +"The person who runs the business."
```

addedOutput schema / properties / operator / properties / team / description

Added value: +"Who works at the business and how clients work with them."

addedOutput schema / properties / operator / properties / vat_id / description
```
Added value: +"The VAT identification number of the business."
```

addedOutput schema / properties / signal / description

Added value: +"A link that opens a Signal chat with the operator."

Changed2 schema fields changedSep 23, 2026

addedOutput schema / properties / operator

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "background": {
+      "type": "string"
+    },
+    "business_id": {
+      "type": "string"
+    },
+    "company_page": {
+      "description": "The turva.dev page that states the business details.",
+      "type": "string"
+    },
+    "legal_form": {
+      "type": "string"
+    },
+    "location": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "run_by": {
+      "type": "string"
+    },
+    "team": {
+      "type": "string"
+    },
+    "vat_id": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "run_by",
+    "legal_form",
+    "business_id",
+    "vat_id",
+    "location",
+    "team",
+    "background",
+    "company_page"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "email",
-  "signal",
-  "linkedin",
-  "business_id",
-  "location",
-  "engagement",
-  "correspondence_languages",
-  "first_reply",
-  "channel_note",
-  "how_to_start"
-]New value: +[
+  "email",
+  "signal",
+  "linkedin",
+  "business_id",
+  "location",
+  "engagement",
+  "correspondence_languages",
+  "first_reply",
+  "channel_note",
+  "how_to_start",
+  "operator"
+]

Changed3 schema fields changedSep 23, 2026

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "business_id": {
+      "type": "string"
+    },
+    "channel_note": {
+      "type": "string"
+    },
+    "correspondence_languages": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "email": {
+      "type": "string"
+    },
+    "engagement": {
+      "type": "string"
+    },
+    "first_reply": {
+      "type": "string"
+    },
+    "how_to_start": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "linkedin": {
+      "type": "string"
+    },
+    "location": {
+      "type": "string"
+    },
+    "signal": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "email",
+    "signal",
+    "linkedin",
+    "business_id",
+    "location",
+    "engagement",
+    "correspondence_languages",
+    "first_reply",
+    "channel_note",
+    "how_to_start"
+  ],
+  "type": "object"
+}

AddedSep 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the payload is static JSON compiled into the Worker, mutates nothing, and only refreshes on deploy — which tells the agent the data can be stale relative to the live site. It stops short of a 5 only because it says nothing about caching or response size.

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?

Front-loaded with the resource and its contents, then usage, then the sibling exclusion, then the behavioral note — a sensible ordering. The long enumeration of returned fields is slightly redundant given an output schema exists, but each clause still helps an agent judge relevance.

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?

For a zero-parameter read tool with a full output schema and four annotations, the description covers everything an agent needs: what it returns, when to call it, when to call something else, and how the data is produced/refreshed. Return-value details are correctly delegated to the output schema.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies a no-argument call and needs to add no parameter meaning; there is nothing further the schema could document.

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?

States a specific verb and resource (returns the operator/contact details of turva.dev) and enumerates the concrete payload (email, Signal, LinkedIn, languages, first-reply time, audit access). It also explicitly carves out the sibling boundary against get_services, so an agent can differentiate it without opening schemas.

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?

Gives an explicit trigger list ('when a user asks who is behind turva.dev, how to contact it, how to start an audit or what access has to be granted') and names the alternative tool (get_services) with the condition that selects it. Nothing is left to inference.

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

All turva-mcp tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?