Connect your AI assistant to Revnu, your autonomous growth agent for outbound sales, SEO, content, social media and ads. Use this MCP connector to read leads and campaign results, review and approve queued work, hand jobs to your Revnu agent, and schedule recurring workflows from your AI chat. Supports Streamable HTTP and OAuth with permissions you choose at sign-in. Tools act on your connected Revnu account; write actions require explicit permissions. Learn more and connect at https://revnu.com/mcp.
Scored across 12 tools
Each tool targets a distinct resource and action (agent status, blocklist, leads, LinkedIn, results, reviews, workflows, token identity). The review tools separate list (queue), get (by id), and search (historical by name/topic) clearly, with descriptions actively guiding proper use.
Most tools follow a noun_verb snake_case pattern (lead_get, leads_list, review_search, workflows_list). A few deviate with noun_noun or single-word forms (agent_status, workflow_runs, linkedin_person, whoami), but all remain readable and consistently snake_case.
12 tools is well within the typical 3–15 range, and each covers a distinct read-only resource or query need without obvious redundancy. The count fits the apparent scope of a read-only data surface.
The surface is entirely read-only: no tools to approve review cards, modify blocklists, add/update leads, trigger workflows, or perform any write actions, despite descriptions referencing `actions` and a missing `ask_revnu` tool. These are significant gaps that would prevent an agent from acting on the platform.
Check whether Revnu is working when the customer asks about progress or agent liveness. Returns status with the sandbox lifecycle state, last activity and finished-turn timestamps, whether a turn is running, and the number and next time of scheduled wakes. Read-only; does not start or interrupt work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | Agent liveness, activity and scheduled work. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false; the description reinforces this and adds genuinely useful scope ('does not start or interrupt work'), which rules out a plausible misinterpretation. It stops short of noting cost, latency, or polling guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and zero filler. Slight redundancy in enumerating return fields (status, timestamps, running turn, scheduled wakes) that the output schema already documents, but it stays compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A no-parameter, read-only status probe with an output schema already in place. The description supplies the trigger condition, the read-only guarantee, and a preview of what status covers, so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; the description correctly implies a no-argument call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (check) plus resource (Revnu / agent liveness) with a stated trigger situation. The scope is narrow and unambiguous, and it is easily separable from the surrounding sibling tools (leads, reviews, workflows), none of which overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames when to call it: 'when the customer asks about progress or agent liveness.' That is a clear usage context, though it names no alternative or exclusion, so an agent must still infer that this is the fallback liveness probe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The customer's block list, newest first: the domains and addresses their agent will never research or contact. Pass back nextCursor for the next page. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum block-list entries per page; default 50, range 1-200. | |
| cursor | No | Opaque nextCursor from the previous blocklist_list result. Omit for the first page. |
| Name | Required | Description |
|---|---|---|
| entries | Yes | |
| nextCursor | Yes | Pass to the next list call; null means the last page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: results are ordered 'newest first' and pagination is handled by passing back the returned nextCursor. It does not mention auth requirements or rate limits, but those are less critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no wasted words. The core purpose is front-loaded, followed by pagination behavior and the read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only two fully documented optional parameters, full annotation coverage, and an output schema. The description supplies ordering and pagination guidance, and since an output schema exists, it need not explain return values. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains both limit and cursor in detail. The description mentions nextCursor for pagination but adds no parameter semantics beyond what the schema provides, so it meets the baseline rather than exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope: 'The customer's block list' with contents defined as 'the domains and addresses their agent will never research or contact.' It is clearly distinguishable from sibling list tools like leads_list, review_list, and workflows_list because the resource is explicitly the customer's block list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual cues: it is a read-only list, newest first, and instructs the agent to 'Pass back nextCursor for the next page.' It does not explicitly name when to use this tool versus alternatives, but no sibling tool overlaps with the block-list resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One lead with its contacts (capped at 50; contactsTruncated says when). Read-only. In hosts that support MCP Apps, the user also sees this result in the Revnu app.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Lead ID returned by leads_list or lead_get. |
| Name | Required | Description |
|---|---|---|
| lead | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral detail beyond them: contacts are capped at 50 and `contactsTruncated` signals when that cap was hit, plus the MCP Apps rendering note. It stops short of describing not-found or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses, front-loaded with the payload shape, then the truncation caveat, then the read-only and UI notes. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an output schema and full annotation coverage, the description supplies everything an agent needs: singular scope, the 50-contact cap and its truncation flag, and confirmation of read-only behavior. Return-value structure is correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, including its pattern and provenance, so the schema does the work. The description adds no additional meaning about the ID beyond what the schema already documents; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One lead with its contacts'), and the singular 'One lead' implicitly contrasts with the sibling leads_list, so an agent can route between them without opening a schema. Scope of the payload is also stated (contacts capped at 50).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: fetching a single lead by ID. The description never names leads_list as the alternative for enumerating leads, nor does it say what to do when the ID is unknown. The schema's note that the ID comes from leads_list or lead_get partially compensates, but the description itself gives no explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The customer's leads, newest first, with status and outreach counts but never draft bodies. workflowRunId (a run id from workflow_runs) lists only the leads that run created or added people to, each with runContactIds and runPeople. Pass back nextCursor for the next page. Read-only. In hosts that support MCP Apps, the user also sees this result in the Revnu app.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum leads per page; default 50, range 1-100. Large records may shorten a page. | |
| cursor | No | Opaque nextCursor from the previous leads_list result. Omit for the first page; keep the same filters. | |
| status | No | Optional status: qualified, drafted, declined, sent, replied, bounced or partially_sent. Omit for all statuses. | |
| workflowRunId | No | Run ID returned by workflow_runs or workflow_run. Restricts results to leads linked to that run. |
| Name | Required | Description |
|---|---|---|
| leads | Yes | |
| nextCursor | Yes | Pass to the next list call; null means the last page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint, so safety is covered; the description nonetheless adds real context by disclosing that draft bodies are omitted and that in MCP Apps hosts the result is surfaced to the user in the Revnu app. It does not discuss permission requirements, but that is a modest gap given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with what the tool returns, then filtering, pagination, and host behavior in descending priority. The MCP Apps sentence is the least essential but still earns its place as host-specific behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-shape explanation is largely unnecessary, and the description still covers filtering, pagination, and excluded content. Gaps are minor: no guidance on choosing among sibling listing tools and no note on authentication scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that run-scoped results carry `runContactIds` and `runPeople`, and by framing `cursor` as an opaque pagination token that must retain the original filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (lists), the resource (customer's leads), ordering (newest first), and the returned fields (status and outreach counts, never draft bodies). It is clearly distinguishable from the single-record sibling lead_get 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operating context: `workflowRunId` narrows the list to leads a run created or touched, and `nextCursor` must be passed back to page while keeping the same filters. It never names an alternative tool or an explicit when-not condition, so the agent must infer that lead_get is for single records.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One person's LinkedIn relationship with each of the customer's connected LinkedIn accounts (or the one named in account): whether they're connected, any pending invite and when it was sent, Revnu's own invite record with when it saw acceptance, and the newest 50 messages with who sent each. profile is a linkedin.com/in/ URL or id. Read live from LinkedIn: each account is one paced profile lookup, so look people up as you need them rather than in bulk. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Name of a connected LinkedIn account. Omit to inspect every connected account; one paced profile lookup per account. | |
| profile | Yes | A linkedin.com/in/ profile URL or LinkedIn profile ID from the customer or a lead contact. |
| Name | Required | Description |
|---|---|---|
| person | Yes | First successfully resolved profile across the selected accounts. Null when no account resolves it; inspect accounts.state for the reason. |
| accounts | Yes | One result per selected account. Inspect state before using relationship or conversation fields; one account can fail while another succeeds. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety is covered; the description adds genuinely new behavior: the data is read live from LinkedIn (freshness), lookups are paced per account (cost/rate context), and the message payload is capped at the newest 50. It stops short of noting pagination or failure behavior for a private/nonexistent profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries information — result shape, parameter format, lookup cost, and read-only status — with no filler. It is dense rather than front-loaded around a single purpose statement, and the trailing 'Read-only' partially duplicates the readOnlyHint annotation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so describing return fields is not strictly required, yet the description usefully frames what the caller gets. Combined with the pacing/cost note and parameter format, an agent has enough to call it correctly; the only omission is behavior when the profile is not found or not connected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by spelling out the cross-parameter consequence of omitting `account` (one paced lookup per connected account) and restating that `profile` accepts a URL or id. That cost implication is not encoded in the schema and is useful for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (one person's LinkedIn relationship across the customer's connected accounts) and enumerates the returned facets — connection status, pending invite timing, Revnu's invite record, and the newest 50 messages. It is unambiguous and clearly distinct from the sibling tools, which deal with leads, reviews, and workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete operational guidance: look people up on demand rather than in bulk because each connected account costs one paced profile lookup, and it explains that omitting `account` inspects every connected account. It does not explicitly name an alternative tool, but there is no sibling that overlaps, so no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The customer's growth scoreboard for a window ending now: per-channel sections that are either {available: true, data} or {available: false, reason}. Zero and unknown are different. since is epoch milliseconds, clamped to the last 31 days; default 24 hours. In hosts that support MCP Apps, the user also sees this result in the Revnu app.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Start of the reporting window as Unix epoch milliseconds. Omit for 24 hours; clamped to 1 hour through 31 days ago. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior beyond that: window clamping, the 24h default, the zero-vs-unknown distinction, and per-channel degradation via {available: false, reason}. It stops short of covering freshness/latency or what triggers unavailable channels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact clauses, front-loaded with the result contract, then parameter semantics, then the MCP Apps note. Dense but each clause carries information; the zero-vs-unknown sentence and the app note are short and non-redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return-value detail is bonus rather than obligation, and combined with the annotation set the agent has enough to call it correctly. Only the absence of any guidance on unavailable-channel reasons or freshness leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema for `since` is actually more precise than the description (it states the 1-hour-to-31-day range, the description only mentions the 31-day ceiling). With the schema doing the heavy lifting, the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource — 'the customer's growth scoreboard for a window ending now' — with the shape of what comes back (per-channel sections). No sibling tool (review_get, leads_list, workflow_runs) covers a growth scoreboard, so it is distinguishable, but the phrasing is noun-heavy and never states the verb or explicit scope boundaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the 'growth scoreboard' framing and the default-window note, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative (e.g. a per-channel or historical variant). An agent can infer intent but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One review card by id, including its full payload (draft text, options, research). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Review card ID returned by review_list or review_get. |
| Name | Required | Description |
|---|---|---|
| item | Yes | The requested review card. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description's 'Read-only' is a restatement that adds no new safety information. The one piece of added value is describing what the card payload contains, though an output schema exists that likely covers this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence stating the resource, the key, and the payload, with zero filler. Nothing restates the name or wastes the agent's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations, full schema coverage, a single required parameter, and an output schema handling return values, the description is nearly complete for a simple fetch. Minor gaps remain around not-found/error behavior and explicit routing away from review_list, but nothing essential to invoking it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter, whose ID format and provenance are documented in the schema itself. The description adds no additional syntax, format, or validation detail beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One review card by id') and enumerates the payload contents (draft text, options, research), which is more informative than the title alone. It implies the single-item counterpart to review_list but never names or contrasts that sibling explicitly, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by 'by id' – an agent infers it should call this when it already holds a card ID (as the schema also notes, IDs come from review_list or review_get). There is no explicit when-to-use versus review_list, no prerequisite statement, and no guidance on what to do if the ID is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List what is waiting for the customer's approval: drafts, questions, budgets and other cards their revnu growth agent has queued. Each card carries actions, the exact verbs the API accepts for it, and primaryLabel, what the dashboard's main button would say. One call returns up to 50 open cards (pass limit for up to 100; any beyond that are not returned): pending ones and ones the agent is revising together, with status on each card saying which. There is no status filter. Returns compact card summaries to the model; full drafts and evidence are delivered separately to the Revnu app. Use review_get only when the customer asks to inspect a particular draft. One successful call already shows the cards in hosts that support MCP Apps. Do not call again to display them, verify the same list, or fetch the same result with omitted/default arguments. Finish with a short count rather than copying the entire card list into chat. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum open cards to return; default 50, range 1-100. Includes pending and revising cards in one call. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Compact open-card summaries. Full drafts are available through review_get and the app. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the safety/idempotency profile; the description adds substantive behavior: a 50-card default cap that silently drops anything beyond, no status filter, mixed pending/revising statuses, that only compact summaries reach the model while full drafts go to the Revnu app, and that a single call renders cards in MCP Apps hosts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and routing come first, and the anti-patterns at the end are high-value. The description is dense and slightly long, with the limit behavior restated in two places, but nearly every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shapes need not be detailed, yet the description still tells the agent what it receives (compact summaries, per-card actions/primaryLabel/status). With one optional param and full annotation coverage, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the limit parameter's default, range and scope are already fully documented. The description restates this and adds only the truncation behavior for values beyond the cap, which is return semantics rather than parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List what is waiting for the customer's approval: drafts, questions, budgets and other cards') and explicitly contrasts itself with the sibling review_get. An agent can distinguish this bulk-listing tool from review_get/review_search 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit routing ('Use review_get only when the customer asks to inspect a particular draft') plus hard anti-patterns: do not call again to display, verify the same list, or refetch with omitted/default arguments. It also prescribes the response style (short count, not the full card list), which is unusually complete guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether work for named people or topics already has a review card, including done, dismissed and other historical cards. Batch names in one call. Returns compact status, recorded delivery state and review links without drawing another app or returning draft bodies. Searches titles and prompts only; no match is not proof of no activity. Done is not proof of delivery. When hasMore is false, openCardCount already counts every matching pending/revising card. Copy reviewUrl directly for links. For a named status lookup, report matching records without listing unrelated queue cards or opening the app. Stop when the requested statuses and their evidence limits are clear. Use review_get only when full draft or evidence is needed; use ask_revnu for missing account evidence, requesting a read-only check when no action is authorized. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum matches per query; default 5, max 20. hasMore means matches may be missing because of this limit or the shared read budget. | |
| queries | Yes | One person or topic per query. Queries run independently in one call. |
| Name | Required | Description |
|---|---|---|
| matches | Yes | |
| coverage | Yes | Search and delivery evidence limitations. Preserve these when reporting no matches or unconfirmed delivery. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses genuine behavioral caveats: no match is not proof of no activity, done is not proof of delivery, hasMore interacts with a shared read budget, and it avoids opening the app or returning draft bodies. This is exactly the kind of context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, but the text sprawls into meta-instructions ('Stop when the requested statuses and their evidence limits are clear') and a trailing 'Read-only.' that merely repeats the annotation. Several sentences could be trimmed without losing guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be explained, yet the description covers the relevant semantics (compact status, openCardCount, reviewUrl, hasMore) plus search limitations. It is complete for correct invocation, with only the redundant return-value detail as a minor overreach.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (queries, limit) are already documented with their bounds and the hasMore caveat in the schema itself. The description only echoes batching ('Batch names in one call'), adding little semantic detail beyond the structured fields, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('check whether work for named people or topics already has a review card') and immediately bounds scope to 'titles and prompts only'. It also names the sibling it is not, review_get, so an agent can distinguish the two without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing: use review_get when full draft or evidence is needed, use ask_revnu for missing account evidence, and report matching records for a named status lookup. It also states batching behavior ('Batch names in one call') and the stop condition, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who this token is: its label, scopes, the revnu account it belongs to, and the rate limits it is held to. Needs no scope. Its scopes say which tools this token can use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| me | Yes | Connected business, token permissions and rate limits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered; the description adds genuinely non-redundant behavior by stating that the call requires no scope and that the returned scopes govern which other tools are usable. That auth-and-capability context goes beyond the annotations and is directly actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the identity payload and followed by the two constraints that matter (no scope needed; scopes gate other tools). The final sentence restates 'scopes' already listed in sentence one, a small redundancy, and 'revnu' reads as a typo, but overall the text is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema and rich annotations, the description covers the essentials: what is returned, that no scope is required, and how the result informs later calls. The one gap is the absence of any relationship to agent_status, which the agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; the description correctly says nothing about arguments and instead spends its words on what the call returns. No parameter-level meaning is missing because there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates exactly what is returned (token label, scopes, owning account, rate limits), which makes the tool unmistakable against the list/get siblings such as leads_list or workflow_runs. It is a noun phrase rather than a verb+resource, and it never names a sibling, but the resource (the calling token itself) is unique among the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Needs no scope' and 'its scopes say which tools this token can use' imply the use case (checking credentials and capability before calling other tools), but the description never states when to call this versus agent_status, which is a plausibly overlapping sibling. Usage must be inferred rather than read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run history for one workflow, newest first, with per-step outcomes. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | workflowId returned by workflows_list or a workflow write. | |
| limit | No | Maximum recent runs; default 10. The API caps at 50 even when a larger value is supplied. |
| Name | Required | Description |
|---|---|---|
| runs | Yes | Run history for the requested workflow, newest first. Empty means no runs are recorded. Queued or running is unfinished; inspect error and stepResults on failed or abandoned runs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Read-only' adds nothing. The description does add real behavioral context beyond the annotations: results are ordered newest first and include per-step outcomes. It says nothing about pagination or how to reach runs beyond the limit window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and front-loaded: scope, ordering, and return shape come first. The trailing 'Read-only.' is pure duplication of readOnlyHint=true and does not earn its place, which keeps this from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations cover the safety profile. Scope, ordering, and content shape are covered; the only real gap is how an agent retrieves runs older than the limit window, which the capped limit parameter hints at but the description never addresses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema, including the default and the API's 50-run cap. The description adds no parameter-level meaning beyond 'one workflow', which the schema already conveys. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list run history) and resource (one workflow), plus the ordering and the per-step outcome content. It does not explicitly distinguish itself from siblings like workflows_list or results_get, but the resource is narrow enough that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'for one workflow' suggests you need a workflowId, but there is no when-to-use vs. workflows_list, no statement of when run history is the right call versus results_get, and no exclusions. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The customer's recurring workflows with their schedule, next run and steps. Read-only. In hosts that support MCP Apps, the user also sees this result in the Revnu app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| workflows | Yes | Non-deleted workflows, including live, paused and proposed workflows; empty when none exist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so restating 'Read-only' adds nothing. The one genuinely new behavioral detail is that hosts supporting MCP Apps surface the result to the user in the Revnu app, which tells the agent the output is user-visible. That is useful but thin, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what is returned before the host-behavior aside. The 'Read-only' sentence is redundant against the annotations and is the only wasted line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not enumerate return fields, and it correctly avoids doing so while still hinting at the shape (schedule, next run, steps). Annotations carry the safety profile, so nothing critical is missing, though sibling differentiation could be stronger.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to explain; baseline for a no-parameter tool applies. Schema coverage is reported at 100% regardless.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and enumerates its contents ('recurring workflows with their schedule, next run and steps'), so an agent knows it lists scheduled workflows rather than workflow executions. It does not explicitly name the sibling it is not (workflow_runs), but the resource framing separates them adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus workflow_runs, nor any prerequisite or context trigger. Usage is only weakly implied by 'the customer's recurring workflows'. With a sibling that lists runs of those workflows, an explicit routing cue is conspicuously absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
review_list9 fields changedOutput schema / properties / items / descriptionPrevious value: -"Open review cards, including revisions."New value: +"Compact open-card summaries. Full drafts are available through review_get and the app."Output schema / properties / items / items / additionalPropertiesPrevious value: -trueNew value: +falseOutput schema / properties / items / items / properties / createdAtRemoved value: -{
- "description": "Unix epoch milliseconds.",
- "type": "number"
-}Output schema / properties / items / items / properties / detailRemoved value: -{
- "description": "Additional context, when available.",
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / items / items / properties / optionsRemoved value: -{
- "anyOf": [
- {
- "items": {
- "additionalProperties": false,
- "properties": {
- "label": {
- "type": "string"
- },
- "value": {
- "type": "string"
- }
- },
- "required": [
- "label",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Choices accepted by review_answer with action choose."
-}Output schema / properties / items / items / properties / payloadRemoved value: -{
- "anyOf": [
- {
- "additionalProperties": true,
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
- ],
- "description": "Source-specific draft, evidence or decision data."
-}Output schema / properties / items / items / properties / promptRemoved value: -{
- "description": "The question or approval request.",
- "type": "string"
-}Output schema / properties / items / items / properties / summaryRemoved value: -{
- "description": "Short summary, when available.",
- "type": [
- "string",
- "null"
- ]
-}Output schema / properties / items / items / properties / updatedAtRemoved value: -{
- "description": "Unix epoch milliseconds.",
- "type": "number"
-}review_searchagent_status1 field changedOutput schema / properties / status / properties / running / descriptionPrevious value: -"Whether recent invocation telemetry indicates an unfinished turn within the last 30 minutes. Poll agent_message_status for a particular request."New value: +"Whether a started turn has no exit yet and the agent wrote activity in the last 20 minutes. Poll agent_message_status for a particular request."lead_get3 fields changedOutput schema / properties / lead / properties / runPeople / descriptionPrevious value: -"People the filtered workflow run added to this company's research list but not as contacts."New value: +"People the filtered workflow run returned on this company's research list but not as contacts."Output schema / properties / lead / properties / runPeople / items / properties / alreadyKnownAdded value: +{
+ "description": "True when the company already had this person before the run.",
+ "type": "boolean"
+}Output schema / properties / lead / properties / runPeople / items / properties / roleAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "economic",
+ "champion",
+ "technical",
+ "user"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Part in the deal: economic is the buyer, champion the inside advocate."
+}leads_list3 fields changedOutput schema / properties / leads / items / properties / runPeople / descriptionPrevious value: -"People the filtered workflow run added to this company's research list but not as contacts."New value: +"People the filtered workflow run returned on this company's research list but not as contacts."Output schema / properties / leads / items / properties / runPeople / items / properties / alreadyKnownAdded value: +{
+ "description": "True when the company already had this person before the run.",
+ "type": "boolean"
+}Output schema / properties / leads / items / properties / runPeople / items / properties / roleAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "economic",
+ "champion",
+ "technical",
+ "user"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Part in the deal: economic is the buyer, champion the inside advocate."
+}lead_get1 field changedOutput schema / properties / lead / properties / runPeopleAdded value: +{
+ "description": "People the filtered workflow run added to this company's research list but not as contacts.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "photoUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "profileUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "title",
+ "email",
+ "linkedinUrl",
+ "profileUrl",
+ "photoUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}leads_list1 field changedOutput schema / properties / leads / items / properties / runPeopleAdded value: +{
+ "description": "People the filtered workflow run added to this company's research list but not as contacts.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "photoUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "profileUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "name",
+ "title",
+ "email",
+ "linkedinUrl",
+ "profileUrl",
+ "photoUrl"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}workflow_runs2 fields changedOutput schema / properties / runs / items / properties / found / properties / contacts / descriptionPrevious value: -"People first saved by this run."New value: +"Contacts first saved by this run."Output schema / properties / runs / items / properties / found / properties / peopleAdded value: +{
+ "description": "People this run added to a company's research list but not as contacts.",
+ "type": "number"
+}agent_status5 fields changedOutput schema / properties / status / properties / lastActivityAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Most recent sandbox activity as Unix epoch milliseconds, or null when none is recorded."Output schema / properties / status / properties / lastTurnAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Most recent turn exit found in recent telemetry, as Unix epoch milliseconds, or null when none is found."Output schema / properties / status / properties / nextWakeAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Earliest pending wakeup as Unix epoch milliseconds, or null when none is scheduled."Output schema / properties / status / properties / pendingWakes / descriptionAdded value: +"Pending scheduled wakeups for this business, capped at 100; 100 can mean more exist."Output schema / properties / status / properties / running / descriptionAdded value: +"Whether recent invocation telemetry indicates an unfinished turn within the last 30 minutes. Poll agent_message_status for a particular request."blocklist_list3 fields changedOutput schema / properties / entries / items / properties / addedAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"When the block was added, as Unix epoch milliseconds."Output schema / properties / entries / items / properties / addedBy / descriptionAdded value: +"Recorded actor who added the block, or null when unknown."Output schema / properties / entries / items / properties / reason / descriptionAdded value: +"Why this identity was blocked, or null when not recorded."lead_get12 fields changedOutput schema / properties / lead / properties / archetype / descriptionAdded value: +"Customer-defined buyer or company archetype."Output schema / properties / lead / properties / companyName / descriptionAdded value: +"Company name, or null when not recorded."Output schema / properties / lead / properties / contact / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "email": {
- "type": [
- "string",
- "null"
- ]
- },
- "linkedinUrl": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": [
- "string",
- "null"
- ]
- },
- "photoUrl": {
- "description": "Sourced profile photo; use it when displaying a person.",
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "description": "Contact email address, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "description": "Contact's LinkedIn profile URL, when known.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Contact's sourced full name, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Contact's job title, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / lead / properties / contacts / items / properties / email / descriptionAdded value: +"Contact email address, or null when unknown."Output schema / properties / lead / properties / contacts / items / properties / linkedinUrl / descriptionAdded value: +"Contact's LinkedIn profile URL, when known."Output schema / properties / lead / properties / contacts / items / properties / name / descriptionAdded value: +"Contact's sourced full name, or null when unknown."Output schema / properties / lead / properties / contacts / items / properties / title / descriptionAdded value: +"Contact's job title, or null when unknown."Output schema / properties / lead / properties / createdAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"When this lead was saved, as Unix epoch milliseconds."Output schema / properties / lead / properties / fields / items / properties / key / descriptionAdded value: +"Configured lead-column key."Output schema / properties / lead / properties / fields / items / properties / value / descriptionAdded value: +"Stored column value, truncated to the API's display limit."Output schema / properties / lead / properties / tags / descriptionAdded value: +"Labels assigned to this lead."Output schema / properties / lead / properties / vertical / descriptionAdded value: +"Customer-defined industry category."leads_list12 fields changedOutput schema / properties / leads / items / properties / archetype / descriptionAdded value: +"Customer-defined buyer or company archetype."Output schema / properties / leads / items / properties / companyName / descriptionAdded value: +"Company name, or null when not recorded."Output schema / properties / leads / items / properties / contact / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {
- "email": {
- "type": [
- "string",
- "null"
- ]
- },
- "linkedinUrl": {
- "type": [
- "string",
- "null"
- ]
- },
- "name": {
- "type": [
- "string",
- "null"
- ]
- },
- "photoUrl": {
- "description": "Sourced profile photo; use it when displaying a person.",
- "type": [
- "string",
- "null"
- ]
- },
- "title": {
- "type": [
- "string",
- "null"
- ]
- }
- },
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "description": "Contact email address, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "description": "Contact's LinkedIn profile URL, when known.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Contact's sourced full name, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Contact's job title, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / leads / items / properties / contacts / items / properties / email / descriptionAdded value: +"Contact email address, or null when unknown."Output schema / properties / leads / items / properties / contacts / items / properties / linkedinUrl / descriptionAdded value: +"Contact's LinkedIn profile URL, when known."Output schema / properties / leads / items / properties / contacts / items / properties / name / descriptionAdded value: +"Contact's sourced full name, or null when unknown."Output schema / properties / leads / items / properties / contacts / items / properties / title / descriptionAdded value: +"Contact's job title, or null when unknown."Output schema / properties / leads / items / properties / createdAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"When this lead was saved, as Unix epoch milliseconds."Output schema / properties / leads / items / properties / fields / items / properties / key / descriptionAdded value: +"Configured lead-column key."Output schema / properties / leads / items / properties / fields / items / properties / value / descriptionAdded value: +"Stored column value, truncated to the API's display limit."Output schema / properties / leads / items / properties / tags / descriptionAdded value: +"Labels assigned to this lead."Output schema / properties / leads / items / properties / vertical / descriptionAdded value: +"Customer-defined industry category."linkedin_person7 fields changedOutput schema / properties / accounts / descriptionPrevious value: -"Connection, invitation and conversation state per connected account."New value: +"One result per selected account. Inspect state before using relationship or conversation fields; one account can fail while another succeeds."Output schema / properties / accounts / items / additionalPropertiesRemoved value: -trueOutput schema / properties / accounts / items / anyOfAdded value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "account": {
+ "description": "Connected account label; pass it as linkedin_person.account to read only this account.",
+ "type": "string"
+ },
+ "connected": {
+ "description": "True when LinkedIn reports a first-degree connection to this person.",
+ "type": "boolean"
+ },
+ "connectedAs": {
+ "description": "Connected LinkedIn identity label, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "invite": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "at": {
+ "description": "Invitation creation time as Unix epoch milliseconds, or null when unavailable.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "direction": {
+ "anyOf": [
+ {
+ "enum": [
+ "sent",
+ "received"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Who initiated the invitation, or null when LinkedIn does not identify a direction."
+ },
+ "status": {
+ "anyOf": [
+ {
+ "enum": [
+ "pending",
+ "ignored",
+ "withdrawn"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Invitation state reported by the relationship lookup."
+ }
+ },
+ "required": [
+ "direction",
+ "status",
+ "at"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "LinkedIn's invitation state; null for an existing connection or no visible invitation."
+ },
+ "lastReplyAt": {
+ "description": "Time of the newest incoming entry in the returned history, as Unix epoch milliseconds; null if none is present.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "messages": {
+ "description": "Newest conversation entries, merged across inboxes and returned oldest first. An empty array means no visible messages.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "at": {
+ "description": "Message time as Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "from": {
+ "description": "Whether the connected account or the looked-up person sent this entry.",
+ "enum": [
+ "you",
+ "them"
+ ],
+ "type": "string"
+ },
+ "kind": {
+ "description": "Conversation entry type; events and invitations may have no text.",
+ "enum": [
+ "message",
+ "event",
+ "inmail",
+ "invitation"
+ ],
+ "type": "string"
+ },
+ "sentBy": {
+ "anyOf": [
+ {
+ "enum": [
+ "agent",
+ "person"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "For outgoing messages: agent means Revnu, person means a human in Revnu's inbox, and null means native LinkedIn or unknown. Incoming entries are null."
+ },
+ "text": {
+ "description": "Message or event text, or null when unavailable.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "at",
+ "from",
+ "sentBy",
+ "kind",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "messagesTruncated": {
+ "description": "True when older messages or additional inboxes were omitted; history is limited to 50 entries from up to three chats.",
+ "type": "boolean"
+ },
+ "revnuInvite": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "acceptedAt": {
+ "description": "When Revnu observed acceptance, or null when not recorded.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "sentAt": {
+ "description": "When Revnu sent its most recent invitation from this account, as Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "withdrawnAt": {
+ "description": "When the invitation was withdrawn, or null when not recorded.",
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "sentAt",
+ "acceptedAt",
+ "withdrawnAt"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Revnu's own invitation history, independent of LinkedIn's current invite state; null if Revnu has no record."
+ },
+ "state": {
+ "const": "ok",
+ "description": "The profile and conversation lookup succeeded for this account.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account",
+ "connectedAs",
+ "state",
+ "connected",
+ "invite",
+ "revnuInvite",
+ "messages",
+ "messagesTruncated",
+ "lastReplyAt"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "properties": {
+ "account": {
+ "description": "Connected account label; pass it as linkedin_person.account to read only this account.",
+ "type": "string"
+ },
+ "connectedAs": {
+ "description": "Connected LinkedIn identity label, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "const": "not_connected",
+ "description": "This account has no usable LinkedIn connection; relationship and conversation fields are unavailable.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account",
+ "connectedAs",
+ "state"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "properties": {
+ "account": {
+ "description": "Connected account label; pass it as linkedin_person.account to read only this account.",
+ "type": "string"
+ },
+ "connectedAs": {
+ "description": "Connected LinkedIn identity label, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "state": {
+ "const": "needs_reauth",
+ "description": "This account must reconnect LinkedIn before the lookup can proceed.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account",
+ "connectedAs",
+ "state"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "properties": {
+ "account": {
+ "description": "Connected account label; pass it as linkedin_person.account to read only this account.",
+ "type": "string"
+ },
+ "connectedAs": {
+ "description": "Connected LinkedIn identity label, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "message": {
+ "description": "Why the lookup is paced.",
+ "type": "string"
+ },
+ "retryAt": {
+ "description": "Earliest retry time as Unix epoch milliseconds; wait until then before retrying this account.",
+ "type": "number"
+ },
+ "state": {
+ "const": "paced",
+ "description": "The profile read was deferred by account pacing, not a missing relationship.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account",
+ "connectedAs",
+ "state",
+ "message",
+ "retryAt"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "properties": {
+ "account": {
+ "description": "Connected account label; pass it as linkedin_person.account to read only this account.",
+ "type": "string"
+ },
+ "connectedAs": {
+ "description": "Connected LinkedIn identity label, or null when unknown.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "message": {
+ "description": "Lookup failure detail, such as an unresolved profile or unavailable conversation.",
+ "type": "string"
+ },
+ "state": {
+ "const": "error",
+ "description": "This account's lookup failed; do not interpret absent relationship data as disconnected.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "account",
+ "connectedAs",
+ "state",
+ "message"
+ ],
+ "type": "object"
+ }
+]Output schema / properties / accounts / items / propertiesRemoved value: -{}Output schema / properties / accounts / items / typeRemoved value: -"object"Output schema / properties / person / anyOfPrevious value: -[
- {
- "additionalProperties": true,
- "properties": {},
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": true,
+ "properties": {
+ "headline": {
+ "description": "LinkedIn profile headline, or null when not returned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "Profile name assembled from the returned first and last names, or null when unavailable.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "providerId": {
+ "description": "LinkedIn's provider identifier for this person, or null when not returned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "publicIdentifier": {
+ "description": "Public profile slug from linkedin.com/in/<slug>, or null when not returned.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "providerId",
+ "publicIdentifier",
+ "name",
+ "headline"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / person / descriptionPrevious value: -"Resolved LinkedIn person, or null when unresolved."New value: +"First successfully resolved profile across the selected accounts. Null when no account resolves it; inspect accounts.state for the reason."whoami22 fields changedOutput schema / properties / me / properties / account / descriptionAdded value: +"The business this connection operates on."Output schema / properties / me / properties / account / properties / id / descriptionAdded value: +"Revnu business account ID that owns this token."Output schema / properties / me / properties / account / properties / name / descriptionAdded value: +"Business display name, or null before one is known."Output schema / properties / me / properties / createdAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"When this token was issued, as Unix epoch milliseconds."Output schema / properties / me / properties / inSetup / descriptionAdded value: +"True while onboarding is incomplete. Call setup_status for the exact next step."Output schema / properties / me / properties / label / descriptionAdded value: +"Human-readable name assigned to this token or connected app."Output schema / properties / me / properties / lastUsedAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Most recently recorded use as Unix epoch milliseconds, updated at minute granularity; null before any recorded use."Output schema / properties / me / properties / limits / descriptionAdded value: +"Configured rate-limit capacities, not remaining request balances. An HTTP 429 response supplies Retry-After."Output schema / properties / me / properties / limits / properties / account / descriptionAdded value: +"Shared request allowance across this business's tokens."Output schema / properties / me / properties / limits / properties / account / properties / burst / descriptionAdded value: +"Maximum requests accepted in a burst."Output schema / properties / me / properties / limits / properties / account / properties / perMinute / descriptionAdded value: +"Configured request rate per minute."Output schema / properties / me / properties / limits / properties / messages / descriptionAdded value: +"Agent-message allowance for this token."Output schema / properties / me / properties / limits / properties / messages / properties / burst / descriptionAdded value: +"Maximum requests accepted in a burst."Output schema / properties / me / properties / limits / properties / messages / properties / perMinute / descriptionAdded value: +"Configured request rate per minute."Output schema / properties / me / properties / limits / properties / reads / descriptionAdded value: +"Read-request allowance for this token."Output schema / properties / me / properties / limits / properties / reads / properties / burst / descriptionAdded value: +"Maximum requests accepted in a burst."Output schema / properties / me / properties / limits / properties / reads / properties / perMinute / descriptionAdded value: +"Configured request rate per minute."Output schema / properties / me / properties / limits / properties / writes / descriptionAdded value: +"Write-request allowance for this token."Output schema / properties / me / properties / limits / properties / writes / properties / burst / descriptionAdded value: +"Maximum requests accepted in a burst."Output schema / properties / me / properties / limits / properties / writes / properties / perMinute / descriptionAdded value: +"Configured request rate per minute."Output schema / properties / me / properties / scopes / descriptionAdded value: +"Permissions granted to this token. A missing scope does not mean the business lacks that capability."Output schema / properties / me / properties / tokenId / descriptionAdded value: +"Identifier of this access token, not its secret bearer value."workflow_runs17 fields changedOutput schema / properties / runs / descriptionPrevious value: -"Newest runs first."New value: +"Run history for the requested workflow, newest first. Empty means no runs are recorded. Queued or running is unfinished; inspect error and stepResults on failed or abandoned runs."Output schema / properties / runs / items / properties / error / descriptionAdded value: +"Reported failure or abandonment reason, or null when none is recorded."Output schema / properties / runs / items / properties / finishedAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Completion time as Unix epoch milliseconds, or null while unfinished."Output schema / properties / runs / items / properties / found / descriptionAdded value: +"New records attributed to this run. Use its id in leads_list.workflowRunId to inspect them."Output schema / properties / runs / items / properties / found / properties / contacts / descriptionAdded value: +"People first saved by this run."Output schema / properties / runs / items / properties / found / properties / leads / descriptionAdded value: +"Companies first saved by this run."Output schema / properties / runs / items / properties / headline / descriptionAdded value: +"Agent's summary of the run, or null before one is reported."Output schema / properties / runs / items / properties / startedAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Run start or queue time as Unix epoch milliseconds."Output schema / properties / runs / items / properties / stepResults / descriptionPrevious value: -"Per-step outcomes and linked review cards."New value: +"Reported steps with their latest outcomes, notes and review-card links; empty before any step reports."Output schema / properties / runs / items / properties / stepResults / items / properties / atAdded value: +{
+ "description": "When this step reported, as Unix epoch milliseconds.",
+ "type": "number"
+}Output schema / properties / runs / items / properties / stepResults / items / properties / gateUnmetAdded value: +{
+ "description": "True when a required approval step reported without a valid approval card as evidence.",
+ "type": "boolean"
+}Output schema / properties / runs / items / properties / stepResults / items / properties / noteAdded value: +{
+ "description": "Additional explanation, or null when omitted.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / runs / items / properties / stepResults / items / properties / outcomeAdded value: +{
+ "description": "Agent-reported outcome text; this is not a fixed status enum.",
+ "type": "string"
+}Output schema / properties / runs / items / properties / stepResults / items / properties / reviewItemIdAdded value: +{
+ "description": "Linked review card ID for review_get, or null when none was created.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / runs / items / properties / stepResults / items / properties / stepIdAdded value: +{
+ "description": "ID of the workflow step that reported this outcome.",
+ "type": "string"
+}Output schema / properties / runs / items / properties / stepResults / items / requiredAdded value: +[
+ "stepId",
+ "outcome",
+ "note",
+ "at",
+ "reviewItemId",
+ "gateUnmet"
+]Output schema / properties / runs / items / properties / workflowVersionAdded value: +{
+ "description": "Workflow revision captured for this run; it may differ from the current workflow version.",
+ "type": "number"
+}workflows_list13 fields changedOutput schema / properties / workflows / descriptionAdded value: +"Non-deleted workflows, including live, paused and proposed workflows; empty when none exist."Output schema / properties / workflows / items / properties / deliverToAdded value: +{
+ "description": "Configured delivery destination, or null when unset.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workflows / items / properties / description / descriptionAdded value: +"The recurring growth job this workflow performs."Output schema / properties / workflows / items / properties / nextRunAt / descriptionPrevious value: -"Unix epoch milliseconds."New value: +"Next scheduled run as Unix epoch milliseconds, or null when not scheduled."Output schema / properties / workflows / items / properties / requestedByAdded value: +{
+ "description": "Label of the person who requested the workflow.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workflows / items / properties / steps / items / properties / details / descriptionAdded value: +"Instructions for performing this step."Output schema / properties / workflows / items / properties / steps / items / properties / gate / descriptionAdded value: +"Optional human approval gate."Output schema / properties / workflows / items / properties / steps / items / properties / gate / properties / label / descriptionAdded value: +"Text identifying the approval gate."Output schema / properties / workflows / items / properties / steps / items / properties / gate / properties / on / descriptionAdded value: +"Whether this step requires human approval."Output schema / properties / workflows / items / properties / steps / items / properties / id / descriptionAdded value: +"Stable step ID used by run stepResults and workflow updates."Output schema / properties / workflows / items / properties / steps / items / properties / title / descriptionAdded value: +"The task this step performs."Output schema / properties / workflows / items / properties / urlAdded value: +{
+ "description": "Dashboard URL for opening this workflow.",
+ "type": "string"
+}Output schema / properties / workflows / items / properties / versionAdded value: +{
+ "description": "Current workflow revision; compare with a run's workflowVersion.",
+ "type": "number"
+}agent_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "status": {
+ "additionalProperties": true,
+ "description": "Agent liveness, activity and scheduled work.",
+ "properties": {
+ "lastActivityAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "lastTurnAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "nextWakeAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pendingWakes": {
+ "type": "number"
+ },
+ "running": {
+ "type": "boolean"
+ },
+ "sandbox": {
+ "description": "Sandbox lifecycle state, or none when no sandbox exists.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sandbox",
+ "lastActivityAt",
+ "running",
+ "lastTurnAt",
+ "pendingWakes",
+ "nextWakeAt"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+}blocklist_list3 fields changedInput schema / properties / cursor / descriptionAdded value: +"Opaque nextCursor from the previous blocklist_list result. Omit for the first page."Input schema / properties / limit / descriptionAdded value: +"Maximum block-list entries per page; default 50, range 1-200."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "addedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "addedBy": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Block-list entry ID for blocklist_remove.",
+ "type": "string"
+ },
+ "kind": {
+ "description": "Blocked identity type, such as domain, email or LinkedIn profile.",
+ "type": "string"
+ },
+ "reason": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "Origin of the block; unsubscribe entries cannot be removed.",
+ "type": "string"
+ },
+ "value": {
+ "description": "Normalized identity that must not be contacted.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "value",
+ "reason",
+ "source",
+ "addedBy",
+ "addedAt"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "description": "Pass to the next list call; null means the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "entries",
+ "nextCursor"
+ ],
+ "type": "object"
+}lead_get2 fields changedInput schema / properties / id / descriptionAdded value: +"Lead ID returned by leads_list or lead_get."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "lead": {
+ "additionalProperties": true,
+ "properties": {
+ "archetype": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "companyName": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "contact": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Primary contact, when available."
+ },
+ "contacts": {
+ "description": "Up to 50 contacts on a detail read.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "contactsTruncated": {
+ "description": "True when the contact cap was reached.",
+ "type": "boolean"
+ },
+ "createdAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "domain": {
+ "description": "Company website domain.",
+ "type": "string"
+ },
+ "fields": {
+ "description": "The customer's configured lead-column values.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "description": "Lead ID for lead_get and lead_update.",
+ "type": "string"
+ },
+ "runContactIds": {
+ "description": "Contacts saved by the filtered workflow run.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "Qualification or outreach state.",
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vertical": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "domain"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "lead"
+ ],
+ "type": "object"
+}leads_list5 fields changedInput schema / properties / cursor / descriptionAdded value: +"Opaque nextCursor from the previous leads_list result. Omit for the first page; keep the same filters."Input schema / properties / limit / descriptionAdded value: +"Maximum leads per page; default 50, range 1-100. Large records may shorten a page."Input schema / properties / status / descriptionAdded value: +"Optional status: qualified, drafted, declined, sent, replied, bounced or partially_sent. Omit for all statuses."Input schema / properties / workflowRunId / descriptionAdded value: +"Run ID returned by workflow_runs or workflow_run. Restricts results to leads linked to that run."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "leads": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "archetype": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "companyName": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "contact": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Primary contact, when available."
+ },
+ "contacts": {
+ "description": "Up to 50 contacts on a detail read.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "linkedinUrl": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "photoUrl": {
+ "description": "Sourced profile photo; use it when displaying a person.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "contactsTruncated": {
+ "description": "True when the contact cap was reached.",
+ "type": "boolean"
+ },
+ "createdAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "domain": {
+ "description": "Company website domain.",
+ "type": "string"
+ },
+ "fields": {
+ "description": "The customer's configured lead-column values.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "key": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "key",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "id": {
+ "description": "Lead ID for lead_get and lead_update.",
+ "type": "string"
+ },
+ "runContactIds": {
+ "description": "Contacts saved by the filtered workflow run.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "status": {
+ "description": "Qualification or outreach state.",
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "vertical": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "domain"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "nextCursor": {
+ "description": "Pass to the next list call; null means the last page.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "leads",
+ "nextCursor"
+ ],
+ "type": "object"
+}linkedin_person3 fields changedInput schema / properties / account / descriptionAdded value: +"Name of a connected LinkedIn account. Omit to inspect every connected account; one paced profile lookup per account."Input schema / properties / profile / descriptionAdded value: +"A linkedin.com/in/ profile URL or LinkedIn profile ID from the customer or a lead contact."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "accounts": {
+ "description": "Connection, invitation and conversation state per connected account.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "person": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Resolved LinkedIn person, or null when unresolved."
+ }
+ },
+ "required": [
+ "person",
+ "accounts"
+ ],
+ "type": "object"
+}results_get2 fields changedInput schema / properties / since / descriptionAdded value: +"Start of the reporting window as Unix epoch milliseconds. Omit for 24 hours; clamped to 1 hour through 31 days ago."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "results": {
+ "additionalProperties": true,
+ "properties": {
+ "ads": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "aeo": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "baseline": {
+ "additionalProperties": false,
+ "description": "Equal-length comparison window immediately before it.",
+ "properties": {
+ "from": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "to": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "from",
+ "to"
+ ],
+ "type": "object"
+ },
+ "email": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "harness": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "linkedin": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "outbound": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "reason": {
+ "type": "string"
+ },
+ "seo": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "skip": {
+ "description": "True when this account is excluded from reporting.",
+ "type": "boolean"
+ },
+ "social": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "caveats": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "data": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "data"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "reason"
+ ],
+ "type": "object"
+ }
+ ],
+ "description": "Unavailable is unknown, not zero. Read reason before interpreting the metric."
+ },
+ "window": {
+ "additionalProperties": false,
+ "description": "Actual reporting window after clamping.",
+ "properties": {
+ "from": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "to": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "from",
+ "to"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}review_get2 fields changedInput schema / properties / id / descriptionAdded value: +"Review card ID returned by review_list or review_get."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "item": {
+ "additionalProperties": true,
+ "description": "The requested review card.",
+ "properties": {
+ "actions": {
+ "description": "The exact action verbs this card accepts.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "createdAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "detail": {
+ "description": "Additional context, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Review card ID for review_get and review actions.",
+ "type": "string"
+ },
+ "kind": {
+ "description": "Card kind, such as approval, question or update.",
+ "type": "string"
+ },
+ "options": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Choices accepted by review_answer with action choose."
+ },
+ "payload": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Source-specific draft, evidence or decision data."
+ },
+ "primaryLabel": {
+ "description": "Label of the dashboard's primary action.",
+ "type": "string"
+ },
+ "prompt": {
+ "description": "The question or approval request.",
+ "type": "string"
+ },
+ "sourceType": {
+ "description": "The work that produced this card, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Current review state, including pending or needs_revision.",
+ "type": "string"
+ },
+ "summary": {
+ "description": "Short summary, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Short title of the proposed work or decision.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "sourceType",
+ "status",
+ "title",
+ "actions",
+ "primaryLabel"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "item"
+ ],
+ "type": "object"
+}review_list2 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum open cards to return; default 50, range 1-100. Includes pending and revising cards in one call."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "items": {
+ "description": "Open review cards, including revisions.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "actions": {
+ "description": "The exact action verbs this card accepts.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "createdAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "detail": {
+ "description": "Additional context, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Review card ID for review_get and review actions.",
+ "type": "string"
+ },
+ "kind": {
+ "description": "Card kind, such as approval, question or update.",
+ "type": "string"
+ },
+ "options": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "label",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Choices accepted by review_answer with action choose."
+ },
+ "payload": {
+ "anyOf": [
+ {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Source-specific draft, evidence or decision data."
+ },
+ "primaryLabel": {
+ "description": "Label of the dashboard's primary action.",
+ "type": "string"
+ },
+ "prompt": {
+ "description": "The question or approval request.",
+ "type": "string"
+ },
+ "sourceType": {
+ "description": "The work that produced this card, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Current review state, including pending or needs_revision.",
+ "type": "string"
+ },
+ "summary": {
+ "description": "Short summary, when available.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Short title of the proposed work or decision.",
+ "type": "string"
+ },
+ "updatedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "sourceType",
+ "status",
+ "title",
+ "actions",
+ "primaryLabel"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}whoami1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "me": {
+ "additionalProperties": false,
+ "description": "Connected business, token permissions and rate limits.",
+ "properties": {
+ "account": {
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "createdAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "inSetup": {
+ "type": "boolean"
+ },
+ "label": {
+ "type": "string"
+ },
+ "lastUsedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "limits": {
+ "additionalProperties": false,
+ "properties": {
+ "account": {
+ "additionalProperties": false,
+ "properties": {
+ "burst": {
+ "type": "number"
+ },
+ "perMinute": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "perMinute",
+ "burst"
+ ],
+ "type": "object"
+ },
+ "messages": {
+ "additionalProperties": false,
+ "properties": {
+ "burst": {
+ "type": "number"
+ },
+ "perMinute": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "perMinute",
+ "burst"
+ ],
+ "type": "object"
+ },
+ "reads": {
+ "additionalProperties": false,
+ "properties": {
+ "burst": {
+ "type": "number"
+ },
+ "perMinute": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "perMinute",
+ "burst"
+ ],
+ "type": "object"
+ },
+ "writes": {
+ "additionalProperties": false,
+ "properties": {
+ "burst": {
+ "type": "number"
+ },
+ "perMinute": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "perMinute",
+ "burst"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "reads",
+ "writes",
+ "messages",
+ "account"
+ ],
+ "type": "object"
+ },
+ "scopes": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "tokenId": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tokenId",
+ "label",
+ "scopes",
+ "createdAt",
+ "lastUsedAt",
+ "account",
+ "limits"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "me"
+ ],
+ "type": "object"
+}workflow_runs3 fields changedInput schema / properties / id / descriptionAdded value: +"workflowId returned by workflows_list or a workflow write."Input schema / properties / limit / descriptionAdded value: +"Maximum recent runs; default 10. The API caps at 50 even when a larger value is supplied."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "runs": {
+ "description": "Newest runs first.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "error": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "finishedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "found": {
+ "additionalProperties": false,
+ "properties": {
+ "contacts": {
+ "type": "number"
+ },
+ "leads": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "leads",
+ "contacts"
+ ],
+ "type": "object"
+ },
+ "headline": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Run ID for leads_list.workflowRunId.",
+ "type": "string"
+ },
+ "startedAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": "number"
+ },
+ "status": {
+ "description": "Run state, such as queued, running, done, failed or abandoned.",
+ "type": "string"
+ },
+ "stepResults": {
+ "description": "Per-step outcomes and linked review cards.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "id",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "runs"
+ ],
+ "type": "object"
+}workflows_list1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "workflows": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "name": {
+ "description": "Workflow name.",
+ "type": "string"
+ },
+ "nextRunAt": {
+ "description": "Unix epoch milliseconds.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "scheduleEcho": {
+ "description": "The interpreted schedule.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scheduleError": {
+ "description": "Why the schedule could not be interpreted.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scheduleText": {
+ "description": "The requested recurring schedule.",
+ "type": "string"
+ },
+ "status": {
+ "description": "Current lifecycle state, including live or paused.",
+ "type": "string"
+ },
+ "steps": {
+ "description": "Complete step list; preserve unchanged steps when replacing it.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "details": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "gate": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "on": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "on"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "details"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "workflowId": {
+ "description": "Workflow ID for updates, run history and run-now calls.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "workflowId",
+ "name",
+ "status",
+ "scheduleText",
+ "steps"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "workflows"
+ ],
+ "type": "object"
+}leads_list1 field changedInput schema / properties / workflowRunIdAdded value: +{
+ "type": "string"
+}linkedin_personagent_statusblocklist_listlead_getleads_listresults_getreview_getreview_listwhoamiworkflow_runsworkflows_listConnect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
Connect your AI assistant to Revensi OS agents, workflows, and business data.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Add one secure layer between your agents and this server.
