A
licenseNot graded
qualityB
maintenancePerplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
2
Apache 2.0
PumpGTM
This connector has been deprecated
Duplicate listing. The official PumpGTM connector is https://glama.ai/mcp/connectors/com.pumpgtm/mcp (same server, https://mcp.pumpgtm.com/mcp).
Server Details
Outbound from your AI. Find people who match your ideal customer, run paced LinkedIn, email and X sequences from your own accounts, and approve drafted replies. Nothing is sent without your approval. Includes a free library of the most-liked cold messages on X. OAuth sign-in; docs at https://pumpgtm.com/docs/mcp
Ownership verified
- Status
- Healthy
- Uptime
- 96.6% over 22 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.7/5.0
Scored across 35 tools
Disambiguation3/5
Several tools overlap around sourcing, enrollment, and Play management: add_leads, add_to_sequence, and reach_universe all touch sequence enrollment, while find_people, manage_x_play, reach_post_engagers, and research_competitor all create or extend audience sources. Descriptions add explicit guardrails and cross-references, but choosing the right tool still requires careful reading.
Naming Consistency4/5
Most tools follow a readable snake_case verb_noun pattern (add_leads, get_company, save_opportunity, list_sequences, review_people). Minor exceptions such as energy, x_account, and sequence_email_settings are noun-only but still understandable in context.
Tool Count2/5
With 35 tools, the surface is heavy for an agent to navigate, and many tools are themselves multi-action entry points (add_leads, save_sequence_draft, set_lead_input). The breadth may reflect the platform, but it exceeds a well-scoped MCP tool set and increases selection risk.
Completeness4/5
The set covers the major GTM lifecycle: lead discovery and enrichment, sequences and email settings, CRM companies/opportunities, reply handling, signals, X Plays, webhooks, and billing/Energy. Some lifecycle gaps remain, such as no obvious sequence deletion/archive or general contact/opportunity deletion, but core workflows are well represented.
Available Tools
37 toolsadd_company_contactLink company contactAInspect
Add a company contact, optionally linked to an existing PumpGTM lead in this workspace. Never guess a lead match from a company name. Does not create or enroll outreach leads.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes | ||
| role | Yes | ||
| Yes | |||
| lead_id | Yes | ||
| company_id | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine effect-boundary context: contact creation is separate from lead creation/enrollment, and lead linkage is optional and must come from a known ID rather than inference. It does not cover permissions or duplicate-handling behavior.
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?
Three short sentences, zero filler, front-loaded with the core action and then the two constraints. Every sentence carries a distinct piece of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the tool is a 7-parameter mutation with 14% schema coverage, so the description carries a heavy load. It covers purpose and effect boundaries well but leaves most parameter semantics and post-call behavior undocumented, which is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (just workspaceId), and the description only compensates for one field: it clarifies that the lead link is optional, which matters because lead_id is required-but-nullable in the schema. The other five required fields (id, company_id, name, email, role) get no added meaning, and there is no hint of ID sourcing rules.
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 ('Add a company contact') plus the scope qualifier ('optionally linked to an existing PumpGTM lead in this workspace'). It also draws an explicit boundary against the sibling add_leads ('Does not create or enroll outreach leads'), so an agent can distinguish it from add_leads without opening either schema.
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?
Gives a real rule of use ('Never guess a lead match from a company name') and a when-not condition ('Does not create or enroll outreach leads'). It stops short of naming a specific alternative tool to use for the lead-creation case, so the routing is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_leadsAdd leads to a sequenceIdempotentInspect
Queue leads into one approved sequence: contacts accepts 1–500 supplied people with LinkedIn, email, and/or X identities plus expectedRevision. It supports X-only and email-only contacts, preserves supplied fields, performs no paid enrichment, skips existing identities across all channels, and keeps paused sequences paused. Other methods accept manual LinkedIn profiles, CSV content, or a saved Sales Navigator list URL. Manual and CSV finish immediately and return added, duplicate, and invalid counts plus stable addedLeadIds. Sales Navigator runs in the background and auto-enrolls; use method=import_status with its batchId to check. Optional accountId binds new LinkedIn leads to that connected workspace sender. Omit for automatic assignment. Sales Navigator uses an explicit choice for both fetching and sending. Existing leads are never reassigned. Nothing is sent in this call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
add_to_sequenceAdd universe people to a sequence (LinkedIn, email, or both)AInspect
Pick people from the account universe (by competitor name, playId, or exact candidateIds; notYetEnrolled skips anyone already in a sequence) and add them to one sequence: an existing non-archived sequenceId from list_sequences, or a new draft named name built from template linkedin | email | linkedin_email (then edit its steps with save_sequence_draft). Email-only sequences skip people without a known email; mixed sequences keep them and their email steps wait until an address is known; findEmails=true first looks up missing addresses, metered. Adding never approves, launches, or sends: the customer approves and starts the sequence with set_sequence_status.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| playId | No | ||
| template | No | ||
| competitor | No | ||
| findEmails | No | ||
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| candidateIds | No | ||
| notYetEnrolled | No | ||
| maxEmailLookups | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give generic safety flags (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds genuinely new behavior: notYetEnrolled skipping, email-only sequences skipping unknown-email people, mixed sequences deferring email steps, findEmails being a metered lookup, and the no-approve/no-send boundary. This is substantial context beyond the structured fields.
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?
Dense but front-loaded, leading with the action and target. Every clause adds operational meaning (skip rules, metering, lifecycle boundary). A bulleted or segmented form would scan better, but there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no output schema, the description covers selection, targeting, side effects, and lifecycle limits well. The main gap is no indication of the return shape (e.g., counts of added/skipped people) and the omitted maxEmailLookups/template values, though nothing an agent needs to invoke it correctly 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?
With only 10% schema description coverage across 10 params, the description carries the burden and mostly delivers: it explains competitor, playId, candidateIds, notYetEnrolled, sequenceId, name, template, and findEmails semantics. It omits maxEmailLookups and lists only 3 of the 7 template enum values (linkedin | email | linkedin_email), leaving gaps an agent must infer.
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 precise verb+resource: pick people from the account universe and add them to one sequence. It names the selection modes (competitor, playId, candidateIds), the two targets (existing sequenceId vs new draft), and routes to specific siblings (list_sequences, save_sequence_draft, set_sequence_status), so an agent can distinguish it from add_leads, add_company_contact, or find_people without opening a schema.
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?
Explicit when-to-use branches: an existing non-archived sequenceId from list_sequences, or a new draft via template (then edit with save_sequence_draft). It also states when email-only vs mixed sequences behave differently and clarifies that adding never approves, launches, or sends, deferring that to set_sequence_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
decide_replyApply the customer's reply decisionADestructiveInspect
Apply one explicit human decision to a pending reply. send, invite, and booking_link contact the prospect; opt_out is permanent. Show the draft and ask the customer first. Pass the item's draftId when it has one (LinkedIn, Instagram and X drafts alike; an X draft's send goes out immediately as a direct message on X from the account that owns the conversation, uses Energy, and does not accept invite). Only for an X reply with no draft pass leadId instead: send then requires text the customer approved, shown to them word for word first, and X accepts only send, snooze, dismiss, opt_out and meeting_booked. Sending the same text again for the same reply returns alreadyDecided instead of a second message.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| text | No | ||
| leadId | No | X replies without a draft only: the item's leadId, used when there is no draftId. | |
| draftId | No | The pending reply's id, on any channel, when the item has one. | |
| decision | Yes | ||
| decidedBy | No | mcp | |
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/non-idempotent, and the description adds substantial context beyond them: opt_out is permanent, an X send goes out immediately as a DM using Energy, and resending identical text returns alreadyDecided instead of a second message. These are concrete side-effects an agent cannot infer from the schema or hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, but the remaining content is delivered as long run-on sentences with nested parentheticals (the X-draft clause) that are dense and hard to parse. The information earns its place, yet the structure and readability suffer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, 7-parameter, multi-channel mutation tool with no output schema, the definition covers decision semantics, channel differences, prerequisites, and a key return value (alreadyDecided). It omits meaningful handling of 'days' (presumably snooze) and 'decidedBy', leaving small gaps.
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 only 43% schema coverage the description must compensate, and it does for the critical params: draftId scope (any channel), leadId restriction (X replies without a draft), and the 'text' precondition of customer-approved wording shown word for word. It leaves 'days' and 'decidedBy' unexplained, so it is strong but not complete.
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?
States a specific verb and resource ('Apply one explicit human decision to a pending reply') and enumerates exactly what each decision does (send/invite/booking_link contact the prospect; opt_out is permanent). It is clearly distinct in behavior from the listing siblings, though it never names a sibling to route against, so it earns a 4 rather than a 5.
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?
Gives explicit prerequisites ('Show the draft and ask the customer first'), tells the agent which identifier to pass and when ('Pass draftId when it has one... only for an X reply with no draft pass leadId'), and states per-channel constraints ('X accepts only send, snooze, dismiss, opt_out and meeting_booked'). This is textbook 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.
energyEnergy balance and top-upInspect
Read this workspace's Energy (what is left, what each action costs, this month's use, renewal); estimate what planned work will cost against it; and, when asked, get a payment link to buy packs or switch automatic top-up on or off. Buying needs the customer to open the link and pay. Enabling automatic top-up authorizes future charges to the saved card and requires explicit customer consent after explaining the amount and threshold.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| buy | No | ||
| estimate | No | Counts of planned work: peopleToFind, xAudiencePeople, xDms (with history checks), xDmsUnchecked (send-only, 0.6 Energy each), xFollows, xUnfollows, xLikes, xReposts (cost Energy) and linkedinInvites, linkedinMessages, emails (free, listed as zero). Returns the Energy and dollars it will cost, whether the balance covers it, and the packs that would close a shortfall. | |
| autoTopUp | No | true authorizes recurring $10 card charges for 75 Energy whenever the balance falls below 50; obtain explicit customer consent to those terms first. false turns it off. Send it with buy to get the payment link and turn top-up on in one call. | |
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
enrich_personBuild a person profileInspect
Look up one person by email or by public LinkedIn person URL (send exactly one; an email is matched to a LinkedIn profile first). Returns person: name, title, headline, location, company {name, domain}, linkedin, and connections (previously observed public follows) when there are any; person is null when nobody matches. Add find: ["x"] to get their X account, returned only when its name matches and its own bio or link points at their LinkedIn, company domain or company name (x.evidence says which). Add find: ["work_email"] for a work email; check workEmail.matchesCompanyDomain before using it. Add find: ["mobile"] for a verified mobile number (about 10 Energy when one is found). A requested extra that did not come back is listed in missing with a reason (not_found means no confident match, not that it does not exist). Uses workspace Energy; 1 Energy is $0.05; energyUsed is what this call spent. Read energy.peopleDataPricing first; cached lookups are free. Requires Energy enabled. Add leadId (one of your own leads, the same person) with find: ["work_email"] to save the found email on that lead; lead.email says attached, lead_has_email, different_person, email_on_another_lead or no_email. Never overwrites an existing email. Does not create leads or send outreach. Repeated calls can cost Energy; never automatically retry a timeout or error. Use find_people for audience discovery, not this tool.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| find | No | ||
| No | |||
| leadId | No | ||
| No | |||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
find_peopleFind peopleAIdempotentInspect
Create or revise a Play from targeting and run it. Targeting may include a hiring signal (currentCompanyHiringRolesAny): the person's current company must have an open job posting for one of those roles, posted within currentCompanyHiringPostedWithinDays. It may include a fundraising signal (currentCompanyRaisedWithinDays, optionally currentCompanyRoundTypesAny and currentCompanyMinRaisedUsd): the person's current company must have closed a funding round that recently; such a Play is re-run once a day so newly funded companies keep arriving for review. Without confirmed=true it only saves the Play and returns the targeting summary; then call again with confirmed=true without asking the customer. Company names are resolved automatically and never block: when several companies share a name, an exclusion covers all of them and a required company includes every strong match; pass a website domain in currentCompanyDomainsAny or a LinkedIn company URL in currentCompanyLinkedInUrlsAny to pin one exactly. The result's companyResolution reports each company's outcome (matched, matched_several, unmatched) with the companies chosen, so you can mention it in one line if useful. With confirmed=true, the Play runs discovery and returns candidates in retrieval order. Pass playId alone to rerun an existing ready Play. Optional sequenceId sets the Play's default sequence. Creates no leads and contacts no one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| playId | No | ||
| confirmed | No | ||
| requestId | Yes | Stable idempotency key; reuse it only to retry this exact request. | |
| targeting | No | ||
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| expectedRevision | No | Required with targeting when revising an existing playId. |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the annotations: 'Creates no leads and contacts no one,' that fundraising-signal Plays are re-run once a day, that company-name resolution never blocks and how it behaves with ambiguous names, and that a recovered companyResolution field is returned. These are traits the readOnlyHint/destructiveHint/idempotentHint annotations cannot convey.
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 definition is a single dense paragraph, front-loaded with the core action and then the confirmed/playId flow. Nearly every sentence earns its place, though the signal-resolution detail is packed tightly enough to be hard to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested tool with no output schema, the description covers the create/revise/run lifecycle, the confirmation gate, signal semantics, and the key return field (companyResolution). It is nearly complete; only workspace/expectedRevision usage is left entirely to the schema.
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 only 43%, so the description must compensate, and it does for the signal parameters: it explains the hiring signal (open posting for a role, posted within currentCompanyHiringPostedWithinDays), the fundraising signal, and that a domain or LinkedIn URL pins a company exactly. It does not explain requestId, workspaceId, or expectedRevision, but those are covered in the schema.
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 opens with a specific verb and resource: 'Create or revise a Play from targeting and run it,' then elaborates that it runs discovery and returns candidates. It distinguishes itself from siblings like manage_x_play and review_people by describing the create/revise/run flow. However, the name 'find_people' does not obviously map to 'create a Play,' so the agent must reconcile the mismatch.
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?
Explicit when-to-use guidance: without confirmed=true it only saves the Play and returns the targeting summary, then 'call again with confirmed=true without asking the customer.' It also states 'Pass playId alone to rerun an existing ready Play,' naming the alternative invocation path directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cold_message_examplesExample cold messagesARead-onlyIdempotentInspect
A random sample from PumpGTM's library of the most-liked public posts on X about writing cold emails and DMs, each with its link and why it was kept. Use them as references when drafting or critiquing a cold message; credit the author and do not copy them word for word. Read-only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the description's trailing 'Read-only' is largely redundant. What it adds beyond the structured data is the nature of the sample (random, most-liked public posts) and the usage obligations (attribution, no verbatim copying), which is genuine behavioral context.
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?
Two sentences, front-loaded with what the tool returns (sample, source, per-item contents) before the usage instructions. No filler, no restatement of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the right thing by stating what each item contains (link plus rationale). Safety requirements for a read-only tool are covered by annotations, and the usage constraints are stated. Only the undocumented count parameter and sampling size behavior leave a small gap.
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 coverage is 50%: workspaceId is fully documented in the schema, but count (integer, 1-10, default 5) has no description anywhere. The description says nothing about either parameter, so it neither compensates for the gap nor adds meaning beyond the schema; the borderline coverage puts this at the baseline.
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 names a specific resource (a random sample from PumpGTM's library of most-liked public X posts about cold email/DM writing) and states exactly what each item contains (link and reason it was kept). No sibling in the list overlaps with this resource, so an agent can identify it immediately from name plus description.
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?
It gives clear positive guidance: use these as references when drafting or critiquing a cold message, credit the author, and do not copy word for word. There is no explicit when-not or named alternative, but this tool has no sibling that could be confused with it, so the routing context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_companyCustomer 360ARead-onlyIdempotentInspect
Company, linked lead contacts, opportunities, success plan, and latest 100 source-attributed events. Recorded/imported signals do not imply a live provider connection.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: results are capped at the latest 100 source-attributed events, and recorded/imported signals do not imply a live provider connection — a caveat an agent could otherwise misread as an active integration.
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?
Two tight sentences with the returned-content inventory front-loaded and the caveat second. No filler; every clause carries content. Slightly terse, but nothing wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description effectively stands in for one by listing the returned sections, including the 100-event cap. For a read-only tool whose annotations already declare safety and idempotency, this is close to complete; only the omission of when-to-use guidance leaves a gap.
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 coverage is 50%: workspaceId is well documented in the schema (teammate workspace, omit for own, supply on every call), while company_id has no description but is a self-evident uuid. The description adds no parameter meaning beyond the schema, so the baseline 3 for partial coverage is appropriate.
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 enumerates exactly what the tool returns (company, linked lead contacts, opportunities, success plan, latest 100 events), which is specific enough to distinguish it from person-centric siblings like get_lead_profile and find_people. It lacks an explicit verb such as 'retrieve', but the resource list makes the read intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_lead_profile or list_signal_events, and no prerequisites are stated. The meaning is inferable from the content list alone, but nothing routes the agent between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lead_profileRead a person's professional profileARead-onlyIdempotentInspect
Read source-dated public identities, available employment history, public activity and relationship observations for a lead owned by this workspace. Public profile links and AI interpretations require review. This does not fetch providers, change identities, enroll or contact anyone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds value by disclosing that identities are 'source-dated', that profile links and AI interpretations 'require review', and that it triggers no providers or outreach — context annotations cannot express.
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?
Three sentences, front-loaded with what is read before the caveats and exclusions. No wasted clauses, though phrasing like 'source-dated public identities' and 'relationship observations' leans on internal jargon that could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the work of enumerating the returned data categories (identities, employment history, activity, relationships) and the review caveat. It stops short of describing pagination or field-level detail, but is adequate for a two-parameter read tool.
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 coverage is 50%: workspaceId is well documented in the schema, while leadId is only a UUID pattern with no prose. The description adds no parameter-level meaning at all, but leadId being a self-evident UUID limits the practical gap, so the baseline 3 is appropriate.
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?
States a specific verb ('Read') and an enumerated set of resources (public identities, employment history, public activity, relationship observations) scoped to 'a lead owned by this workspace'. This is enough to distinguish it from write-style siblings like enrich_person or set_lead_input, though it doesn't name a sibling explicitly.
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 closing sentence gives useful negative scope ('does not fetch providers, change identities, enroll or contact anyone'), which implicitly steers agents away from enrich_person and sequence tools. However, there is no explicit positive when-to-use statement or named alternative, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lead_threadRead a lead's LinkedIn conversationRead-onlyIdempotentInspect
Read incoming and outgoing LinkedIn messages using the lead's original sender. No sends, reply decisions or read receipts. Pass leadId from list_leads and optionally limit (1–100, default 50). Each page is oldest first; nextCursor retrieves the next older page, so prepend it to the conversation. Reuse cursors only for the same lead and workspace within 30 minutes. available=false means the lead has no saved LinkedIn thread yet; provider failures are errors, never empty history. Text and attachment presence only; no attachment downloads. LinkedIn only for now.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| leadId | Yes | ||
| channel | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
get_pipelineSales pipelineBRead-onlyIdempotentInspect
Read your workspace's CRM opportunities and company lifecycle. Money is in minor units and totals are separated by currency. Probabilities are explicit stage/team estimates, not calibrated predictions or verified revenue. Requires the CRM feature.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| scope | No | Active excludes archived companies; archived and all preserve historical access. | active |
| offset | No | ||
| currency | No | ||
| attention | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), so the bar is lower. The description goes beyond them with genuinely useful semantics: money in minor units, totals segregated by currency, and the caveat that probabilities are stage/team estimates rather than calibrated predictions or verified revenue. That prevents real misinterpretation of the return payload.
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?
Three tight sentences, front-loaded with what is returned before the currency and probability caveats, then the prerequisite. No padding, though the prerequisite could arguably lead if it gates whether the tool is callable at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With seven parameters, 29% schema coverage, and no output schema, the description does well on entity and value semantics (money units, currency segregation, probability caveat) but leaves the majority of parameters undocumented, so an agent still cannot confidently use q, attention, limit, or offset. Adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (just scope and workspaceId), so the description carries the burden for q, limit, offset, currency, and attention. It adds nothing about any parameter, and notably omits that totals are split by currency and therefore that the currency filter matters for interpretation.
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?
States a specific verb+resource: reading CRM opportunities and company lifecycle data from the workspace. This clearly separates it from write-oriented siblings like save_opportunity and from get_company/get_workspace, though it does not explicitly acknowledge those near-neighbors.
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?
Gives one real precondition ('Requires the CRM feature'), which is useful gating context. However, it never says when to prefer this over get_company, get_workspace, or list_leads, and gives no exclusions or scope guidance, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_webhook_play_setupSet up HubSpot or webhook signupsARead-onlyIdempotentInspect
Read setup instructions for HubSpot form signups or a generic Webhook Play. Omit playId for creation links; pass it for the setup URL, relevant OAuth or webhook instructions, test steps, troubleshooting and up to five saved contacts. Explain one step at a time in plain language. Returns OAuth setup guidance for HubSpot, without claiming an existing connection or configuring HubSpot automatically. Never returns credentials, creates a Play, activates a sequence, enrolls or sends. Use this for connecting HubSpot/forms, testing signup intake, or diagnosing webhook setup.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| playId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description goes further by disclosing the payload shape (setup URL, OAuth/webhook instructions, test steps, troubleshooting, up to five saved contacts), the guarantee that no credentials are returned, and that it does not auto-configure HubSpot or claim an existing connection. Missing only auth-permission or rate-limit context to reach the top band.
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?
Front-loaded with the core action, then mode branches, then negative guarantees, then use cases — a logical order an agent can scan. It is a fairly dense block of prose with some overlap between the "never returns/creates" list and the closing use-case sentence, keeping it out of the 5 band.
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 2-parameter, read-only tool with no output schema, the description carries the return-content burden itself (setup URL, instructions, test steps, troubleshooting, saved contacts) and states the non-effects clearly. Nothing an agent needs to call it correctly 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 only 50%: workspaceId is documented in the schema, but playId has no description there. The description compensates by explaining the two playId modes (omitted vs. supplied) and what each returns, which meaningfully extends beyond the schema. It adds no format or UUID semantics, so not a 5.
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?
"Read setup instructions for HubSpot form signups or a generic Webhook Play" gives a concrete verb (read) and resource (setup instructions / Play setup data) plus the two supported channels. The closing sentence explicitly fences off what the tool is not (creates a Play, activates a sequence, enrolls or sends), so an agent can separate it from the mutating siblings like add_to_sequence or set_sequence_status.
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?
"Use this for connecting HubSpot/forms, testing signup intake, or diagnosing webhook setup" states clear trigger scenarios, and the playId branch (omit for creation links, pass for setup URL) tells the agent which mode to invoke. It never names a competing tool to prefer instead, so it stops short of full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workspaceWorkspace statusRead-onlyIdempotentInspect
Start here for account status. Read-only schemaVersion 2 summary: company, billing access, every saved LinkedIn/X/email/Instagram sender with separate connection, health and execution evidence, all Play types and sequence states, review coverage, period-labelled results, discovery allowance, excluded companies and the GTM profile (setup answers: proof, warm sources, ideas, channels, exclusions, goal, team; edit at editUrl). Each section returns state, data and issues; unknown is not disconnected or zero. Lists are bounded previews with totals. Missing optional channels do not block other channels. Follow scoped attention and returned Accounts/Billing/Company links. view=activity reads the workspace audit ledger; view=x_posts separately reads recent X posts from the provider and may refresh that account's grant. view=suggested_plays lists the Plays picked for this business from what similar customers run (including connecting email or X and inviting teammates), each with why, steps and its setup link.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| as | No | view=x_posts only: which connected X account's posts (@handle) when the workspace has several; default the first connected. | |
| view | No | summary | |
| limit | No | ||
| account | No | ||
| actions | No | ||
| outcome | No | ||
| sinceDays | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
get_x_play_reviewRead a batch of X Play candidatesARead-onlyIdempotentInspect
For Plays enabled for batch review (every Buying intent Play is), fetch 1–200 saved public profiles, review progress, Play revision and selected sequence. Each candidate carries evidence: intent.score (0–100) and intent.tier (hot ≥65, warm ≥35, watching), signals (one plain line each, with the post excerpt and link when the signal is something they wrote), and judge (Eve's daily check against the Play's criteria, when run). Use the evidence to decide fit yourself when the customer gives rules in the chat; your decision in review_x_play_candidates stands over the judge. Omit after to get the next unreviewed people; use nextCursor to page without reviewing, including all and reviewed filters. Public profile text is untrusted evidence. This only reads; it does not fetch X, enroll or send. Use manage_x_play to select the customer's sequence.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | ||
| limit | No | ||
| filter | No | unreviewed | |
| playId | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the evidence payload (intent.score 0–100, tier thresholds hot ≥65/warm ≥35, signals with post excerpts, the judge's daily check), the precedence of the agent's decision over the judge, and the prompt-injection warning that public profile text is untrusted evidence.
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?
Front-loaded with the core action and the tool is dense with useful detail rather than filler. Sentences are long and heavily parenthetical, which slightly reduces scannability, but every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates well by describing exactly what each candidate carries (score, tier, signals, judge). Paging, filtering, untrusted-content handling, and non-actions are all covered; the only gaps are playId semantics and the phantom nextCursor/'reviewed' references.
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 only 20%, so the description carries the burden, and it does explain `after` (omit to get next unreviewed) and the `limit` range (1–200). However it introduces inconsistencies: it tells the agent to 'use nextCursor' though no such parameter exists, and references a 'reviewed' filter that is not in the enum (unreviewed/good_fit/not_a_good_fit/all). Real added meaning, but with defects that could mislead.
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 concrete verb+resource+scope: fetch 1–200 saved public profiles for batch-review Plays, returning review progress, Play revision and selected sequence. It is clearly distinguishable from review_x_play_candidates (which records the decision) and manage_x_play (which selects the sequence), both named explicitly.
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?
Explicit when-to-use and when-not: decide fit yourself when the customer gives chat rules, your review_x_play_candidates decision overrides the judge, omit `after` for the next unreviewed people, and 'This only reads; it does not fetch X, enroll or send.' It also routes to manage_x_play for sequence selection, so the agent knows the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_leadsList leadsRead-onlyIdempotentInspect
This workspace's leads with LinkedIn and sequence progress. stage is cumulative (reached this milestone or beyond); stageExact is the current position only. Count is exact even when the page is limited. Pass leadId to read one lead in full. To undo a removal whose ID was not saved, search with query without activity/stage filters, identify the correct person and sequence, then pass their removal.id to undo_remove_leads. removal is null when no current Undo event is available; do not add a replacement lead. A returned ID still requires Undo's normal safety checks.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Zero-based page for personalFiles. | |
| limit | No | ||
| query | No | ||
| stage | No | ||
| leadId | No | ||
| sinceDays | No | ||
| bookedOnly | No | ||
| sequenceId | No | ||
| stageExact | No | ||
| strategyId | No | ||
| engagedOnly | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| personalFiles | No | With sequenceId: which file each person has for that sequence's per-person file step (for example their personalised video), 25 people a page: file name and size, and state waiting (no file yet), ready (attached, not sent), sent, or closed (not needed). query narrows by name, email, company or handle; waitingForInput=true lists only people still missing a file. Use it when the customer wants to check who got which file; appUrl opens the same table in the app, where each video can be watched. | |
| waitingForInput | No | Only people the engine is holding because a LinkedIn message, email, X DM or Instagram DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys (waitingForFiles names the ones that are a file for that person) and waitingSince. |
list_pending_repliesReplies waiting for a decisionARead-onlyIdempotentInspect
Inbound replies frozen for human review. Every item names its channel (linkedin, instagram, x). Items with an id carry PumpGTM's draft answer: decide them with decide_reply by that draftId (allowedDecisions lists what applies; X drafts accept everything but invite and send as a direct message on X). X items with no draft and no id (an encrypted reply PumpGTM could not read, or an older reply) are decided with decide_reply using their leadId, or answered in X at replyUrl. An X item with theirMessage null and messageUnavailable x_chat_passcode_required (or x_chat_passcode_changed) is an encrypted X Chat reply PumpGTM could not read: say so plainly, never guess or invent what they wrote, and tell the customer they can unlock it from their Inbox (unlockUrl) by entering their X Chat passcode once (x_chat_passcode_changed: the passcode changed in X and must be entered again). Never ask the customer for the passcode in this chat. Read-only.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered (and the trailing 'Read-only.' repeats it). The description adds real value beyond annotations: it discloses the shape of returned items and the special-case behaviors (drafts accept everything but invite/send on X; encrypted replies must not be guessed; never ask for the passcode).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the body is a single dense block that mixes this tool's semantics with extended decide_reply and X-Chat-passcode handling that arguably belongs to decide_reply's description. It is not padded, but it is hard to scan and over-weighted toward downstream actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry return-value meaning, and it does: channel, id/draftId, allowedDecisions, theirMessage/messageUnavailable, replyUrl, unlockUrl are all explained. The only gap is the undocumented limit parameter and no guidance on paging through results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: workspaceId is documented in the schema, but limit is undocumented anywhere. The description mentions neither parameter, so it does nothing to compensate for the gap on limit (bounds, default, pagination meaning) or to reinforce the teammate-workspace requirement.
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?
Names a specific verb and resource ('Inbound replies frozen for human review') and immediately scopes what each returned item contains (channel, id, draftId). An agent can distinguish it from list_leads, list_signal_events, and the decide_reply sibling without opening a schema.
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?
Gives explicit downstream routing: items with an id go to decide_reply by draftId, X items without a draft/id go to decide_reply by leadId or are answered at replyUrl, and encrypted X Chat items get a specific explanation path. It never states when to reach for this listing tool versus other listing siblings, but the 'frozen for human review' framing makes the trigger clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sequencesList sequencesARead-onlyIdempotentInspect
Sequences with executionModel, steps, approval state, status, and exact enrolled-lead counts. The compact list uses step index/message; pass sequenceId to read the full editable stepIndex/messageTmpl shape and exact revision before editing. Both shapes retain graph next/condition and X sendIf. Preserve those fields in a full replacement.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the two return shapes (index/message vs. stepIndex/messageTmpl), retention of graph next/condition and X sendIf, and the warning to 'Preserve those fields in a full replacement.' These are context the annotations cannot convey.
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?
Three front-loaded sentences: the first enumerates returned fields, the second distinguishes the two modes, the third gives the preservation caution. The field enumeration is dense but each sentence carries distinct information, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param, no-output-schema, read-only tool, the description covers return shape, the two read modes, and the editing caveat. Combined with the schema-provided workspaceId note, an agent has enough to call it correctly; only explicit sibling routing 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 only 50%: workspaceId is described in the schema, but sequenceId has no schema description. The description compensates by explaining exactly what sequenceId unlocks (full editable stepIndex/messageTmpl shape and exact revision), adding meaning beyond the raw UUID type.
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 name/verb 'list_sequences' plus the opening 'Sequences with executionModel, steps, approval state, status, and exact enrolled-lead counts' makes clear this returns sequence resources and their fields. It also distinguishes the two read modes (compact list vs. full editable shape). It does not, however, explicitly differentiate itself from sequence-related siblings like save_sequence_draft or set_sequence_status.
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?
It gives specific guidance for the sequenceId parameter ('pass sequenceId to read the full editable ... shape and exact revision before editing'), which is a real usage cue. But it offers no when-not-to-use and never names alternatives among the many sibling sequence tools, leaving the agent to infer the tool's place in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_signal_eventsRead signal eventsARead-onlyIdempotentInspect
Read source-linked hiring observations from PumpGTM's shared index. Default start=recent returns up to 30 days of observations; start=now returns a cursor for future observations. Save and reuse the returned cursor with the same filters to continue. Deduplicate downstream actions by eventId. No Energy charge or paid search; collection is demand-driven, not a scheduled company watch. Does not create leads or contact anyone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| limit | No | ||
| start | No | recent | |
| cursor | No | ||
| filters | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: no Energy charge, demand-driven rather than scheduled collection, deduplicate downstream by eventId, and it does not create leads or contact anyone.
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?
Four tight sentences covering behavior, cursor lifecycle, deduplication, and cost/side-effect profile, with the core action and default front-loaded. No filler, though the density is high and some sentences carry multiple ideas.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries some of the return-value burden, and it does mention eventId for deduplication. Still, for a 6-parameter tool with a nested filters object, the filter parameters are undocumented in both schema and description, leaving real gaps.
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?
With only 17% schema description coverage, the description must compensate, and it partially does: it explains the start enum values (recent=30 days, now=cursor) and cursor reuse semantics. However, limit, the nested filters (roles, companyDomains, min/maxHeadcount), and the name const are not explained; workspaceId is already documented in the schema.
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?
States a specific verb and resource: 'Read source-linked hiring observations from PumpGTM's shared index,' which concretely identifies the data domain. It does not explicitly differentiate itself from siblings like list_signal_types or record_customer_signal, so it falls short of the sibling-routing bar for a 5.
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?
Gives clear operational context: default start=recent returns up to 30 days, start=now returns a forward-looking cursor, and the cursor should be reused with the same filters to continue. It stops short of naming alternatives or stating when NOT to use this tool versus list_signal_types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_signal_typesList available signal typesARead-onlyIdempotentInspect
Discover the Signals API catalog. Only available types are callable. Coming-soon entries are roadmap categories, not event names or working subscriptions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine interpretation context: only available types are callable and coming-soon entries are roadmap categories rather than working subscriptions, which tells the agent how to read the results. It stops short of describing pagination or return shape, but adds real value beyond the annotations.
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?
Three tight sentences with no padding, front-loaded with what the tool does and immediately followed by the interpretation caveats. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries some burden of explaining results, and it does so by clarifying the available vs coming-soon distinction. Annotations cover the safety profile and the sole parameter is fully specified in the schema, so the definition is nearly complete; only return structure/pagination detail is absent.
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% and the single workspaceId parameter is fully documented in the schema (format, pattern, teammate-vs-own semantics). The description adds nothing about the parameter, so the baseline 3 applies since the schema does the heavy lifting.
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 frames the tool as discovering the 'Signals API catalog' and the title names the concrete resource (signal types). It distinguishes signal types from event names ('Coming-soon entries are roadmap categories, not event names'), which helps separate it from the sibling list_signal_events. The verb+resource is clear enough, though the body leans on the title rather than stating 'returns the list of signal types' outright.
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?
Usage is only implied: an agent infers you call this to find which types are callable before subscribing. There is no explicit when-to-use vs alternatives guidance and no mention of the sibling list_signal_events or record_customer_signal, which a reader would need to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_x_playRead, create or change an X PlayAInspect
List X Plays, get one Play's current revision and audience, create a Buying intent Play, or update a Play's name, audience rules, sequence, or running/paused state. Each Play's audience is described in plain words (audience.sources); show those to the customer, never the plan JSON. create makes a Buying intent Play from one signal: competitor_followers (people following several competitor X accounts), competitor_post_engagers (people replying to, quoting or reposting competitors' recent posts), asks (people asking X and/or LinkedIn for a tool like the customer's), complaints (people unhappy with a competitor on X and/or LinkedIn), or reddit (threads asking for what the customer sells, with a reply drafted for review). When the customer has not named competitors, suggest a few from the company profile and confirm before creating. Phrases are short buyer words ("best bank for a startup", "account frozen"), never the company's own marketing terms. criteria says who fits in one sentence; found people are checked against it. A Buying intent Play collects before X is connected and lists people for review; it never enrolls or messages anyone by itself. sequenceId (an X-lane or LinkedIn-lane sequence) or message (creates an approved active X DM sequence named after the Play) is optional. Discover a Play first; update requires expectedRevision. Unspecified fields stay unchanged. The sender stays fixed. For Plays on the account's own posts or followers, reach_post_engagers sets up a new source. Pausing a Play stops future audience collection, not messages already queued in its sequence; use set_sequence_status to stop those too when requested. Enabling automatic enrollment or resuming may start future outreach through the paced engine. Never connects accounts or sends directly.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Required for create, e.g. "Founders who follow our competitors". | |
| plan | No | ||
| action | Yes | Required: list to discover Plays; get to read one; create for a new Buying intent Play; update to apply an explicit change. | |
| playId | No | Required for get and update. Discover with action=list. | |
| signal | No | Required for create. competitor_followers: people following several competitor X accounts (competitors, minShared). competitor_post_engagers: people replying to, quoting or reposting the competitors' recent X posts (competitors, postsPerCompetitor). asks: people asking X and/or LinkedIn for a tool like the customer's (phrases, networks). complaints: people unhappy with a competitor on X and/or LinkedIn (phrases, competitors for X, competitorNames for LinkedIn). reddit: Reddit threads asking for what the customer sells, with a reply drafted for review (phrases, subreddits). | |
| status | No | ||
| message | No | create: the first X DM; creates an approved active X DM sequence named after the Play. Optional; use sequenceId instead to reuse one. | |
| phrases | No | asks, complaints, reddit: 1–10 short search phrases in the words a buyer would write, e.g. "best bank for a startup" or "account frozen". | |
| criteria | No | create: who fits, in one sentence, e.g. "Founders or finance leads at early-stage US startups". Found people are checked against it. | |
| networks | No | asks, complaints: where to search. Default ["x"]. | |
| minShared | No | competitor_followers: how many of the competitors a person must follow. Default 3, never more than the number of competitors. | |
| sequenceId | No | create: an existing sequence to attach (X lane, or LinkedIn lane for a Buying intent Play). Optional. | |
| subreddits | No | reddit: subreddits to prefer, as r/name or name. Threads elsewhere on Reddit still count; omit to search all of Reddit. | |
| competitors | No | Competitor X accounts as @handle, handle or x.com profile link. 2–10 for competitor_followers, 1–10 for competitor_post_engagers, optional for complaints (anchors the X search). | |
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| competitorNames | No | complaints on LinkedIn: competitor company names as written ("Mercury"), since LinkedIn posts name companies, not X handles. | |
| expectedRevision | No | Required for update. Copy the revision returned by list or get. | |
| postsPerCompetitor | No | competitor_post_engagers: newest posts read per competitor each day. Default 5. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this non-readOnly/non-destructive, and the description goes well beyond them: it explains that a Buying intent Play 'collects before X is connected and lists people for review; it never enrolls or messages anyone by itself', that pausing stops collection but not queued messages, and that resuming 'may start future outreach through the paced engine'. These are the exact side-effect semantics an agent needs for a mixed read/write tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action list, which is good, but it then becomes a dense run-on paragraph that repeats the per-signal definitions already present in the signal parameter schema. Much of it earns its place, yet there is clear redundancy and no structural separation for an 18-parameter tool.
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 complex, high-parameter tool with no output schema, the description covers actions, per-action prerequisites, side effects, alternatives, and even the customer-facing rule ('show those to the customer, never the plan JSON'). An agent has everything needed to select and invoke it correctly.
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 description coverage is 89%, so the baseline is 3, but the description adds conceptual framing the schema lacks: the five signal kinds are explained in plain language, phrases are characterized as 'short buyer words', and criteria is described as a one-sentence fit check. Minor redundancy with the schema's own signal enum text keeps it from a 5.
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 specific verbs (list, get, create, update) against a specific resource (X Plays), and enumerates what each action touches (current revision/audience, Buying intent Play, name/audience rules/sequence/state). It is immediately distinguishable from siblings like get_x_play_review or reach_post_engagers.
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?
Explicit prerequisites and routing: 'Discover a Play first; update requires expectedRevision', 'For Plays on the account's own posts or followers, reach_post_engagers sets up a new source', and 'use set_sequence_status to stop those too'. It also tells the agent to confirm competitors with the customer before creating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reach_post_engagersReach everyone who engaged with a LinkedIn or X postAInspect
LinkedIn profileUrl plus message explicitly follows that profile: check the latest 10 posts from the past 30 days every six hours and automatically enroll up to 500 new engagers per collection. Only use profileUrl when the customer requests recurring outreach. LinkedIn post URL plus message: PumpGTM creates a Play with its own approved sequence (note-less connection request, then your message), fetches every reactor and commenter in the background (up to 500), and enrolls all of them; call again with only playId for progress. X post URL (x.com/…/status/…) plus message, or plus an existing X sequenceId: creates a real X Play, its audience rules and collection source, and returns its Play link. X defaults to review before enrollment; select engagements when the customer wants only likes or replies. The customer adds selected people to the X sequence (or with add_to_sequence). followers=true instead of a post URL creates a new-followers X Play. A supplied Sequence keeps its status; a message creates an approved active Sequence. Existing shared sources retain their status, Sequence and collection progress. Report polling blockers and paused Sequences exactly as returned; do not promise polling or sending while blocked. Follower Plays can still receive incoming X follow events while fallback polling is blocked. Use manage_x_play to inspect/edit the returned X Play, including enabling autopilot only when the customer requests automatic enrollment. watchId alone checks source/Sequence progress. The X call itself never enrolls or sends.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| as | No | X only: which connected account's post or followers (@handle) when the workspace has several; default the first connected. | |
| name | No | ||
| playId | No | ||
| message | No | ||
| postUrl | No | ||
| watchId | No | ||
| followers | No | X only: collect the account's new followers for review instead of a post's engagers. | |
| profileUrl | No | LinkedIn only: explicitly follow this personal profile's latest posts and automatically enroll new reactors and commenters every six hours. Use with message instead of postUrl. | |
| sequenceId | No | X posts only: an existing X DM sequence instead of a new one from message. | |
| engagements | No | X posts only: liked for likes, replied for replies, both when the customer requests all engagers. Defaults to both. | |
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say non-readonly, non-destructive, non-idempotent; the description adds the 500-engager cap, six-hour polling, approval defaults, paused sequences, and that X calls never enroll. It notes polling blockers and fallback behavior, which is valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single massive paragraph with no structure, run-on sentences, and extensive detail. It is not front-loaded; the agent must parse through many clauses to find key routing logic. This hurts readability and quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, no output schema, multi-platform), the description covers the major behaviors, branching, and limitations well. Minor gaps remain regarding error handling or exact return shape, but it is largely complete.
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 55%, so the description must compensate. It explains profileUrl, message, postUrl, playId, watchId, followers, engagements, and sequenceId semantics well, though it doesn't clarify the optional 'name' or 'as' beyond what the schema already states.
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 names a specific verb (reach) and resource (post engagers) and distinguishes between LinkedIn and X paths with detailed branching. It is clear what the tool does, though the density and lack of a concise opening sentence reduce immediate clarity.
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?
Explicit conditions are given for using profileUrl (recurring outreach only), for X engagements vs all, and for followers=true, with references to manage_x_play and watchId. However, it doesn't fully compare against add_to_sequence or other alternatives for enrolling contacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reach_universeTake universe people into an email campaign or a LinkedIn sequenceAInspect
Pick people from the account universe (by competitor name, playId, or exact candidateIds; notYetEnrolled skips anyone already in LinkedIn outreach) and reach them on one channel. channel=email puts everyone with a known email into one of the workspace's own email campaigns, either campaignId or a new draft named campaignName, and may set the campaign's steps (plain text, {{firstName}} {{company}} {{title}} placeholders, delayDays between steps), schedule, sending mailboxIds (or allMailboxes), and dailyLimit in the same call; people without an email are skipped, and findEmails=true first looks up missing addresses, up to maxEmailLookups and a daily limit. channel=linkedin enrolls them into an active approved sequence by sequenceId through the ordinary paced engine. Nothing is launched or sent in this call.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| steps | No | ||
| playId | No | ||
| channel | Yes | ||
| schedule | No | ||
| campaignId | No | ||
| competitor | No | ||
| dailyLimit | No | ||
| findEmails | No | ||
| mailboxIds | No | ||
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| allMailboxes | No | ||
| campaignName | No | ||
| candidateIds | No | ||
| notYetEnrolled | No | ||
| maxEmailLookups | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses that people without an email are skipped, that findEmails triggers lookups bounded by maxEmailLookups and a daily limit, that LinkedIn enrollment uses the paced engine against an approved sequence, that campaign steps/schedule/mailboxes can be configured in the same call, and crucially that nothing is launched or sent here. This is exactly the mutation-effect context the annotations do not carry.
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?
Front-loaded with the selection rule and channel split, and dense with substance rather than filler. It is a single long paragraph that would benefit from tighter segmentation, but each clause earns its place for a 16-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a highly complex 16-param, no-output-schema tool, the description covers selection, both channel modes, and the no-send caveat. It omits what the call returns (e.g. enrolled/skipped counts) and error/failure conditions, which are the only meaningful remaining gaps.
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 only 6%, so the description must compensate, and it does: it explains competitor/playId/candidateIds selection, notYetEnrolled's skip semantics, campaignId vs a new campaignName draft, the steps fields (plain text, {{firstName}} {{company}} {{title}} placeholders, delayDays), schedule, mailboxIds/allMailboxes, dailyLimit, sequenceId, and findEmails/maxEmailLookups. Nearly every non-trivial parameter gains meaning beyond the bare 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 ('Pick people ... and reach them'), the exact resource pool (the account universe), the selection axes (competitor name, playId, or candidateIds), and the two distinct behaviors keyed on channel. An agent can tell this apart from reach_post_engagers or add_to_sequence purely from the description.
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?
Gives clear operating context: exactly one channel per call, channel=email routes to an email campaign while channel=linkedin enrolls into an active approved sequence. It does not, however, name sibling alternatives or state when to prefer this tool over add_to_sequence/reach_post_engagers, so selection between siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_customer_signalRecord customer signalAInspect
Append a dated note, meeting, reply, product engagement, risk, or milestone, with its source link. Use evidence, not assumptions. Source names are attribution, not provider verification. Does not read a provider or send to Slack. A note never refreshes contact recency.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| body | Yes | ||
| kind | Yes | ||
| title | Yes | ||
| source | Yes | ||
| company_id | Yes | ||
| source_url | Yes | ||
| occurred_at | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it's a write (readOnlyHint=false) and not idempotent. The description adds valuable side-effect context: it explicitly states it does NOT read a provider or send to Slack, and that 'A note never refreshes contact recency' — these are non-obvious behaviors that prevent user confusion. It stops short of detailing permissions or rate limits.
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?
Very concise: five short sentences that pack substantial value, each addressing a distinct aspect (what, evidence quality, source semantics, non-effects, recency caveat). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-param write tool with no output schema, the description covers the key behavioral surprises and quality guidance. It leaves some parameter details (e.g., occurred_at format, workspaceId handling) to the schema, which is reasonable, but with low schema coverage it could say more about required fields like body nullability.
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 only 11%, so the burden falls on the description. It lists the signal kinds (matching the kind enum) and source link, and clarifies source attribution semantics, but it does not explain occurred_at, company_id, title/body limits, or the optional workspaceId. Baseline 3 is appropriate given partial enum coverage but significant gaps.
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 clearly states the tool appends a dated note/meeting/reply/engagement/risk/milestone with a source link, and enumerates the supported kinds, which matches the kind enum in the schema. It does not explicitly differentiate from list_signal_events, but the write verb 'Append' makes the create-vs-read distinction intuitive against the 'list_' sibling.
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 description offers a quality constraint ('Use evidence, not assumptions') and a caveat about attribution ('Source names are attribution, not provider verification'), which guides proper usage. However, it does not say when to use this vs. list_signal_events or add_company_contact, nor does it specify preconditions like required company existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_leadsRemove or stop leadsDestructiveIdempotentInspect
Only when the customer explicitly asks to undo an add or stop leads. Target lead IDs, one batchId from add_leads, or target=companies with employer names: those go on the workspace do-not-contact list (shown in get_workspace), every Play stops finding people there, no lead at those employers is ever added again, and everyone already queued there is removed. Uncontacted leads leave the queue; contacted leads keep history and get no further automated steps. Sent invitations and messages cannot be reversed. Returns removal IDs for undo_remove_leads. Removed people stay out of Play review and ordinary imports until explicitly restored.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
research_competitorResearch a competitor's customersAInspect
With websiteUrl and competitorName: read that site's public case studies in the background and add every named customer account and quoted person to the account universe, each cited to its source page; optional roles retrieve a broad pool of current employees, then product-aware AI keeps the strongest evidence-backed people for review. Uses the workspace's company or its active Team's shared company. If neither exists, ask the customer to add their own company website at the returned setupUrl, then retry. Supply productBrief when the Play promotes a different product. Without websiteUrl and competitorName: list the sourced account universe (optional playId narrows to one competitor and reports research status). Review material only; enrolls and contacts no one.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| roles | No | ||
| playId | No | ||
| websiteUrl | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| productBrief | No | ||
| competitorName | No | ||
| maxCaseStudies | No | ||
| maxPeopleTotal | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, and the description is consistent with them (it writes accounts/people to the universe while explicitly stating 'Review material only; enrolls and contacts no one'). It adds useful behavioral context the annotations lack: background execution, source-page citation, workspace/Team company resolution, and the setupUrl fallback. It stops short of describing run duration or rate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries meaning (no filler), but the first sentence is a sprawling semicolon-chained run-on that mixes both modes and several side effects, making it hard to parse quickly. Front-loading the two-mode structure would improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, dual-mode tool with no output schema and no required params, the description covers modes, prerequisites, workspace resolution, side effects, and the non-enrollment reassurance. The remaining gaps are the numeric bounding parameters, which the schema names but does not explain.
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 only 11% schema description coverage, the description carries most of the param burden and largely succeeds: it explains websiteUrl, competitorName, playId (narrowing the listing and reporting status), roles, productBrief, and the workspace company fallback. It leaves limit, maxCaseStudies, and maxPeopleTotal unaddressed, which are relevant for a bounded list tool.
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?
States a specific verb and resource (research a competitor's public case studies and add named accounts/people to the account universe) and clearly delineates its two modes via the websiteUrl+competitorName switch. It does not name or differentiate itself from any sibling (e.g. reach_universe, review_people, find_people), so an agent must infer its niche from the text alone.
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?
It spells out the two invocation modes and their conditions, the prerequisite when no workspace company exists (ask the customer to add a site at setupUrl and retry), and the conditional case for productBrief when the Play promotes a different product. No explicit alternative tools or when-not-to-use guidance is given, keeping it shy of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_peopleReview found peopleAIdempotentInspect
Without decisions: read one review batch with its candidates and saved choices. With decisions: record the customer's explicit good_fit and not_a_fit choices; a top-level sequenceId applies to every good fit, finish=true completes the review and queues good fits into the sequence. For add all, mark every candidate good_fit with finish=true. Sends nothing in this call. Open world: people queued into a live sequence are later contacted by its paced steps.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| finish | No | ||
| batchId | Yes | ||
| decisions | No | ||
| requestId | No | Required with decisions. | |
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds the crucial clarification that 'Sends nothing in this call' despite the write path, explains what finish=true actually does (completes the review, queues good fits into the sequence), and warns that queued people are later contacted by paced steps — real behavioral context beyond the hints.
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?
Front-loaded mode split ('Without decisions… With decisions…'), then the sequencing/finish semantics, then the no-send guarantee and open-world consequence. Every sentence carries distinct information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter dual-mode tool with no output schema, the description covers the read return (batch with candidates and saved choices) and the write side effects well. Minor gaps remain: requestId's conditional requirement and the feedback fields are only discoverable from the schema.
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 description coverage is only 33%, so the description must carry weight, and it does for the non-obvious cases: the top-level sequenceId applies to every good fit, finish=true completes the review, and decision values are good_fit/not_a_fit. It stays silent on requestId's 'required with decisions' rule, workspaceId, and feedbackNote/feedbackReason, so it does not fully compensate.
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 resource (a review batch of found people with its candidates and saved choices) and splits the tool's two modes by verb: read a batch when no decisions are supplied, record good_fit/not_a_fit decisions when they are. This is enough to separate it from siblings like review_x_play_candidates or add_to_sequence without opening any schema.
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?
Explicitly tells the agent which mode to pick based on whether decisions are present, and gives the concrete 'add all' recipe (mark every candidate good_fit with finish=true). It does not name alternative tools (add_to_sequence, add_leads, review_x_play_candidates) or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
review_x_play_candidatesReview an X Play batch and enroll good fitsAIdempotentInspect
Save explicit customer fit choices, or apply criteria the customer authorized, to up to 200 candidates read from get_x_play_review. Put the reason for each decision in note (one short sentence); it is kept on the person like Eve's own verdict. Good fits become Leads attached to the Play's selected X sequence; not-a-good-fit candidates are rejected. Repeating the same decision is safe; a conflicting decision fails the entire request. Existing leads keep their assignments. Supply the revisions and sequence returned by the read. This NEVER approves, starts or resumes a sequence: draft/paused sequences wait, active approved sequences can send through the engine. Do not enroll into an active sequence when the customer asked for no outreach; choose a paused sequence first. Omit uncertain people and report them rather than inventing a fit. Read the next unreviewed batch after saving.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| playId | Yes | ||
| decisions | Yes | ||
| sequenceId | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| expectedRevision | Yes | ||
| sequenceRevision | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing atomicity ('a conflicting decision fails the entire request'), preservation rules ('Existing leads keep their assignments'), and the critical boundary that it NEVER approves, starts or resumes a sequence. The idempotency and non-destructive safety profile are already covered by annotations, so this is additive rather than redundant, though the return behavior after a conflict is left unspecified.
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?
Purpose is front-loaded and each sentence carries operational content (atomicity, boundary, sequencing, exclusions). It is dense and long but nearly every clause earns its place; only the 'Eve's own verdict' phrasing is decorative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-read-only, revision-guarded batch mutation with no output schema, the description covers safety boundary, conflict behavior, idempotency and next-step sequencing. It lacks detail on what a successful save returns, but the essential call-time context is present.
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 schema description coverage at only 17%, the description compensates well: it explains note's format and purpose, and that the revisions and sequence must be supplied 'returned by the read' (covering expectedRevision/sequenceRevision concurrency semantics). playId and workspaceId are only weakly implied, keeping it short of a 5.
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 ('Save explicit customer fit choices ... to up to 200 candidates') and explicitly scopes it against the sibling reader get_x_play_review. An agent can distinguish this write tool from the read tool without opening either schema.
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?
Gives explicit when/when-not guidance: do not enroll into an active sequence when the customer asked for no outreach, choose a paused sequence, omit uncertain people, and read the next batch after saving. It also names the prerequisite read tool get_x_play_review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_companySave CRM companyAInspect
Create or revise a CRM company and its customer success plan. Use a new UUID and expected_revision=0 to create; use the current revision to edit. Lifecycle is your team's assessment; active never means Stripe-verified. Do not invent customer status. Does not send, enroll, or bill anyone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| name | Yes | ||
| owner | Yes | ||
| domain | Yes | ||
| lifecycle | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| success_plan | Yes | ||
| next_review_on | Yes | ||
| expected_revision | Yes |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering only read-only/destructive/idempotency flags, the description adds the substantive behavior: optimistic-concurrency semantics via expected_revision, the meaning of the lifecycle field ('your team's assessment; active never means Stripe-verified'), and explicit side-effect exclusions (does not send, enroll, or bill anyone). This is exactly the context an agent cannot get from the annotations.
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?
Four dense sentences, front-loaded with purpose, then the create/edit rule, then semantics warnings, then side-effect boundaries. No filler; the two lifecycle/status sentences overlap slightly but each adds a distinct guardrail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter mutation tool with no output schema and near-zero schema description coverage, the description covers the risky parts well (concurrency, side effects, lifecycle interpretation) but leaves the agent guessing on several required fields (owner, domain, next_review_on) and on what happens when a stale revision is supplied.
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 only 11% (only workspaceId documented), so the description must compensate. It does explain expected_revision's dual create/edit role and clarifies lifecycle's semantics, but name, domain, owner, owner, next_review_on and success_plan format expectations remain undocumented in both schema and description.
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?
Specific verb+resource (create or revise a CRM company and its customer success plan), clearly distinguishable from siblings like get_company, add_company_contact and save_opportunity. The description also delimits scope by stating what it does not do (send, enroll, bill).
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?
Gives an explicit rule for create vs edit (new UUID plus expected_revision=0 for creation, current revision for edits) and a constraint on what may be entered ('Do not invent customer status'). It does not name alternative tools for adjacent tasks, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_opportunitySave opportunityAInspect
Create or revise a deal for an existing CRM company. Ask for missing value/currency; null value means unknown. Use a new UUID/revision=0 to create, otherwise current revision. Stage does not change outreach or company lifecycle. Won means recorded won, not paid. Only set probability_override when the user supplies an estimate.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| stage | Yes | ||
| title | Yes | ||
| currency | Yes | ||
| next_step | Yes | ||
| company_id | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| amount_minor | Yes | ||
| next_step_due_on | Yes | ||
| expected_close_on | Yes | ||
| expected_revision | Yes | ||
| probability_override | Yes |
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the mutation/safety profile (readOnly false, destructive false, idempotent false), so the description carries the semantic burden and delivers: stage does not alter outreach or company lifecycle, 'won' means recorded won rather than paid, and null means unknown. It does not mention what a revision conflict returns or any permission requirement, which are the remaining gaps for an upsert tool.
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?
Six short, dense sentences with the core purpose front-loaded and no filler; every clause carries a rule. The telegraphic style ('null value means unknown', 'Won means recorded won, not paid') is efficient but occasionally terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-required-parameter mutation with no output schema, the description focuses on semantics but leaves substantial parameter and workflow information implicit. Most notably, with optimistic concurrency via expected_revision, an agent is not told what the call returns (e.g. the new revision to use next), which matters for chained saves.
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 only 8% (just workspaceId), and 11 of 12 parameters are required with no schema docs. The description compensates for some: amount_minor null = unknown, currency should be solicited, expected_revision 0 means create, probability_override is gated. It says nothing about title, company_id, the stage enum values, next_step, or the two date fields, so the gap is only partially closed.
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 first sentence names a specific verb pair (create or revise) and resource (a deal for an existing CRM company), and the 'existing CRM company' qualifier distinguishes it from save_company and the lead-oriented siblings. It is clear what the tool does, though it never names a sibling tool to contrast against.
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?
Gives concrete when-to-use rules: create with a new UUID and revision=0, otherwise use the current revision; ask for missing value/currency; only set probability_override when the user supplies an estimate. These are real decision rules with conditions attached, but there are no explicit exclusions or named alternatives for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_sequence_draftCreate or edit a sequence draftIdempotentInspect
Without sequenceId: create a complete new sequence (name plus ordered steps); the customer's request is the approval, so it is approved and live when this returns. With sequenceId and expectedRevision: read the full sequence first, then replace its complete step list using that exact revision, preserving next, condition, sendIf and other unchanged fields. The new revision is approved and returns to its previous status (active stays active, paused stays paused, a draft goes live). Omitted executionModel keeps the saved model on edit. Graphs allow up to 30 steps; linear/tracks allow 20. In a graph, a LinkedIn message or endorsement must come after a connection request and an 'Accepted?' (linkedin_accepted) or 'Already connected?' (linkedin_first_degree) Yes path; view, like and comment need no connection. Steps include connect, message, engage (LinkedIn), email (subject plus body), x_dm and x_engage; Instagram DMs run only in their own linear sequence. Linear sequences using LinkedIn must start with connect, and linear X sequences cannot mix other channels. Tracks use separate channel lanes. Graphs can mix LinkedIn, email and X, start with email or X, and branch with next/condition; connect need not be first. Once any lead has left graph step 0, changing step count, kinds, edges or conditions is refused; copy and delay edits remain possible with the structure preserved. Before graph outreach, automatic reply safety checks previously contacted email, LinkedIn and X conversations: a human reply stops the flow and unavailable evidence holds it, independently of xThreadCheck. {{firstName}} {{fullName}} {{company}} {{title}} render across channels. {{ai_intro}} (message and email steps) is a one-sentence opener Eve writes for each person from their role and recent LinkedIn posts when they reach that step, saved for later steps, costing 0.1 Energy per person; when it cannot be written it renders its plain-text |fallback, or 'Hope your week is going well.' without one, so put it on its own line. A message step may also carry a per-person value the customer supplies later (for example {{video_url}}); declare it with tool { kind: "customer_input", tokens: [...] } and the step holds each person until set_lead_input stores the value. Nothing is sent in this call; enrolled people enter the paced queue. Give the customer the result's reviewUrl to review or pause the sequence. Open world: an active saved sequence contacts enrolled people, who are third parties.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| steps | Yes | Complete replacement, not a patch: 1–30 graph steps or 1–20 linear/tracks steps. Read the full sequence before editing and retain unchanged routing and sendIf fields. | |
| requestId | Yes | Stable idempotency key; reuse it only to retry this exact request. | |
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| xThreadCheck | No | Workspace-wide optional X conversation check. true checks for prior conversations before X outreach (5 Energy per DM instead of 0.6); false is the default. Omit to keep the current setting. This is separate from automatic graph reply safety: setting false never disables checks for replies to previously contacted graph conversations, including before switching to LinkedIn or email. | |
| executionModel | No | linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; a LinkedIn message or endorsement must come after a connection request and an 'Accepted?' (linkedin_accepted) or 'Already connected?' (linkedin_first_degree) Yes path; view, like and comment need no connection; missing email or X identity skips that channel's action. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress. | |
| expectedRevision | No |
search_known_peopleSearch previously observed professional profilesARead-onlyIdempotentInspect
Search a company, professional role, or explicitly stated accelerator cohort in permitted shared professional evidence. Returns at most 20 matching identities; coverage is incomplete and includes labelled historical roles and interpretations. This is not a live provider search, does not expose other customers' lists or messages, and does not authorize outreach. Check source dates before recommending someone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: caps results at 20 identities, warns that coverage is incomplete, notes inclusion of labelled historical roles and interpretations, and clarifies it is not a live provider search and does not authorize outreach. This is exactly the extra behavioral context a read-only search needs.
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?
Front-loads the purpose before the caveats, and each sentence adds a distinct constraint rather than restating. Dense but every clause carries information; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with no output schema, the description covers result cardinality, coverage limitations, and data provenance. It stops short of describing pagination or the exact shape of a result record, but those are minor for a 20-item capped search.
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 50% (query is undocumented in the schema), and the description compensates by explaining that query targets a company, professional role, or explicitly stated accelerator cohort. workspaceId is fully documented in the schema itself, so the loop is closed.
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?
States a specific verb (Search) and the kinds of things searched over (company, professional role, accelerator cohort) and explicitly distinguishes itself from a live provider search, which helps separate it from siblings like find_people. It never names a sibling directly, but the 'not a live provider search' contrast makes its niche legible.
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?
Gives exclusions (not live provider search, does not expose other customers' data, does not authorize outreach) and a usage instruction ('Check source dates before recommending someone'). No alternative tool is named, so routing to the right sibling still requires inference, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sequence_email_settingsRead or configure sequence email sendersAIdempotentInspect
Read a sequence's email sending inboxes, schedule, daily limit and unsubscribeFooter (adds a visible unsubscribe line; off by default; omit to keep it). The response also reports read-only plainTextEmail from the workspace's Accounts sending rules. When true, workspace plain-text mode overrides the footer and removes automatic unsubscribe headers, HTML formatting and tracking; it cannot be changed through sequence settings. Otherwise List-Unsubscribe headers are sent. Supply settings to replace sequence preferences using this workspace's cold outreach mailboxes. Does not change sequence status or send immediately; an active sequence can send on its next paced tick. Paused or disconnected inboxes remain paused or disconnected. No Energy charge.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| settings | No | ||
| sequenceId | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations (readOnlyHint/idempotentHint/destructiveHint) by disclosing that unsubscribeFooter is off by default and omitted means unchanged, that plainTextEmail is read-only and overrides the footer/tracking, that List-Unsubscribe headers otherwise apply, that pacing continues on next tick, and that there is no Energy charge. Rich, non-obvious behavioral context for a mutation tool.
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?
Front-loaded with the read behavior before the write behavior, and each sentence carries distinct information (footer semantics, plainTextEmail override, non-effects, no Energy charge). Slightly dense with several clauses packed into single sentences, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested, dual read/write tool with no output schema and 33% param coverage, the description covers behavior, side effects, and read-only fields well. The remaining gap is the nested settings sub-fields (schedule/mailboxIds/dailyLimit), which are left entirely to the schema.
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 coverage is low (33%) with a required nested settings object (mailboxIds, schedule, dailyLimit), and the description does not explain those nested fields. It does add semantics for unsubscribeFooter ('adds a visible unsubscribe line; off by default; omit to keep it'), which is genuinely beyond the schema, partially compensating for the gap.
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 (read) and resource (sequence's email sending inboxes, schedule, daily limit, unsubscribeFooter), plus the write mode ('Supply settings to replace sequence preferences'). It explicitly distinguishes from set_sequence_status ('Does not change sequence status') and from send actions ('or send immediately'), so an agent can route correctly without opening the schema.
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?
Clear read-vs-write condition is stated: omit settings to read, supply settings to replace. It also clarifies what it will NOT do (change status, send immediately) and notes paused/disconnected inboxes stay that way. It doesn't name a specific sibling alternative for replacing settings, but the boundary conditions are well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_lead_inputStore a per-person value or file for a held messageIdempotentInspect
Store a value the customer supplies for one person, such as a link to a video they recorded, so a LinkedIn message, email, X DM or Instagram DM step declared with tool customer_input can send. Identify the person by exactly one of leadId, LinkedIn profile URL, email address or X handle. values maps the sequence's token names (for example video_url) to the customer's text; the key comes from the sequence, the customer never types it. One call fills every step of that person's sequence that uses the token and has not sent yet. A LinkedIn message, opted-in email or X DM step may instead ask for a file for each person (tool customer_input attachment, for example a personalised demo video). Limits are the providers': LinkedIn 15 MB per message together with the step's own files; email one document, image or MP4 up to 18 MB (1.5 MB from Microsoft mailboxes); X one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds. Nothing is compressed: a larger file is refused with the limit and the way forward, which you relay as written (compress it and try again, or send a video link instead). A link to a video (Loom, YouTube, Drive) is a text value such as video_url, not a file. To send a file, call once with upload { key, fileName, size } to get a one-time uploadUrl, PUT the file's bytes there with the returned headers, then call again with files { key: uploadTicket }; if you cannot upload bytes yourself, give the customer the returned appUrl to add the file in the app instead. For several people at once (the customer has already decided which file is whose; do not second-guess their pairing), call with uploads [{ leadId or linkedinUrl or email or xUsername, key, fileName, size }] (up to 25, no top-level person) to get one uploadUrl and uploadTicket per person, PUT each file, then call with confirmUploads [uploadTicket, ...] to attach them all. Each person succeeds or is refused on their own with a reason; tickets last two hours and confirming one again is harmless, so a rerun only adds what is missing. Afterwards list_leads with sequenceId and personalFiles=true shows which file each person has. Nothing is sent in this call: the paced engine sends on its next run if the person is at that step, or when they reach it. A value or file for someone who already replied, finished, or already received that message is refused with nothing changed. The result includes how many people in that sequence are still waiting. Open world: the stored value releases a held message to that person, a third party.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| No | The person's email address, for someone reached by email. | ||
| files | No | The file slot's key mapped to the uploadTicket returned by a previous upload call, after the bytes were uploaded. | |
| leadId | No | ||
| upload | No | Ask for a one-time upload link for this person's file. Stores nothing. | |
| values | No | ||
| uploads | No | Several people's files at once: one upload link per person. Stores nothing. Use instead of a top-level person. | |
| requestId | Yes | Stable idempotency key; reuse it only to retry this exact request. | |
| xUsername | No | The person's X handle, with or without @, for someone reached on X. | |
| linkedinUrl | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| confirmUploads | No | The uploadTickets from an uploads call, after each file's bytes were PUT; attaches each to its person. Use instead of a top-level person. |
set_sequence_statusPause, resume, reopen, or approve a sequence or an email campaignAIdempotentInspect
For a LinkedIn sequence (sequenceId): paused stops it for every enrolled lead, active resumes a paused sequence, draft reopens it for editing in the dashboard. status=approved (expectedRevision required) is only for a sequence that is still a draft, for example one created in the dashboard: it records the customer's approval of that exact revision and makes it live in the same call. Sequences created or edited with save_sequence_draft, and drafts people were added to over MCP, are already live and need no approval here. For an email campaign (emailCampaignId): active launches sending inside its schedule and limits, paused stops it, draft reopens it; approved does not apply. Open world: active or approved lets PumpGTM's paced engine send connection requests, messages and emails to the enrolled people, who are third parties.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| sequenceId | No | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. | |
| emailCampaignId | No | ||
| expectedRevision | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, idempotent, open-world, non-destructive, but the description adds the crucial context they cannot express: active/approved makes PumpGTM's paced engine send connection requests, messages and emails to enrolled third parties, and that approved records approval of an exact revision and makes it live in the same call. This is meaningful side-effect disclosure beyond the hints.
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?
Front-loads the sequence case and each sentence carries non-redundant information, but the paragraph is dense and run-on, packing several distinct rules into long compound sentences. Efficient in content, slightly heavy in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and for an open-world state mutation the description covers the effects, the approval guardrail, and resource routing. It stops short of explaining what happens to paused enrolled leads on resume or what the call returns, leaving modest gaps for a mutating tool.
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 description coverage is only 20%, so the description must compensate, and it largely does: it explains the semantics of every status value, which id (sequenceId vs emailCampaignId) applies to which resource, and that expectedRevision is mandatory for approved. It does not, however, state that sequenceId and emailCampaignId are mutually exclusive or clarify expectedRevision's revision-checking behavior.
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 (set status) and a specific dual resource (LinkedIn sequence vs email campaign), then maps each enum value to its concrete effect per resource type. It also distinguishes itself from the sibling save_sequence_draft by naming what that tool already accomplishes.
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 states when each status applies and when it does not: 'approved' only for still-draft sequences and requires expectedRevision, is not applicable to email campaigns, and is unnecessary for sequences created/edited with save_sequence_draft or drafts people were added to over MCP. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
undo_remove_leadsUndo lead removalIdempotentInspect
Only when the customer explicitly asks to undo a removal. Pass exact removalIds from remove_leads or list_leads removal.id. Restores the same lead in its original sequence with its progress; paused sequences stay paused. No copy is created and this call sends nothing. Replies, opt-outs, changed sequences, overlapping outreach and unconfirmed sends can block restoration; explain each returned reason. Retrying the same removal IDs is safe and cannot undo a later removal. Company exclusions and cancelled imports are not reversed. Open world: restored outreach may later contact these people through the ordinary paced engine.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| removalIds | Yes | Exact removal IDs from remove_leads or the lead's removal field. Reuse these IDs for retries. | |
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
x_accountAct as the connected X accountAInspect
One action from a connected X account: follow or unfollow a profile (target is an X profile URL or @handle), or like or repost one post (target is an X post URL). as picks which connected account acts when the workspace has several (get_workspace view=x_posts lists them); default is the first connected. Needs the X channel. Unfollow only when requested by the customer. It never sends a DM or writes a new post.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| as | No | ||
| action | Yes | ||
| target | Yes | ||
| workspaceId | No | A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it is a non-read-only, open-world, non-idempotent, non-destructive action; the description adds value beyond that by disclosing the X-channel prerequisite, the multi-account resolution rule and default, and hard boundaries ('never sends a DM or writes a new post'). It does not discuss rate limits or failure/partial-success behavior, which is a minor gap.
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?
Dense but front-loaded: the action/target model comes first, then account selection, then prerequisites and exclusions. Most sentences earn their place, though the final boundary sentence could be folded into the earlier enumeration for tighter flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, no-output-schema mutation tool, the description covers prerequisites, multi-account targeting, and explicit non-capabilities, which is enough for correct invocation. Missing only operational details like rate limiting or error semantics, which are secondary here.
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 only 25% (only workspaceId is documented), so the description must carry the load and largely does: it explains that `as` selects the acting connected account (default first, where to list them) and that `target` is an X profile URL/@handle or post URL depending on action. The `action` enum values are self-explanatory from the schema, so no further compensation is needed.
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?
Names the specific verb set and resource: one action (follow/unfollow/like/repost) from a connected X account, with the target type spelled out per action (X profile URL/@handle vs X post URL). An agent can distinguish this from siblings like manage_x_play or get_x_play_review without opening the schema.
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?
Gives clear context and one explicit exclusion ('Unfollow only when requested by the customer') plus the prerequisite ('Needs the X channel') and how to enumerate accounts (get_workspace view=x_posts). It does not explicitly name an alternative tool for related X play operations, but the when-to-use conditions are otherwise unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
energy2 fields changed- changed
Input schema / properties / autoTopUp / descriptionPrevious value: -"true authorizes recurring $10 card charges for 100 Energy whenever the balance falls below 50; obtain explicit customer consent to those terms first. false turns it off. Send it with buy to get the payment link and turn top-up on in one call."New value: +"true authorizes recurring $10 card charges for 75 Energy whenever the balance falls below 50; obtain explicit customer consent to those terms first. false turns it off. Send it with buy to get the payment link and turn top-up on in one call." - changed
Input schema / properties / buy / properties / packs / descriptionPrevious value: -"Packs to buy; each pack is $10 for 100 Energy. The billing page offers 1 ($10), 5 ($50), 10 ($100), 25 ($250), 50 ($500)."New value: +"Packs to buy; each pack is $10 for 75 Energy, or 100 Energy each when buying 5 or more. The billing page offers 1 ($10), 5 ($50), 10 ($100), 25 ($250), 50 ($500)."
- Changed
get_workspace2 fields changed- changed
Input schema / properties / actions / items / enumPrevious value: -[ - "resolve", - "invite", - "invite_withdrawn", - "accepted", - "like", - "message", - "followup", - "reply_detected", - "view_profile", - "endorse", - "comment", - "tool_prepare", - "enrich", - "meeting_invited", - "reply_drafted", - "reply_sent", - "reply_dismissed", - "reply_snoozed", - "sequence_started", - "sequence_contact", - "sequence_contact_attempt", - "sequence_contact_cancelled", - "reply_check", - "sequence_stopped", - "meeting_booked", - "meeting_no_show", - "meeting_synced", - "manual_override", - "x_dm", - "x_follow", - "x_like", - "x_follow_back", - "x_unfollow", - "x_repost", - "x_lookup_cached", - "memory_search", - "x_follow_back_scan", - "x_credit_balance", - "x_reply_subscription", - "x_follow_event", - "x_auto_accept", - "instagram_dm", - "instagram_comment", - "instagram_unlock", - "track_unavailable", - "track_done", - "ad_campaign_architected", - "ad_campaign_saved", - "ad_creative_generated", - "ad_budget_revised", - "ad_approval_requested", - "ad_campaign_approved", - "ad_campaign_published_paused", - "linkedin_search", - "post_engagement_read", - "activity_check", - "web_pages_read", - "email_found", - "email_campaign_created", - "email_campaign_added", - "email_sent", - "email_replied", - "email_auto_reply", - "email_skipped", - "email_bounced", - "email_unsubscribed", - "hubspot_reply_logged", - "email_click", - "testimonial_submitted", - "sequence_people_added", - "sequence_status_changed", - "lead_replenishment_enabled", - "lead_replenishment_disabled", - "recovery_eligible", - "recovery_matched", - "recovery_enrolled", - "recovery_review", - "recovery_invite_sent", - "recovery_invite_accepted", - "recovery_message_sent", - "recovery_reply_detected", - "recovery_suppressed", - "engine_run", - "linkedin_connect", - "error" -]New value: +[ + "resolve", + "invite", + "invite_withdrawn", + "accepted", + "like", + "message", + "followup", + "reply_detected", + "view_profile", + "endorse", + "comment", + "tool_prepare", + "enrich", + "meeting_invited", + "reply_drafted", + "reply_sent", + "reply_dismissed", + "reply_snoozed", + "sequence_started", + "sequence_contact", + "sequence_contact_attempt", + "sequence_contact_cancelled", + "reply_check", + "sequence_stopped", + "meeting_booked", + "meeting_no_show", + "meeting_synced", + "manual_override", + "x_dm", + "x_follow", + "x_like", + "x_follow_back", + "x_unfollow", + "x_repost", + "x_lookup_cached", + "memory_search", + "x_follow_back_scan", + "x_credit_balance", + "x_reply_subscription", + "x_follow_event", + "x_auto_accept", + "instagram_dm", + "instagram_comment", + "instagram_unlock", + "whatsapp_dm", + "track_unavailable", + "track_done", + "ad_campaign_architected", + "ad_campaign_saved", + "ad_creative_generated", + "ad_budget_revised", + "ad_approval_requested", + "ad_campaign_approved", + "ad_campaign_published_paused", + "linkedin_search", + "post_engagement_read", + "activity_check", + "web_pages_read", + "email_found", + "email_campaign_created", + "email_campaign_added", + "email_sent", + "email_replied", + "email_auto_reply", + "email_skipped", + "email_bounced", + "email_unsubscribed", + "hubspot_reply_logged", + "email_click", + "testimonial_submitted", + "sequence_people_added", + "sequence_status_changed", + "lead_replenishment_enabled", + "lead_replenishment_disabled", + "recovery_eligible", + "recovery_matched", + "recovery_enrolled", + "recovery_review", + "recovery_invite_sent", + "recovery_invite_accepted", + "recovery_message_sent", + "recovery_reply_detected", + "recovery_suppressed", + "engine_run", + "linkedin_connect", + "error" +] - changed
Input schema / properties / actions / maxItemsPrevious value: -85New value: +86
3 tool updates
- Changed
add_leads1 field changed- changed
Input schema / oneOfPrevious value: -[ - { - "additionalProperties": false, - "properties": { - "expectedRevision": { - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" - }, - "leads": { - "items": { - "additionalProperties": false, - "properties": { - "company": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ] - }, - "email": { - "anyOf": [ - { - "format": "email", - "maxLength": 320, - "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$", - "type": "string" - }, - { - "type": "null" - } - ] - }, - "linkedinUrl": { - "anyOf": [ - { - "maxLength": 500, - "type": "string" - }, - { - "type": "null" - } - ] - }, - "person": { - "maxLength": 200, - "minLength": 1, - "type": "string" - }, - "title": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ] - }, - "xUsername": { - "anyOf": [ - { - "maxLength": 500, - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "person" - ], - "type": "object" - }, - "maxItems": 500, - "minItems": 1, - "type": "array" - }, - "method": { - "const": "contacts", - "type": "string" - }, - "requestId": { - "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", - "type": "string" - }, - "sequenceId": { - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "workspaceId": { - "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "method", - "requestId", - "sequenceId", - "expectedRevision", - "leads" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "leads": { - "items": { - "additionalProperties": false, - "properties": { - "company": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ] - }, - "customFields": { - "additionalProperties": { - "maxLength": 1000, - "type": "string" - }, - "description": "Per-person values from the customer's own list, keyed by a lowercase token such as personalized_message; written verbatim wherever a message uses {{personalized_message}}. Never generate these values.", - "propertyNames": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "type": "object" - }, - "linkedinUrl": { - "maxLength": 500, - "minLength": 1, - "type": "string" - }, - "person": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ] - }, - "title": { - "anyOf": [ - { - "maxLength": 200, - "type": "string" - }, - { - "type": "null" - } - ] - } - }, - "required": [ - "linkedinUrl" - ], - "type": "object" - }, - "maxItems": 500, - "minItems": 1, - "type": "array" - }, - "method": { - "const": "manual", - "type": "string" - }, - "requestId": { - "description": "Stable idempotency key; reuse it only to retry this exact request.", - "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", - "type": "string" - }, - "sequenceId": { - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "workspaceId": { - "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "method", - "requestId", - "sequenceId", - "leads" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "csvContent": { - "description": "Comma-separated CSV with a header row; column order does not matter. linkedinUrl (required): A person's HTTPS LinkedIn /in/ profile URL, not a company page, website, or other social profile. Accepted headers: linkedin url, linkedin, linkedin_url, profile url. person (optional): The person's full name. Combine separate first and last name columns when needed. Accepted headers: person, name, full name. company (optional): The person's employer or company name. Accepted headers: company. title (optional): The person's job title or role. Accepted headers: title, role. Headers are case-insensitive. Extra per-person columns (for example personalizedMessage or fundingRound) are kept only when customColumns maps each header to a lowercase token such as personalized_message; the value is then written verbatim wherever a message uses {{personalized_message}}, and a blank cell renders empty or as {{token|fallback}}. Other unrecognized, blank, or overlapping columns block import before any rows are added. For arbitrary headers such as URL or Links, inspect the original values and use method=manual with mapped records. Never infer identity from a header alone or invent missing URLs. Preserve names, employers and titles; disclose unsupported fields you omit. Ask one focused question only when the values cannot resolve ambiguity. Example: Person,LinkedIn URL,Company,Title\nAda,https://www.linkedin.com/in/ada,Example,Founder", - "maxLength": 200000, - "minLength": 1, - "type": "string" - }, - "customColumns": { - "additionalProperties": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "description": "Extra CSV header → lowercase token it fills, for example { \"personalizedMessage\": \"personalized_message\" }.", - "propertyNames": { - "maxLength": 200, - "type": "string" - }, - "type": "object" - }, - "method": { - "const": "csv", - "type": "string" - }, - "requestId": { - "description": "Stable idempotency key; reuse it only to retry this exact request.", - "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", - "type": "string" - }, - "sequenceId": { - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "workspaceId": { - "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "method", - "requestId", - "sequenceId", - "csvContent" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "accountId": { - "maxLength": 160, - "minLength": 1, - "type": "string" - }, - "listUrl": { - "format": "uri", - "maxLength": 500, - "type": "string" - }, - "method": { - "const": "sales_navigator", - "type": "string" - }, - "requestId": { - "description": "Stable idempotency key; reuse it only to retry this exact request.", - "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", - "type": "string" - }, - "sequenceId": { - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "workspaceId": { - "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "method", - "requestId", - "sequenceId", - "listUrl" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "batchId": { - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - }, - "method": { - "const": "import_status", - "type": "string" - }, - "workspaceId": { - "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", - "format": "uuid", - "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", - "type": "string" - } - }, - "required": [ - "method", - "batchId" - ], - "type": "object" - } -]New value: +[ + { + "additionalProperties": false, + "properties": { + "accountId": { + "description": "LinkedIn sender ID from get_workspace or the partner LinkedIn accounts list. Omit for automatic assignment. Applies only to new LinkedIn leads; never moves existing leads between senders.", + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "expectedRevision": { + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "leads": { + "items": { + "additionalProperties": false, + "properties": { + "company": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "email": { + "anyOf": [ + { + "format": "email", + "maxLength": 320, + "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$", + "type": "string" + }, + { + "type": "null" + } + ] + }, + "linkedinUrl": { + "anyOf": [ + { + "maxLength": 500, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "person": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "title": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "xUsername": { + "anyOf": [ + { + "maxLength": 500, + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "person" + ], + "type": "object" + }, + "maxItems": 500, + "minItems": 1, + "type": "array" + }, + "method": { + "const": "contacts", + "type": "string" + }, + "requestId": { + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", + "type": "string" + }, + "sequenceId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "workspaceId": { + "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "method", + "requestId", + "sequenceId", + "expectedRevision", + "leads" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "accountId": { + "description": "LinkedIn sender ID from get_workspace or the partner LinkedIn accounts list. Omit for automatic assignment. Applies only to new LinkedIn leads; never moves existing leads between senders.", + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "leads": { + "items": { + "additionalProperties": false, + "properties": { + "company": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "customFields": { + "additionalProperties": { + "maxLength": 1000, + "type": "string" + }, + "description": "Per-person values from the customer's own list, keyed by a lowercase token such as personalized_message; written verbatim wherever a message uses {{personalized_message}}. Never generate these values.", + "propertyNames": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "type": "object" + }, + "linkedinUrl": { + "maxLength": 500, + "minLength": 1, + "type": "string" + }, + "person": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ] + }, + "title": { + "anyOf": [ + { + "maxLength": 200, + "type": "string" + }, + { + "type": "null" + } + ] + } + }, + "required": [ + "linkedinUrl" + ], + "type": "object" + }, + "maxItems": 500, + "minItems": 1, + "type": "array" + }, + "method": { + "const": "manual", + "type": "string" + }, + "requestId": { + "description": "Stable idempotency key; reuse it only to retry this exact request.", + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", + "type": "string" + }, + "sequenceId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "workspaceId": { + "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "method", + "requestId", + "sequenceId", + "leads" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "accountId": { + "description": "LinkedIn sender ID from get_workspace or the partner LinkedIn accounts list. Omit for automatic assignment. Applies only to new LinkedIn leads; never moves existing leads between senders.", + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "csvContent": { + "description": "Comma-separated CSV with a header row; column order does not matter. linkedinUrl (required): A person's HTTPS LinkedIn /in/ profile URL, not a company page, website, or other social profile. Accepted headers: linkedin url, linkedin, linkedin_url, profile url. person (optional): The person's full name. Combine separate first and last name columns when needed. Accepted headers: person, name, full name. company (optional): The person's employer or company name. Accepted headers: company. title (optional): The person's job title or role. Accepted headers: title, role. Headers are case-insensitive. Extra per-person columns (for example personalizedMessage or fundingRound) are kept only when customColumns maps each header to a lowercase token such as personalized_message; the value is then written verbatim wherever a message uses {{personalized_message}}, and a blank cell renders empty or as {{token|fallback}}. Other unrecognized, blank, or overlapping columns block import before any rows are added. For arbitrary headers such as URL or Links, inspect the original values and use method=manual with mapped records. Never infer identity from a header alone or invent missing URLs. Preserve names, employers and titles; disclose unsupported fields you omit. Ask one focused question only when the values cannot resolve ambiguity. Example: Person,LinkedIn URL,Company,Title\nAda,https://www.linkedin.com/in/ada,Example,Founder", + "maxLength": 200000, + "minLength": 1, + "type": "string" + }, + "customColumns": { + "additionalProperties": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "description": "Extra CSV header → lowercase token it fills, for example { \"personalizedMessage\": \"personalized_message\" }.", + "propertyNames": { + "maxLength": 200, + "type": "string" + }, + "type": "object" + }, + "method": { + "const": "csv", + "type": "string" + }, + "requestId": { + "description": "Stable idempotency key; reuse it only to retry this exact request.", + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", + "type": "string" + }, + "sequenceId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "workspaceId": { + "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "method", + "requestId", + "sequenceId", + "csvContent" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "accountId": { + "description": "LinkedIn sender ID from get_workspace or the partner LinkedIn accounts list. Omit for automatic assignment. Applies only to new LinkedIn leads; never moves existing leads between senders.", + "maxLength": 160, + "minLength": 1, + "type": "string" + }, + "listUrl": { + "format": "uri", + "maxLength": 500, + "type": "string" + }, + "method": { + "const": "sales_navigator", + "type": "string" + }, + "requestId": { + "description": "Stable idempotency key; reuse it only to retry this exact request.", + "pattern": "^[A-Za-z0-9][A-Za-z0-9._:-]{7,119}$", + "type": "string" + }, + "sequenceId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "workspaceId": { + "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "method", + "requestId", + "sequenceId", + "listUrl" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "batchId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "method": { + "const": "import_status", + "type": "string" + }, + "workspaceId": { + "description": "A teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.", + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + } + }, + "required": [ + "method", + "batchId" + ], + "type": "object" + } +]
- Added
get_lead_thread - Added
undo_remove_leads
1 tool update
- Changed
enrich_person2 fields changed- changed
Input schema / properties / find / items / enumPrevious value: -[ - "x", - "work_email" -]New value: +[ + "x", + "work_email", + "mobile" +] - changed
Input schema / properties / find / maxItemsPrevious value: -2New value: +3
1 tool update
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / messageTmpl / descriptionPrevious value: -"Required for email, X DM and Instagram DM steps; a LinkedIn message can instead supply text on every variant. On a connect step it is the optional connection note: at most 300 characters, only {{firstName}} {{fullName}} {{company}} {{title}} {{senderFirstName}}; omit it for a request without a note."New value: +"Required for email, X DM and Instagram DM steps; a LinkedIn message can instead supply text on every variant. On a connect step it is the connection note, which should be omitted unless the customer insists on one: at most 300 characters, only {{firstName}} {{fullName}} {{company}} {{title}} {{senderFirstName}}; omit it for a request without a note."
2 tool updates
- Changed
list_leads1 field changed- changed
Input schema / properties / waitingForInput / descriptionPrevious value: -"Only people the engine is holding because a LinkedIn message, email or X DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys (waitingForFiles names the ones that are a file for that person) and waitingSince."New value: +"Only people the engine is holding because a LinkedIn message, email, X DM or Instagram DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys (waitingForFiles names the ones that are a file for that person) and waitingSince."
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / tool / anyOfPrevious value: -[ - { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "fallback": { - "enum": [ - "send_without", - "skip_step" - ], - "type": "string" - }, - "kind": { - "const": "sendspark", - "type": "string" - }, - "outputToken": { - "const": "video_url", - "type": "string" - }, - "params": { - "additionalProperties": { - "maxLength": 300, - "type": "string" - }, - "propertyNames": { - "maxLength": 40, - "type": "string" - }, - "type": "object" - }, - "timeoutHours": { - "maximum": 168, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "params" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "attachment": { - "additionalProperties": false, - "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message, up to each provider's limit (LinkedIn: with the step's own attachments, at most 5 files and 15 MB together; email: one document, image or MP4 up to 18 MB, 1.5 MB from Microsoft mailboxes; X: one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. acceptRisk and emailOptIn are accepted for compatibility and ignored.", - "properties": { - "acceptRisk": { - "const": true, - "type": "boolean" - }, - "emailOptIn": { - "additionalProperties": false, - "properties": { - "acceptedAt": { - "maxLength": 40, - "type": "string" - }, - "acceptedBy": { - "maxLength": 200, - "type": "string" - } - }, - "required": [ - "acceptedBy" - ], - "type": "object" - }, - "key": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - } - }, - "required": [ - "key" - ], - "type": "object" - }, - "kind": { - "const": "customer_input", - "type": "string" - }, - "tokens": { - "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", - "items": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "maxItems": 5, - "type": "array" - } - }, - "required": [ - "kind", - "tokens" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "fallback": { + "enum": [ + "send_without", + "skip_step" + ], + "type": "string" + }, + "kind": { + "const": "sendspark", + "type": "string" + }, + "outputToken": { + "const": "video_url", + "type": "string" + }, + "params": { + "additionalProperties": { + "maxLength": 300, + "type": "string" + }, + "propertyNames": { + "maxLength": 40, + "type": "string" + }, + "type": "object" + }, + "timeoutHours": { + "maximum": 168, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "params" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "attachment": { + "additionalProperties": false, + "description": "LinkedIn message, email, X DM and Instagram DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message, up to each provider's limit (LinkedIn: with the step's own attachments, at most 5 files and 15 MB together; email: one document, image or MP4 up to 18 MB, 1.5 MB from Microsoft mailboxes; X: one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. acceptRisk and emailOptIn are accepted for compatibility and ignored.", + "properties": { + "acceptRisk": { + "const": true, + "type": "boolean" + }, + "emailOptIn": { + "additionalProperties": false, + "properties": { + "acceptedAt": { + "maxLength": 40, + "type": "string" + }, + "acceptedBy": { + "maxLength": 200, + "type": "string" + } + }, + "required": [ + "acceptedBy" + ], + "type": "object" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "kind": { + "const": "customer_input", + "type": "string" + }, + "tokens": { + "description": "LinkedIn message, email, X DM and Instagram DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", + "items": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "maxItems": 5, + "type": "array" + } + }, + "required": [ + "kind", + "tokens" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +]
1 tool update
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / executionModel / descriptionPrevious value: -"linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; missing email or X identity skips that channel's action. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress."New value: +"linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; a LinkedIn message or endorsement must come after a connection request and an 'Accepted?' (linkedin_accepted) or 'Already connected?' (linkedin_first_degree) Yes path; view, like and comment need no connection; missing email or X identity skips that channel's action. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress."
1 tool update
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / executionModel / descriptionPrevious value: -"linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; missing email or X identity skips that channel's action. tracks requires multichannel_tracks; creating or editing graphs requires flow_graph. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress."New value: +"linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; missing email or X identity skips that channel's action. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress."
1 tool update
- Changed
get_workspace2 fields changed- changed
Input schema / properties / actions / items / enumPrevious value: -[ - "resolve", - "invite", - "invite_withdrawn", - "accepted", - "like", - "message", - "followup", - "reply_detected", - "view_profile", - "endorse", - "comment", - "tool_prepare", - "enrich", - "meeting_invited", - "reply_drafted", - "reply_sent", - "reply_dismissed", - "reply_snoozed", - "sequence_started", - "sequence_contact", - "sequence_contact_attempt", - "sequence_contact_cancelled", - "reply_check", - "sequence_stopped", - "meeting_booked", - "meeting_no_show", - "meeting_synced", - "manual_override", - "x_dm", - "x_follow", - "x_like", - "x_follow_back", - "x_unfollow", - "x_repost", - "x_lookup_cached", - "memory_search", - "x_follow_back_scan", - "x_credit_balance", - "x_reply_subscription", - "x_follow_event", - "x_auto_accept", - "instagram_dm", - "instagram_comment", - "instagram_unlock", - "track_unavailable", - "track_done", - "ad_campaign_architected", - "ad_campaign_saved", - "ad_creative_generated", - "ad_budget_revised", - "ad_approval_requested", - "ad_campaign_approved", - "ad_campaign_published_paused", - "linkedin_search", - "post_engagement_read", - "activity_check", - "web_pages_read", - "email_found", - "email_campaign_created", - "email_campaign_added", - "email_sent", - "email_replied", - "email_auto_reply", - "email_skipped", - "email_bounced", - "email_unsubscribed", - "email_click", - "testimonial_submitted", - "sequence_people_added", - "sequence_status_changed", - "lead_replenishment_enabled", - "lead_replenishment_disabled", - "recovery_eligible", - "recovery_matched", - "recovery_enrolled", - "recovery_review", - "recovery_invite_sent", - "recovery_invite_accepted", - "recovery_message_sent", - "recovery_reply_detected", - "recovery_suppressed", - "engine_run", - "linkedin_connect", - "error" -]New value: +[ + "resolve", + "invite", + "invite_withdrawn", + "accepted", + "like", + "message", + "followup", + "reply_detected", + "view_profile", + "endorse", + "comment", + "tool_prepare", + "enrich", + "meeting_invited", + "reply_drafted", + "reply_sent", + "reply_dismissed", + "reply_snoozed", + "sequence_started", + "sequence_contact", + "sequence_contact_attempt", + "sequence_contact_cancelled", + "reply_check", + "sequence_stopped", + "meeting_booked", + "meeting_no_show", + "meeting_synced", + "manual_override", + "x_dm", + "x_follow", + "x_like", + "x_follow_back", + "x_unfollow", + "x_repost", + "x_lookup_cached", + "memory_search", + "x_follow_back_scan", + "x_credit_balance", + "x_reply_subscription", + "x_follow_event", + "x_auto_accept", + "instagram_dm", + "instagram_comment", + "instagram_unlock", + "track_unavailable", + "track_done", + "ad_campaign_architected", + "ad_campaign_saved", + "ad_creative_generated", + "ad_budget_revised", + "ad_approval_requested", + "ad_campaign_approved", + "ad_campaign_published_paused", + "linkedin_search", + "post_engagement_read", + "activity_check", + "web_pages_read", + "email_found", + "email_campaign_created", + "email_campaign_added", + "email_sent", + "email_replied", + "email_auto_reply", + "email_skipped", + "email_bounced", + "email_unsubscribed", + "hubspot_reply_logged", + "email_click", + "testimonial_submitted", + "sequence_people_added", + "sequence_status_changed", + "lead_replenishment_enabled", + "lead_replenishment_disabled", + "recovery_eligible", + "recovery_matched", + "recovery_enrolled", + "recovery_review", + "recovery_invite_sent", + "recovery_invite_accepted", + "recovery_message_sent", + "recovery_reply_detected", + "recovery_suppressed", + "engine_run", + "linkedin_connect", + "error" +] - changed
Input schema / properties / actions / maxItemsPrevious value: -84New value: +85
2 tool updates
- Changed
list_leads2 fields changed- added
Input schema / properties / pageAdded value: +{ + "description": "Zero-based page for personalFiles.", + "maximum": 400, + "minimum": 0, + "type": "integer" +} - added
Input schema / properties / personalFilesAdded value: +{ + "description": "With sequenceId: which file each person has for that sequence's per-person file step (for example their personalised video), 25 people a page: file name and size, and state waiting (no file yet), ready (attached, not sent), sent, or closed (not needed). query narrows by name, email, company or handle; waitingForInput=true lists only people still missing a file. Use it when the customer wants to check who got which file; appUrl opens the same table in the app, where each video can be watched.", + "type": "boolean" +}
- Changed
set_lead_input2 fields changed- added
Input schema / properties / confirmUploadsAdded value: +{ + "description": "The uploadTickets from an uploads call, after each file's bytes were PUT; attaches each to its person. Use instead of a top-level person.", + "items": { + "maxLength": 2000, + "minLength": 1, + "type": "string" + }, + "maxItems": 25, + "minItems": 1, + "type": "array" +} - added
Input schema / properties / uploadsAdded value: +{ + "description": "Several people's files at once: one upload link per person. Stores nothing. Use instead of a top-level person.", + "items": { + "additionalProperties": false, + "properties": { + "email": { + "maxLength": 320, + "minLength": 3, + "type": "string" + }, + "fileName": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "leadId": { + "format": "uuid", + "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$", + "type": "string" + }, + "linkedinUrl": { + "maxLength": 500, + "minLength": 1, + "type": "string" + }, + "size": { + "exclusiveMinimum": 0, + "maximum": 50000000, + "type": "integer" + }, + "xUsername": { + "maxLength": 16, + "minLength": 1, + "type": "string" + } + }, + "required": [ + "key", + "fileName", + "size" + ], + "type": "object" + }, + "maxItems": 25, + "minItems": 1, + "type": "array" +}
1 tool update
- Changed
get_workspace1 field changed- changed
Input schema / properties / view / enumPrevious value: -[ - "summary", - "activity", - "x_posts" -]New value: +[ + "summary", + "activity", + "x_posts", + "suggested_plays" +]
1 tool update
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / tool / anyOfPrevious value: -[ - { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "fallback": { - "enum": [ - "send_without", - "skip_step" - ], - "type": "string" - }, - "kind": { - "const": "sendspark", - "type": "string" - }, - "outputToken": { - "const": "video_url", - "type": "string" - }, - "params": { - "additionalProperties": { - "maxLength": 300, - "type": "string" - }, - "propertyNames": { - "maxLength": 40, - "type": "string" - }, - "type": "object" - }, - "timeoutHours": { - "maximum": 168, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "params" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "attachment": { - "additionalProperties": false, - "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message, up to each provider's limit (LinkedIn: with the step's own attachments, at most 5 files and 15 MB together; email: one document, image or MP4 up to 18 MB, 1.5 MB from Microsoft mailboxes; X: one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. On an email step, first show the customer this warning and get their agreement: \"Attachments on cold email often land in spam or get blocked. This sends from your own mailbox and you accept that risk. A link usually performs better.\" Only then set acceptRisk true; keep an emailOptIn already returned by list_sequences unchanged when editing.", - "properties": { - "acceptRisk": { - "const": true, - "type": "boolean" - }, - "emailOptIn": { - "additionalProperties": false, - "properties": { - "acceptedAt": { - "maxLength": 40, - "type": "string" - }, - "acceptedBy": { - "maxLength": 200, - "type": "string" - } - }, - "required": [ - "acceptedBy" - ], - "type": "object" - }, - "key": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - } - }, - "required": [ - "key" - ], - "type": "object" - }, - "kind": { - "const": "customer_input", - "type": "string" - }, - "tokens": { - "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", - "items": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "maxItems": 5, - "type": "array" - } - }, - "required": [ - "kind", - "tokens" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "fallback": { + "enum": [ + "send_without", + "skip_step" + ], + "type": "string" + }, + "kind": { + "const": "sendspark", + "type": "string" + }, + "outputToken": { + "const": "video_url", + "type": "string" + }, + "params": { + "additionalProperties": { + "maxLength": 300, + "type": "string" + }, + "propertyNames": { + "maxLength": 40, + "type": "string" + }, + "type": "object" + }, + "timeoutHours": { + "maximum": 168, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "params" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "attachment": { + "additionalProperties": false, + "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message, up to each provider's limit (LinkedIn: with the step's own attachments, at most 5 files and 15 MB together; email: one document, image or MP4 up to 18 MB, 1.5 MB from Microsoft mailboxes; X: one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. acceptRisk and emailOptIn are accepted for compatibility and ignored.", + "properties": { + "acceptRisk": { + "const": true, + "type": "boolean" + }, + "emailOptIn": { + "additionalProperties": false, + "properties": { + "acceptedAt": { + "maxLength": 40, + "type": "string" + }, + "acceptedBy": { + "maxLength": 200, + "type": "string" + } + }, + "required": [ + "acceptedBy" + ], + "type": "object" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "kind": { + "const": "customer_input", + "type": "string" + }, + "tokens": { + "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", + "items": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "maxItems": 5, + "type": "array" + } + }, + "required": [ + "kind", + "tokens" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +]
2 tool updates
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / tool / anyOfPrevious value: -[ - { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "fallback": { - "enum": [ - "send_without", - "skip_step" - ], - "type": "string" - }, - "kind": { - "const": "sendspark", - "type": "string" - }, - "outputToken": { - "const": "video_url", - "type": "string" - }, - "params": { - "additionalProperties": { - "maxLength": 300, - "type": "string" - }, - "propertyNames": { - "maxLength": 40, - "type": "string" - }, - "type": "object" - }, - "timeoutHours": { - "maximum": 168, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "params" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "attachment": { - "additionalProperties": false, - "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message (LinkedIn: with the step's own attachments, at most 5 files and 4 MB together; email: one file of 1 MB or less (a document, image or short MP4); X: one image or MP4 video, 4 MB or less). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. On an email step, first show the customer this warning and get their agreement: \"Attachments on cold email often land in spam or get blocked. This sends from your own mailbox and you accept that risk. A link usually performs better.\" Only then set acceptRisk true; keep an emailOptIn already returned by list_sequences unchanged when editing.", - "properties": { - "acceptRisk": { - "const": true, - "type": "boolean" - }, - "emailOptIn": { - "additionalProperties": false, - "properties": { - "acceptedAt": { - "maxLength": 40, - "type": "string" - }, - "acceptedBy": { - "maxLength": 200, - "type": "string" - } - }, - "required": [ - "acceptedBy" - ], - "type": "object" - }, - "key": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - } - }, - "required": [ - "key" - ], - "type": "object" - }, - "kind": { - "const": "customer_input", - "type": "string" - }, - "tokens": { - "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", - "items": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "maxItems": 5, - "type": "array" - } - }, - "required": [ - "kind", - "tokens" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "fallback": { + "enum": [ + "send_without", + "skip_step" + ], + "type": "string" + }, + "kind": { + "const": "sendspark", + "type": "string" + }, + "outputToken": { + "const": "video_url", + "type": "string" + }, + "params": { + "additionalProperties": { + "maxLength": 300, + "type": "string" + }, + "propertyNames": { + "maxLength": 40, + "type": "string" + }, + "type": "object" + }, + "timeoutHours": { + "maximum": 168, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "params" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "attachment": { + "additionalProperties": false, + "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message, up to each provider's limit (LinkedIn: with the step's own attachments, at most 5 files and 15 MB together; email: one document, image or MP4 up to 18 MB, 1.5 MB from Microsoft mailboxes; X: one image up to 5 MB, GIF up to 15 MB or MP4 video up to 50 MB and 140 seconds). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. On an email step, first show the customer this warning and get their agreement: \"Attachments on cold email often land in spam or get blocked. This sends from your own mailbox and you accept that risk. A link usually performs better.\" Only then set acceptRisk true; keep an emailOptIn already returned by list_sequences unchanged when editing.", + "properties": { + "acceptRisk": { + "const": true, + "type": "boolean" + }, + "emailOptIn": { + "additionalProperties": false, + "properties": { + "acceptedAt": { + "maxLength": 40, + "type": "string" + }, + "acceptedBy": { + "maxLength": 200, + "type": "string" + } + }, + "required": [ + "acceptedBy" + ], + "type": "object" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "kind": { + "const": "customer_input", + "type": "string" + }, + "tokens": { + "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", + "items": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "maxItems": 5, + "type": "array" + } + }, + "required": [ + "kind", + "tokens" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +]
- Changed
set_lead_input1 field changed- changed
Input schema / properties / upload / properties / size / maximumPrevious value: -4000000New value: +50000000
3 tool updates
- Changed
list_leads1 field changed- changed
Input schema / properties / waitingForInput / descriptionPrevious value: -"Only people the engine is holding because a LinkedIn message, email or X DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys and waitingSince."New value: +"Only people the engine is holding because a LinkedIn message, email or X DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys (waitingForFiles names the ones that are a file for that person) and waitingSince."
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / tool / anyOfPrevious value: -[ - { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "fallback": { - "enum": [ - "send_without", - "skip_step" - ], - "type": "string" - }, - "kind": { - "const": "sendspark", - "type": "string" - }, - "outputToken": { - "const": "video_url", - "type": "string" - }, - "params": { - "additionalProperties": { - "maxLength": 300, - "type": "string" - }, - "propertyNames": { - "maxLength": 40, - "type": "string" - }, - "type": "object" - }, - "timeoutHours": { - "maximum": 168, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "params" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "kind": { - "const": "customer_input", - "type": "string" - }, - "tokens": { - "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically).", - "items": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "maxItems": 5, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "kind", - "tokens" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "fallback": { + "enum": [ + "send_without", + "skip_step" + ], + "type": "string" + }, + "kind": { + "const": "sendspark", + "type": "string" + }, + "outputToken": { + "const": "video_url", + "type": "string" + }, + "params": { + "additionalProperties": { + "maxLength": 300, + "type": "string" + }, + "propertyNames": { + "maxLength": 40, + "type": "string" + }, + "type": "object" + }, + "timeoutHours": { + "maximum": 168, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "params" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "attachment": { + "additionalProperties": false, + "description": "LinkedIn message, email and X DM steps. A file the customer gives for each person, such as a personalised demo video, sent with the message (LinkedIn: with the step's own attachments, at most 5 files and 4 MB together; email: one file of 1 MB or less (a document, image or short MP4); X: one image or MP4 video, 4 MB or less). The step holds each person until their file is stored with set_lead_input. Use key \"personal_file\" unless the customer names it. A LinkedIn message may have empty text when the file is the whole message; an X DM still needs text. On an email step, first show the customer this warning and get their agreement: \"Attachments on cold email often land in spam or get blocked. This sends from your own mailbox and you accept that risk. A link usually performs better.\" Only then set acceptRisk true; keep an emailOptIn already returned by list_sequences unchanged when editing.", + "properties": { + "acceptRisk": { + "const": true, + "type": "boolean" + }, + "emailOptIn": { + "additionalProperties": false, + "properties": { + "acceptedAt": { + "maxLength": 40, + "type": "string" + }, + "acceptedBy": { + "maxLength": 200, + "type": "string" + } + }, + "required": [ + "acceptedBy" + ], + "type": "object" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + } + }, + "required": [ + "key" + ], + "type": "object" + }, + "kind": { + "const": "customer_input", + "type": "string" + }, + "tokens": { + "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically). May be empty only when attachment is set.", + "items": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "maxItems": 5, + "type": "array" + } + }, + "required": [ + "kind", + "tokens" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +]
- Changed
set_lead_input3 fields changed- added
Input schema / properties / filesAdded value: +{ + "additionalProperties": { + "maxLength": 2000, + "minLength": 1, + "type": "string" + }, + "description": "The file slot's key mapped to the uploadTicket returned by a previous upload call, after the bytes were uploaded.", + "propertyNames": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "type": "object" +} - added
Input schema / properties / uploadAdded value: +{ + "additionalProperties": false, + "description": "Ask for a one-time upload link for this person's file. Stores nothing.", + "properties": { + "fileName": { + "maxLength": 200, + "minLength": 1, + "type": "string" + }, + "key": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "size": { + "exclusiveMinimum": 0, + "maximum": 4000000, + "type": "integer" + } + }, + "required": [ + "key", + "fileName", + "size" + ], + "type": "object" +} - changed
Input schema / requiredPrevious value: -[ - "requestId", - "values" -]New value: +[ + "requestId" +]
2 tool updates
- Changed
energy2 fields changed- changed
Input schema / properties / autoTopUp / descriptionPrevious value: -"true authorizes recurring $10 card charges for 200 Energy whenever the balance falls below 50; obtain explicit customer consent to those terms first. false turns it off. Send it with buy to get the payment link and turn top-up on in one call."New value: +"true authorizes recurring $10 card charges for 100 Energy whenever the balance falls below 50; obtain explicit customer consent to those terms first. false turns it off. Send it with buy to get the payment link and turn top-up on in one call." - changed
Input schema / properties / buy / properties / packs / descriptionPrevious value: -"Packs to buy; each pack is $10 for 200 Energy. The billing page offers 1 ($10), 5 ($50), 10 ($100), 25 ($250), 50 ($500)."New value: +"Packs to buy; each pack is $10 for 100 Energy. The billing page offers 1 ($10), 5 ($50), 10 ($100), 25 ($250), 50 ($500)."
- Changed
sequence_email_settings1 field changed- added
Input schema / properties / settings / properties / unsubscribeFooterAdded value: +{ + "type": "boolean" +}
3 tool updates
- Changed
list_leads1 field changed- changed
Input schema / properties / waitingForInput / descriptionPrevious value: -"Only people the engine is holding because a message step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists waitingFor keys and waitingSince."New value: +"Only people the engine is holding because a LinkedIn message, email or X DM step needs a value from the customer (see leads_waiting_for_input in get_workspace). Each returned lead lists channel, waitingFor keys and waitingSince."
- Changed
save_sequence_draft1 field changed- changed
Input schema / properties / steps / items / properties / tool / anyOfPrevious value: -[ - { - "oneOf": [ - { - "additionalProperties": false, - "properties": { - "fallback": { - "enum": [ - "send_without", - "skip_step" - ], - "type": "string" - }, - "kind": { - "const": "sendspark", - "type": "string" - }, - "outputToken": { - "const": "video_url", - "type": "string" - }, - "params": { - "additionalProperties": { - "maxLength": 300, - "type": "string" - }, - "propertyNames": { - "maxLength": 40, - "type": "string" - }, - "type": "object" - }, - "timeoutHours": { - "maximum": 168, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "params" - ], - "type": "object" - }, - { - "additionalProperties": false, - "properties": { - "kind": { - "const": "customer_input", - "type": "string" - }, - "tokens": { - "description": "Message steps only. The tokens in this step's text that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa.", - "items": { - "pattern": "^[a-z][a-z0-9_]{0,39}$", - "type": "string" - }, - "maxItems": 5, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "kind", - "tokens" - ], - "type": "object" - } - ] - }, - { - "type": "null" - } -]New value: +[ + { + "oneOf": [ + { + "additionalProperties": false, + "properties": { + "fallback": { + "enum": [ + "send_without", + "skip_step" + ], + "type": "string" + }, + "kind": { + "const": "sendspark", + "type": "string" + }, + "outputToken": { + "const": "video_url", + "type": "string" + }, + "params": { + "additionalProperties": { + "maxLength": 300, + "type": "string" + }, + "propertyNames": { + "maxLength": 40, + "type": "string" + }, + "type": "object" + }, + "timeoutHours": { + "maximum": 168, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "params" + ], + "type": "object" + }, + { + "additionalProperties": false, + "properties": { + "kind": { + "const": "customer_input", + "type": "string" + }, + "tokens": { + "description": "LinkedIn message, email and X DM steps. The tokens in this step's text (and an email's subject) that the customer supplies for each person (for example [\"video_url\"] for {{video_url}}). The step holds each person until every token has a value from set_lead_input; there is no timeout. Every non-built-in token in the text must be declared here and vice versa ({{email}} on email and {{username}} on X are filled automatically).", + "items": { + "pattern": "^[a-z][a-z0-9_]{0,39}$", + "type": "string" + }, + "maxItems": 5, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "kind", + "tokens" + ], + "type": "object" + } + ] + }, + { + "type": "null" + } +]
- Changed
set_lead_input2 fields changed- added
Input schema / properties / emailAdded value: +{ + "description": "The person's email address, for someone reached by email.", + "maxLength": 320, + "minLength": 3, + "type": "string" +} - added
Input schema / properties / xUsernameAdded value: +{ + "description": "The person's X handle, with or without @, for someone reached on X.", + "maxLength": 16, + "minLength": 1, + "type": "string" +}
1 tool update
- Changed
save_sequence_draft4 fields changed- changed
Input schema / properties / executionModel / descriptionPrevious value: -"tracks: LinkedIn, email and X steps run as parallel lanes per person (each lane's delayDays count from its own previous step; a person without one channel's handle still gets the others). graph: a branching flow of up to 30 steps; every step has next, branch steps (kind branch, with condition and delayDays as the wait window) split into yes and no paths, connect may sit anywhere (once per path), and a person with no email skips an email step. Example: connect -> branch linkedin_accepted 3 days, yes -> message, no -> email. tracks needs the workspace's multichannel_tracks feature and graph needs its flow_graph feature. Default linear."New value: +"linear: up to 20 ordered steps; delayDays counts from the previous step and the step after connect waits for acceptance. tracks: up to 20 steps in parallel LinkedIn, email and X lanes; delays count from each lane's previous step and a missing channel does not block other lanes. graph: up to 30 nodes with explicit next targets, branch conditions and one cursor; action delays start when that node is reached, waiting branches use delayDays as their window. connect may sit anywhere, once per path; missing email or X identity skips that channel's action. tracks requires multichannel_tracks; creating or editing graphs requires flow_graph. Defaults to linear on create; omission on edit preserves the saved model. Changing models requires no existing execution progress." - added
Input schema / properties / steps / descriptionAdded value: +"Complete replacement, not a patch: 1–30 graph steps or 1–20 linear/tracks steps. Read the full sequence before editing and retain unchanged routing and sendIf fields." - changed
Input schema / properties / steps / items / properties / next / descriptionPrevious value: -"executionModel graph only: where the step leads, by step index. { next: i } on an action step (omit to go on to the following step), { yes: i, no: j } on a branch; null ends the flow there. Step 0 is where everyone starts; paths may merge but never loop."New value: +"executionModel graph only: { next: i } on an action step, { yes: i, no: j } on a branch. A null target ends that path, for example { next: null }; omitting an action's next object or passing top-level next: null defaults to the following step. Step 0 is the entry; every step must be reachable, paths may merge but never loop. Preserve the returned next objects when editing." - changed
Input schema / properties / xThreadCheck / descriptionPrevious value: -"Workspace-wide X setting (applies to every sequence). true: before each X DM, check the conversation so nobody the customer already talks to is messaged and the sequence stops on a reply (5 Energy per DM). false (the default): messages send without that check, cheaper. Omit to keep the current setting."New value: +"Workspace-wide optional X conversation check. true checks for prior conversations before X outreach (5 Energy per DM instead of 0.6); false is the default. Omit to keep the current setting. This is separate from automatic graph reply safety: setting false never disables checks for replies to previously contacted graph conversations, including before switching to LinkedIn or email."
2 tool updates
- Changed
get_workspace2 fields changed- changed
Input schema / properties / actions / items / enumPrevious value: -[ - "resolve", - "invite", - "invite_withdrawn", - "accepted", - "like", - "message", - "followup", - "reply_detected", - "view_profile", - "endorse", - "comment", - "tool_prepare", - "enrich", - "meeting_invited", - "reply_drafted", - "reply_sent", - "reply_dismissed", - "reply_snoozed", - "sequence_started", - "sequence_contact", - "sequence_contact_attempt", - "sequence_contact_cancelled", - "reply_check", - "sequence_stopped", - "meeting_booked", - "meeting_no_show", - "meeting_synced", - "manual_override", - "x_dm", - "x_follow", - "x_like", - "x_follow_back", - "x_unfollow", - "x_repost", - "x_lookup_cached", - "memory_search", - "x_follow_back_scan", - "x_credit_balance", - "x_reply_subscription", - "x_follow_event", - "x_auto_accept", - "instagram_dm", - "instagram_comment", - "instagram_unlock", - "track_unavailable", - "track_done", - "ad_campaign_architected", - "ad_campaign_saved", - "ad_creative_generated", - "ad_budget_revised", - "ad_approval_requested", - "ad_campaign_approved", - "ad_campaign_published_paused", - "linkedin_search", - "post_engagement_read", - "web_pages_read", - "email_found", - "email_campaign_created", - "email_campaign_added", - "email_sent", - "email_replied", - "email_auto_reply", - "email_skipped", - "email_bounced", - "email_unsubscribed", - "email_click", - "testimonial_submitted", - "sequence_people_added", - "sequence_status_changed", - "lead_replenishment_enabled", - "lead_replenishment_disabled", - "recovery_eligible", - "recovery_matched", - "recovery_enrolled", - "recovery_review", - "recovery_invite_sent", - "recovery_invite_accepted", - "recovery_message_sent", - "recovery_reply_detected", - "recovery_suppressed", - "engine_run", - "linkedin_connect", - "error" -]New value: +[ + "resolve", + "invite", + "invite_withdrawn", + "accepted", + "like", + "message", + "followup", + "reply_detected", + "view_profile", + "endorse", + "comment", + "tool_prepare", + "enrich", + "meeting_invited", + "reply_drafted", + "reply_sent", + "reply_dismissed", + "reply_snoozed", + "sequence_started", + "sequence_contact", + "sequence_contact_attempt", + "sequence_contact_cancelled", + "reply_check", + "sequence_stopped", + "meeting_booked", + "meeting_no_show", + "meeting_synced", + "manual_override", + "x_dm", + "x_follow", + "x_like", + "x_follow_back", + "x_unfollow", + "x_repost", + "x_lookup_cached", + "memory_search", + "x_follow_back_scan", + "x_credit_balance", + "x_reply_subscription", + "x_follow_event", + "x_auto_accept", + "instagram_dm", + "instagram_comment", + "instagram_unlock", + "track_unavailable", + "track_done", + "ad_campaign_architected", + "ad_campaign_saved", + "ad_creative_generated", + "ad_budget_revised", + "ad_approval_requested", + "ad_campaign_approved", + "ad_campaign_published_paused", + "linkedin_search", + "post_engagement_read", + "activity_check", + "web_pages_read", + "email_found", + "email_campaign_created", + "email_campaign_added", + "email_sent", + "email_replied", + "email_auto_reply", + "email_skipped", + "email_bounced", + "email_unsubscribed", + "email_click", + "testimonial_submitted", + "sequence_people_added", + "sequence_status_changed", + "lead_replenishment_enabled", + "lead_replenishment_disabled", + "recovery_eligible", + "recovery_matched", + "recovery_enrolled", + "recovery_review", + "recovery_invite_sent", + "recovery_invite_accepted", + "recovery_message_sent", + "recovery_reply_detected", + "recovery_suppressed", + "engine_run", + "linkedin_connect", + "error" +] - changed
Input schema / properties / actions / maxItemsPrevious value: -83New value: +84
- Changed
manage_x_play1 field changed- changed
Input schema / properties / plan / properties / scope / oneOfPrevious value: -[ - { - "properties": { - "kind": { - "const": "any", - "type": "string" - } - }, - "required": [ - "kind" - ], - "type": "object" - }, - { - "properties": { - "kind": { - "const": "posts", - "type": "string" - }, - "postIds": { - "items": { - "maxLength": 40, - "minLength": 1, - "type": "string" - }, - "maxItems": 100, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "kind", - "postIds" - ], - "type": "object" - }, - { - "properties": { - "kind": { - "const": "followers", - "type": "string" - } - }, - "required": [ - "kind" - ], - "type": "object" - }, - { - "properties": { - "kind": { - "const": "intent", - "type": "string" - }, - "sources": { - "items": { - "oneOf": [ - { - "properties": { - "handles": { - "items": { - "pattern": "^[A-Za-z0-9_]{1,15}$", - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "kind": { - "const": "competitor_followers", - "type": "string" - }, - "minShared": { - "default": 3, - "maximum": 10, - "minimum": 2, - "type": "integer" - } - }, - "required": [ - "kind", - "handles" - ], - "type": "object" - }, - { - "properties": { - "competitors": { - "items": { - "pattern": "^[A-Za-z0-9_]{1,15}$", - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "intent": { - "enum": [ - "asks", - "complaints" - ], - "type": "string" - }, - "kind": { - "const": "x_keywords", - "type": "string" - }, - "phrases": { - "items": { - "maxLength": 80, - "type": "string" - }, - "maxItems": 10, - "type": "array" - } - }, - "required": [ - "kind", - "phrases", - "intent" - ], - "type": "object" - }, - { - "properties": { - "kind": { - "const": "reddit_asks", - "type": "string" - }, - "phrases": { - "items": { - "maxLength": 80, - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "subreddits": { - "items": { - "pattern": "^[A-Za-z0-9_]{2,21}$", - "type": "string" - }, - "maxItems": 10, - "type": "array" - } - }, - "required": [ - "kind", - "phrases" - ], - "type": "object" - }, - { - "properties": { - "competitors": { - "items": { - "maxLength": 80, - "minLength": 1, - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "intent": { - "enum": [ - "asks", - "complaints", - "milestone" - ], - "type": "string" - }, - "kind": { - "const": "linkedin_keywords", - "type": "string" - }, - "phrases": { - "items": { - "maxLength": 80, - "type": "string" - }, - "maxItems": 10, - "type": "array" - } - }, - "required": [ - "kind", - "phrases", - "intent" - ], - "type": "object" - }, - { - "properties": { - "actions": { - "items": { - "enum": [ - "replied", - "quoted", - "reposted" - ], - "type": "string" - }, - "type": "array" - }, - "handles": { - "items": { - "pattern": "^[A-Za-z0-9_]{1,15}$", - "type": "string" - }, - "maxItems": 10, - "type": "array" - }, - "kind": { - "const": "competitor_post_engagers", - "type": "string" - }, - "postsPerCompetitor": { - "default": 5, - "maximum": 10, - "minimum": 1, - "type": "integer" - } - }, - "required": [ - "kind", - "handles" - ], - "type": "object" - } - ] - }, - "maxItems": 6, - "minItems": 1, - "type": "array" - } - }, - "required": [ - "kind", - "sources" - ], - "type": "object" - } -]New value: +[ + { + "properties": { + "kind": { + "const": "any", + "type": "string" + } + }, + "required": [ + "kind" + ], + "type": "object" + }, + { + "properties": { + "kind": { + "const": "posts", + "type": "string" + }, + "postIds": { + "items": { + "maxLength": 40, + "minLength": 1, + "type": "string" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "kind", + "postIds" + ], + "type": "object" + }, + { + "properties": { + "kind": { + "const": "followers", + "type": "string" + } + }, + "required": [ + "kind" + ], + "type": "object" + }, + { + "properties": { + "kind": { + "const": "intent", + "type": "string" + }, + "sources": { + "items": { + "oneOf": [ + { + "properties": { + "handles": { + "items": { + "pattern": "^[A-Za-z0-9_]{1,15}$", + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "kind": { + "const": "competitor_followers", + "type": "string" + }, + "minShared": { + "default": 3, + "maximum": 10, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "handles" + ], + "type": "object" + }, + { + "properties": { + "competitors": { + "items": { + "pattern": "^[A-Za-z0-9_]{1,15}$", + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "intent": { + "enum": [ + "asks", + "complaints" + ], + "type": "string" + }, + "kind": { + "const": "x_keywords", + "type": "string" + }, + "phrases": { + "items": { + "maxLength": 80, + "type": "string" + }, + "maxItems": 10, + "type": "array" + } + }, + "required": [ + "kind", + "phrases", + "intent" + ], + "type": "object" + }, + { + "properties": { + "kind": { + "const": "reddit_asks", + "type": "string" + }, + "phrases": { + "items": { + "maxLength": 80, + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "subreddits": { + "items": { + "pattern": "^[A-Za-z0-9_]{2,21}$", + "type": "string" + }, + "maxItems": 10, + "type": "array" + } + }, + "required": [ + "kind", + "phrases" + ], + "type": "object" + }, + { + "properties": { + "competitors": { + "items": { + "maxLength": 80, + "minLength": 1, + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "intent": { + "enum": [ + "asks", + "complaints", + "milestone" + ], + "type": "string" + }, + "kind": { + "const": "linkedin_keywords", + "type": "string" + }, + "phrases": { + "items": { + "maxLength": 80, + "type": "string" + }, + "maxItems": 10, + "type": "array" + } + }, + "required": [ + "kind", + "phrases", + "intent" + ], + "type": "object" + }, + { + "properties": { + "actions": { + "items": { + "enum": [ + "replied", + "quoted", + "reposted" + ], + "type": "string" + }, + "type": "array" + }, + "handles": { + "items": { + "pattern": "^[A-Za-z0-9_]{1,15}$", + "type": "string" + }, + "maxItems": 10, + "type": "array" + }, + "kind": { + "const": "competitor_post_engagers", + "type": "string" + }, + "postsPerCompetitor": { + "default": 5, + "maximum": 10, + "minimum": 1, + "type": "integer" + } + }, + "required": [ + "kind", + "handles" + ], + "type": "object" + } + ] + }, + "maxItems": 6, + "minItems": 1, + "type": "array" + } + }, + "required": [ + "kind", + "sources" + ], + "type": "object" + } +]
1 tool update
- Changed
get_workspace2 fields changed- changed
Input schema / properties / actions / items / enumPrevious value: -[ - "resolve", - "invite", - "invite_withdrawn", - "accepted", - "like", - "message", - "followup", - "reply_detected", - "view_profile", - "endorse", - "comment", - "tool_prepare", - "enrich", - "meeting_invited", - "reply_drafted", - "reply_sent", - "reply_dismissed", - "reply_snoozed", - "sequence_started", - "sequence_stopped", - "meeting_booked", - "meeting_no_show", - "meeting_synced", - "manual_override", - "x_dm", - "x_follow", - "x_like", - "x_follow_back", - "x_unfollow", - "x_repost", - "x_lookup_cached", - "memory_search", - "x_follow_back_scan", - "x_credit_balance", - "x_reply_subscription", - "x_follow_event", - "x_auto_accept", - "instagram_dm", - "instagram_comment", - "instagram_unlock", - "track_unavailable", - "track_done", - "ad_campaign_architected", - "ad_campaign_saved", - "ad_creative_generated", - "ad_budget_revised", - "ad_approval_requested", - "ad_campaign_approved", - "ad_campaign_published_paused", - "linkedin_search", - "post_engagement_read", - "web_pages_read", - "email_found", - "email_campaign_created", - "email_campaign_added", - "email_sent", - "email_replied", - "email_auto_reply", - "email_skipped", - "email_bounced", - "email_unsubscribed", - "email_click", - "testimonial_submitted", - "sequence_people_added", - "sequence_status_changed", - "lead_replenishment_enabled", - "lead_replenishment_disabled", - "recovery_eligible", - "recovery_matched", - "recovery_enrolled", - "recovery_review", - "recovery_invite_sent", - "recovery_invite_accepted", - "recovery_message_sent", - "recovery_reply_detected", - "recovery_suppressed", - "engine_run", - "linkedin_connect", - "error" -]New value: +[ + "resolve", + "invite", + "invite_withdrawn", + "accepted", + "like", + "message", + "followup", + "reply_detected", + "view_profile", + "endorse", + "comment", + "tool_prepare", + "enrich", + "meeting_invited", + "reply_drafted", + "reply_sent", + "reply_dismissed", + "reply_snoozed", + "sequence_started", + "sequence_contact", + "sequence_contact_attempt", + "sequence_contact_cancelled", + "reply_check", + "sequence_stopped", + "meeting_booked", + "meeting_no_show", + "meeting_synced", + "manual_override", + "x_dm", + "x_follow", + "x_like", + "x_follow_back", + "x_unfollow", + "x_repost", + "x_lookup_cached", + "memory_search", + "x_follow_back_scan", + "x_credit_balance", + "x_reply_subscription", + "x_follow_event", + "x_auto_accept", + "instagram_dm", + "instagram_comment", + "instagram_unlock", + "track_unavailable", + "track_done", + "ad_campaign_architected", + "ad_campaign_saved", + "ad_creative_generated", + "ad_budget_revised", + "ad_approval_requested", + "ad_campaign_approved", + "ad_campaign_published_paused", + "linkedin_search", + "post_engagement_read", + "web_pages_read", + "email_found", + "email_campaign_created", + "email_campaign_added", + "email_sent", + "email_replied", + "email_auto_reply", + "email_skipped", + "email_bounced", + "email_unsubscribed", + "email_click", + "testimonial_submitted", + "sequence_people_added", + "sequence_status_changed", + "lead_replenishment_enabled", + "lead_replenishment_disabled", + "recovery_eligible", + "recovery_matched", + "recovery_enrolled", + "recovery_review", + "recovery_invite_sent", + "recovery_invite_accepted", + "recovery_message_sent", + "recovery_reply_detected", + "recovery_suppressed", + "engine_run", + "linkedin_connect", + "error" +] - changed
Input schema / properties / actions / maxItemsPrevious value: -79New value: +83
Related MCP Servers
- AlicenseCqualityBmaintenanceCompetitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs119 npmMIT
- AlicenseAqualityCmaintenanceEnables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.164 npm1MIT
industrylens-mcpofficial
AlicenseNot gradedqualityBmaintenanceBrowse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.MIT
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.