Skip to main content
Glama

conduyt_ai_chat

Send a multi-turn message thread to a CRM-grounded AI assistant and optionally pin the chat to a contact or deal record so replies use live context; returns the assistant's response.

Instructions

Conversational AI assistant grounded in your CRM. Send a multi-turn message thread and optionally pin it to a record (contact/deal) so the assistant has live context. Returns the assistant's reply.

Input Schema

NameRequiredDescriptionDefault
contextNoFreeform extra context to ground the reply
sectionNoPin the chat to a specific record for grounded answers
messagesYesConversation thread, oldest first. Max 20 messages, 4000 chars each.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions multi-turn messages, optional record pinning, and that a reply is returned, but it does not disclose whether the operation is read-only, whether chats are persisted, what pinning changes on the record, or any auth/rate/cost behavior.

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 tightly written sentences with no filler. The purpose is front-loaded, followed by the key input behavior and return value.

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

Completeness3/5

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

The nested parameter schema is richly documented, no output schema exists, and the description states that the assistant's reply is returned. But with no annotations and no sibling usage guidance, the definition leaves important behavioral and routing context thin.

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%, and the schema already explains messages, section, and context in detail. The description adds only a high-level note about the multi-turn thread and record pinning, so it meets the baseline for fully covered parameters without adding much beyond the schema.

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

Purpose4/5

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

The description states a clear verb and resource: send a multi-turn message thread to a CRM-grounded conversational AI assistant and get a reply. It also clarifies the optional record pinning behavior, but it does not explicitly distinguish this from sibling AI tools such as conduyt_ai_insights or conduyt_ai_compose_email.

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

Usage Guidelines3/5

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

The description implies usage for general CRM-grounded conversation and optional record-specific context via pinning. However, it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives among the many AI sibling tools.

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