Skip to main content
Glama

Import profile from LinkedIn or resume

import_profile
Destructive

Fill in the user's Himalayas profile from their LinkedIn profile URL or their resume text. Runs in the background for a few minutes; get_my_profile shows the result. append_only adds what's missing and keeps what's there; replace_all overwrites the profile, so ask the user first. Uses the connected Himalayas account; no extra sign-in needed.

Input Schema

NameRequiredDescriptionDefault
modeNoDefault append_only
resume_textNoThe full text of their resume
linkedin_urlNoTheir LinkedIn profile URL, e.g. https://www.linkedin.com/in/name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag non-read-only and destructive, but the description adds behavior the schema cannot express: the call returns immediately while work continues in the background for minutes, the output is surfaced via get_my_profile, replace_all is irreversible and needs user confirmation, and no separate sign-in is required. This is exactly the added context the annotations leave out.

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?

Four short sentences with no filler; purpose and inputs lead, the asynchronous/retrieval detail and mode trade-off follow. Every sentence carries information an agent needs.

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 an async, destructive-capable import tool with no output schema, the description covers initiation, expected latency, how to observe the result, the destructive path and its confirmation requirement, and auth expectations — nothing material is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description goes beyond the schema's terse "Default append_only" by explaining the semantic effect of each mode value and implying that at least one of linkedin_url or resume_text must be supplied (both are optional in the schema).

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 (fill in / import) on a specific resource (the user's Himalayas profile) and names both accepted input sources (LinkedIn URL, resume text). This clearly separates it from siblings like update_profile (manual edits) and get_my_profile (retrieval).

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?

Explains the mode choice explicitly — append_only adds missing fields and keeps existing ones, replace_all overwrites so the user must be asked first — and routes the agent to get_my_profile for the result. It stops short of naming sibling alternatives such as update_profile for piecemeal edits, so it is clear context rather than full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources