Store LinkedIn profile data and extracted facts to build career context. Convert raw profile text into structured professional history for personalized coaching and advisory.
Store LinkedIn profile data for career context building.
| Name | Required | Description | Default |
|---|---|---|---|
| raw_text | Yes | LinkedIn profile text or data export | |
| extracted_facts | No | Structured facts extracted from LinkedIn |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Store', revealing a write operation but nothing about overwrite/append semantics, idempotency, whether raw_text is parsed, or what happens to existing profile data. This is a meaningful gap for an ingest tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It earns its place by naming the resource and purpose, though it is too sparse to fully carry behavioral and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is underspecified for an ingest/write tool. It does not explain expected side effects, data flow, return behavior, or how this relates to existing profile data. The schema covers parameters well, but contextual behavior is largely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (raw_text and extracted_facts) already have meaningful descriptions in the schema. The tool description adds no parameter-specific detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Store') and resource ('LinkedIn profile data'), and connects it to a clear purpose ('career context building'). It is distinguishable from sibling ingest tools by naming LinkedIn as the data source, though it could more explicitly contrast with atlas_ingest_resume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the agent has LinkedIn profile data that should be stored for career context. However, it does not explicitly state when not to use it, nor does it name alternatives like atlas_ingest_resume or atlas_update_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.