Datamagnet

Create signal

create_signal

Destructive

Create a standing monitor that notifies the account when something happens on LinkedIn. Free to create.

What each type watches:

job_change — tracked people changing job or company
new_post — tracked people publishing a new post
person_activity — tracked people reacting to or commenting on any post, anyone's: their own engagement, reported one item at a time
keyword_engagement — people engaging with posts matching keywords
industry_engagement — people engaging with posts from an industry
company_engagement — people engaging with specific companies' posts
person_engagement — people engaging with specific people's posts (the reverse of person_activity)

job_change, new_post and person_activity require profile_urls. An account can run several of one type (say "Champions" and "Churned customers"), each with its own signal_id. Without signal_id, a create adds the profiles to the account's only signal of that type, or starts one if there is none. Pass signal_id to add to a specific signal, or new_signal: true to start another. With several and neither given, the call fails: find the right one with list_signals. Adding to a signal keeps its name and settings; if it is paused, resume it first.

name is an optional display label for a new signal. It can repeat and can be changed later with update_signal action rename.

person_activity takes an optional activity_types: reactions, comments, or both (the default). Each costs one lookup per profile per run, so asking for one halves the cost. It applies when the monitor is first created; on an existing monitor change it with update_signal action update_activity_types. The first run records a baseline and reports nothing; after that every new reaction, comment and reply is reported once.

keyword_engagement requires keywords, and takes an optional icp object to filter and score the leads it surfaces. Several of these can coexist; each gets its own signal_id.

Notifications go to the account email. additional_emails adds more recipients. webhook_url receives a POST when the signal fires, signed with webhook_secret if one is given.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`icp`	No
`name`	No
`keywords`	No
`signal_id`	No
`new_signal`	No
`signal_type`	Yes
`webhook_url`	No
`profile_urls`	No
`activity_types`	No
`webhook_secret`	No
`additional_emails`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: free creation, notification routing to account email, additional recipients, signed webhooks, per-run lookup costs, and baseline behavior on first run. It also explains that adding profiles preserves existing signal name/settings.

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 long but dense and largely front-loaded, with no obvious filler. The type list and multi-paragraph rules are appropriate for an 11-parameter tool, though the density could be organized slightly more crisply.

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?

Given seven signal types, 11 parameters, and an output schema, the description covers the essential creation workflows, notification behavior, update handoff, and failure conditions. The main remaining gap, icp internals, is a minor detail rather than a missing operational requirement.

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?

With 0% schema description coverage, the description carries most parameter meaning: it explains signal_type values, required profile_urls, signal_id/new_signal semantics, activity_types cost/default, keywords, icp filtering/scoring, and notification params. It still leaves profile_urls format and icp object structure unspecified.

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 and resource: 'Create a standing monitor' for LinkedIn activity. It immediately distinguishes the tool from siblings by explaining signal types and linking lifecycle actions to list_signals and update_signal.

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

Usage Guidelines5/5

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

Explicitly covers when signal_id, new_signal, and neither should be used, including the failure mode when multiple signals exist. It also states prerequisites like profile_urls for certain types, keyword requirements, and the need to resume a paused signal before adding to it.

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

All Datamagnet tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.