Skip to main content
Glama
Ak47dev-biz

ATLAS MCP Server

by Ak47dev-biz

atlas_ingest_chat_history

Ingest conversation transcripts to analyze behavioral patterns, recurring themes, and psychological insights, turning raw dialogue into actionable understanding for coaching and advisory work.

Instructions

Analyze past conversation transcripts for behavioral patterns, recurring themes, and psychological insights.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesWhere the chat history is from (e.g., 'therapy sessions', 'coaching calls', 'journal entries')
raw_textYesThe conversation/text content to analyze
observed_patternsNoPatterns observed by Claude during analysis

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of explaining side effects. It only says 'Analyze...' and never discloses whether the tool persists the raw text, writes observed patterns to a profile, or merely returns analysis. The name includes 'ingest', suggesting persistence, but the description does not confirm or explain that behavior.

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?

The description is a single sentence with no filler and a clear front-loaded verb and object. It is concise, though the missing usage and side-effect context means the brevity comes at some cost.

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

Completeness2/5

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

This is an ingestion-oriented tool with no annotations and no output schema, yet the description does not clarify what happens after analysis, whether data is stored, or whether observed_patterns is intended as an input or a result. These are material gaps for an agent deciding whether and how to invoke it.

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 source, raw_text, and observed_patterns are already documented in the JSON Schema. The description adds only the general theme of pattern analysis and contributes no additional meaning to individual parameters.

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 concrete action ('Analyze') on a specific resource ('past conversation transcripts') and names the analytic outcomes ('behavioral patterns, recurring themes, psychological insights'). It doesn't explicitly differentiate this from sibling ingest tools or atlas_add_pattern, but the chat-history resource is distinct enough to orient an agent.

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 phrase 'past conversation transcripts' implies the tool is meant for conversational text, but there is no explicit when-to-use guidance, no named alternatives, and no exclusions. The agent must infer fit from the resource type rather than from stated selection criteria.

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