Skip to main content
Glama
TsvetanG2

cognigy-ai-mcp-management-server

by TsvetanG2
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript

set_contact_profile_schema

Idempotent

Add or update custom fields in a Cognigy.AI project's contact profile schema while preserving built-in and unlisted custom fields. Run with dryRun false to apply changes.

Instructions

Adds or updates custom fields in the Cognigy.AI contact profile schema of a project. Built-in fields (firstname, email, ...) always exist; existing custom fields not listed are kept. MUTATING: Set dryRun=false to update.

Input Schema

NameRequiredDescriptionDefault
dryRunNoIf true (default), validates without updating. Set to false to actually update.
schemaYesCustom fields to add or update. Existing custom fields with the same internal name are replaced; others are kept.
projectIdYesThe project ID to set the profile schema for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.1
    • changedInput schema / properties / schema / description
      Previous value: -"Array of schema field definitions"New value: +"Custom fields to add or update. Existing custom fields with the same internal name are replaced; others are kept."
    • removedInput schema / properties / schema / items / properties / description
      Removed value: -{
-  "description": "Field description",
-  "type": "string"
-}
    • addedInput schema / properties / schema / items / properties / field
      Added value: +{
+  "description": "Display name of the field",
+  "type": "string"
+}
    • addedInput schema / properties / schema / items / properties / internal
      Added value: +{
+  "description": "Reference name used in code, e.g. profile.<internal>",
+  "type": "string"
+}
    • removedInput schema / properties / schema / items / properties / name
      Removed value: -{
-  "description": "Field name",
-  "type": "string"
-}
    • changedInput schema / properties / schema / items / properties / type / enum
      Previous value: -[
-  "string",
-  "number",
-  "boolean",
-  "array",
-  "object"
-]New value: +[
+  "string",
+  "number",
+  "boolean",
+  "object"
+]
    • changedInput schema / properties / schema / items / required
      Previous value: -[
-  "name",
-  "type"
-]New value: +[
+  "field",
+  "internal",
+  "type"
+]
    • addedInput schema / properties / schema / minItems
      Added value: +1
  2. First observedv0.1.4

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and the description adds real substance: merge semantics (existing custom fields not listed are kept) and the default-safe dry-run gate. It does not mention permission requirements, but the non-destructive merge behavior is disclosed and consistent with annotations.

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

Conciseness5/5

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

Three short, front-loaded sentences: purpose first, then preservation semantics, then the mutation toggle. No filler, and the most decision-relevant fact (dryRun=false to actually write) is placed last for emphasis without burying it.

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

Completeness4/5

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

With no output schema and a nested array parameter, the description adequately covers what changes and what is preserved, which is the key risk for this operation. It leaves auth/preconditions and return behavior unstated, but those are secondary for a 3-parameter, 100%-covered schema.

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

Parameters3/5

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

Schema description coverage is 100%, so dryRun, schema, and projectId are already documented in the schema, including the same dry-run and merge semantics repeated in the description. The description adds no syntax or format detail beyond the structured fields, so the baseline 3 applies.

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?

Names a specific verb pair ('Adds or updates') and a precise resource ('custom fields in the Cognigy.AI contact profile schema of a project'), which separates it from siblings like update_contact_profile (contact data) and get_contact_profile_schema (read counterpart). An agent can identify the target object without opening the schema.

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

Usage Guidelines4/5

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

Gives clear operational context: built-in fields always exist and unlisted custom fields are kept, plus the explicit instruction 'Set dryRun=false to update.' It stops short of naming alternatives (e.g., get_contact_profile_schema for reading), but the mutating condition is spelled out.

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

Deploy Server

Other Tools