Skip to main content
Glama

icp

Read-only

Validate a saved target profile against LinkedIn or audit it against a campaign goal without creating campaigns, contacts, or records. See matched profiles, filter contributions, and fit scores.

Instructions

Preview a saved ICP against LinkedIn, or audit it against a campaign goal, without creating anything.

Runs the search create_campaign would run from the ICP's enriched LinkedIn
codes and shows what comes back, how each filter is shaping the result, and
how the profiles score against the persona. It creates no campaign, no
outreach records and no contacts, so an ICP can be checked and rejected
without cleanup. Use it when the targeting is unproven or when someone asks
for example profiles for an ICP.

Args:
    action: "preview" shows matched profiles, the exact filters sent to
        LinkedIn with their resolved code names, a per-filter contribution
        readout, and the fit scores. "goal_match" runs no search at all:
        it asks whether the ICP's personas actually hold budget authority
        for the campaign's goal, grounded in the shipped sales-methodology
        knowledge base, and returns match / partial / mismatch with the
        decision-maker coverage and concrete fixes.
    icp_id: ID of a saved ICP from generate_icp (a truncated id works).
        Leave empty to list your saved ICPs.
    persona: Which persona of the ICP to search with, 1-based (default 1).
        An ICP usually holds 2-4; each has its own filters.
    limit: How many matched profiles to list, 1-50 (default 10). The search
        itself always fetches one full page regardless.
    campaign_id: goal_match only — take the goal and the offer from this
        campaign's config/context instead of typing them.
    target_description: goal_match only — the goal to audit against when
        there is no campaign yet. Falls back to the ICP's own target.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
actionNopreview
icp_idNo
personaNo
campaign_idNo
target_descriptionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.375

TDQS

A5/5.0
Behavior5/5

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

Annotations already state readOnlyHint=true and openWorldHint=true, but the description adds meaningful behavioral detail beyond that: it creates no campaign, no outreach records, and no contacts; it always fetches one full page from LinkedIn regardless of limit; and goal_match runs no search at all. These details are not derivable from the annotations or schema and materially shape invocation expectations.

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?

The description is front-loaded with the core purpose, then a short use-case sentence, then a compact args list. Every sentence earns its place: even details like 'the search always fetches one full page regardless' and 'Leave empty to list your saved ICPs' add operational value. The structure separates prose from parameters cleanly, making it scannable for an agent.

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 a two-action tool with six parameters, the description covers all invocation paths: preview behavior, goal_match behavior, optional campaign_id, fallback target_description, empty icp_id behavior, and per-action outputs. An output schema exists, so return-value documentation is not necessary. There are no missing operational details that would prevent an agent from invoking this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden for all 6 parameters. It does this thoroughly: action has both values explained, icp_id notes that it may be empty to list saved ICPs, persona has a 1-based default and explains multiple personas, limit constrains range and behavior, and campaign_id and target_description are gated to goal_match with fallback semantics. This exceeds what the bare schema provides.

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?

The description opens with a specific verb-resource pair: 'Preview a saved ICP against LinkedIn, or audit it against a campaign goal, without creating anything.' It clearly distinguishes itself from create_campaign by explaining it runs the same search but creates no campaign, outreach records, or contacts. The two actions, preview and goal_match, are explicitly defined.

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?

The description gives explicit when-to-use guidance: 'Use it when the targeting is unproven or when someone asks for example profiles for an ICP.' It also names create_campaign as the alternative tool and explains the key difference: this tool does not create anything, so ICPs can be checked and rejected without cleanup. This effectively tells an agent when not to use the mutation tool.

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