Create and install an AI Website Salesperson for sales, qualification, and lead capture.
Scored across 6 tools
Most tools are clearly distinct: create, status, install, verify, configure, results. However, get_salesperson_installation and verify_salesperson_installation both relate to installation, and could be confused; get_salesperson_installation returns the script while verify checks detection, so descriptions help but some overlap exists.
All tools follow a consistent verb_noun pattern: check, configure, create, get, verify, all prefixed with salesperson. Minor deviation is that some use 'salesperson' as noun, others 'salesperson_installation' or 'salesperson_results', but the pattern is predictable and consistent.
With 6 tools, the surface is well-scoped for a single-purpose server (managing an AI salesperson). Each tool covers a necessary operation: create, configure, status, install, verify, results. No excessive redundancy or missing core functions.
The lifecycle is largely covered: create, configure, check status, install, verify, and get results. A minor gap is that there is no delete/remove tool, which might be expected, but the current set supports core workflows without dead ends. Agents can work around the missing delete by noting the salesperson is unclaimed or leaving it.
Find out whether a website salesperson has finished reading the website and is ready to talk to visitors, and whether its script has been detected on the live site. Give it the salesperson_id returned when the salesperson was created.
| Name | Required | Description | Default |
|---|---|---|---|
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
| Name | Required | Description |
|---|---|---|
| domain | No | |
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| installed | No | |
| ownership | Yes | |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| salesperson | Yes | |
| website_url | Yes | |
| last_seen_at | No | When the script was last seen loading. Null before installation. |
| salesperson_id | Yes | |
| detected_domains | No | |
| salesperson_name | Yes | |
| test_environment | No | |
| installation_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover the safety profile: read-only, idempotent, and non-destructive. The description adds the concrete things it checks, but does not disclose anything else about behavior or consequences. Since annotations carry most of the burden here, the added value is adequate but not outstanding.
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 concise, front-loaded with the purpose, and each sentence earns its place. It states what the tool checks and how to supply the ID without unnecessary details.
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 read-only status check with a fully documented schema, an output schema, and safety annotations, this description is sufficient. It could be slightly stronger by explicitly steering the agent away from sibling status/verification tools, but that is already accounted for in the usage dimension.
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 salesperson_id parameter is already clearly documented. The description repeats that the ID comes from creation, which is helpful but does not add meaningful semantic information beyond the schema.
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 outcome — checking whether the salesperson has finished reading the website and whether its script is detected on the live site. It is clear, but it does not explicitly distinguish itself from overlapping siblings like verify_salesperson_installation or get_salesperson_installation.
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 only instructs the agent to pass the salesperson_id returned at creation. It provides no guidance about when to prefer this tool over siblings such as verify_salesperson_installation or get_salesperson_results, and no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change a salesperson's name, its opening line, or the goal it works towards. While a salesperson is still unclaimed this can be set as part of setting it up. Once the website owner has claimed it, changes must be made by the owner in HeySale — do not ask anyone for an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| api_key | No | Developers only. Not required, and never ask a website owner for one. | |
| greeting | No | ||
| objective | No | What the salesperson should aim for. | |
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| message | No | |
| success | No | |
| updated | No | Which fields were changed. |
| ownership | Yes | |
| error_code | No | |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| salesperson | Yes | |
| website_url | Yes | |
| salesperson_id | Yes | |
| salesperson_name | Yes | |
| test_environment | No | |
| authentication_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: ownership state changes the permitted workflow, and API keys must not be requested from website owners. This goes well beyond the schema and complements the readOnlyHint=false and idempotentHint=true annotations without contradicting them.
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 focused sentences deliver the core purpose and the key usage boundary without repetition or filler. The most important information is front-loaded and every clause adds value.
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 description covers what the tool changes, when it should be used, when it should not be used, and how to handle API keys. An output schema exists, so return values do not need to be described. Given the tool's moderate complexity, nothing critical 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?
The description maps 'name', 'opening line', and 'goal' to the likely parameters name, greeting, and objective, adding meaning not fully explicit in the schema. The api_key and salesperson_id parameters are already documented in the schema, and the description reinforces the API key policy, though it does not explain every parameter.
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 action ('Change') and clearly identifies the resources being modified: the salesperson's name, opening line, and goal. It is easy to distinguish from sibling tools like create_website_salesperson or check_salesperson_status because it focuses on modifying an existing salesperson's configuration.
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 when-to-use guidance: configure while the salesperson is unclaimed, as part of setup. It also gives a when-not-to-use rule: once claimed, changes must be made by the owner in HeySale. It does not explicitly name an alternative tool like create_website_salesperson, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give any public website an AI salesperson that talks to its visitors, answers questions about the business, and captures leads. Use this when someone wants to add a salesperson, live chat, a sales assistant or a chatbot alternative to a site. Provide the website address; the salesperson reads the site itself. The response always includes an explicit salesperson_id — keep it, because every other HeySale tool needs it — plus the one-line install script and a claim_url to give the website owner. Safe to call twice for the same website. To try HeySale without touching a real website, use website_url https://hey.sale/mcp-test — that creates an isolated, disposable test salesperson on HeySale's own reviewer sandbox.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign | No | ||
| website_url | Yes | The public website address, e.g. https://example.com | |
| business_name | No | The business name, if known. | |
| integration_source | No | The AI platform making this call, e.g. claude, chatgpt, cursor, lovable, replit. | |
| external_project_id | No | A stable id for the calling project, so repeat calls reuse the same salesperson. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| reused | No | True when an existing salesperson for that website was returned instead of a new one. |
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| success | Yes | |
| ownership | Yes | |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| preview_url | No | |
| salesperson | Yes | |
| website_url | Yes | |
| free_minutes | No | |
| installation | Yes | |
| salesperson_id | Yes | |
| salesperson_name | Yes | |
| test_environment | No | |
| integration_source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which already state idempotent and non-destructive), the description adds meaningful behavior information: the response always includes a salesperson_id required by all other HeySale tools, the install script and claim_url, that it is safe to call multiple times for the same site, and that using https://hey.sale/mcp-test creates an isolated disposable test instance. These are concrete operational details an agent needs.
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 well-structured, front-loaded with the core purpose, and organized logically from 'what it does' to 'when to use' to 'what to expect in the response' to 'safety/test considerations'. It consists of six sentences, and each one adds meaningful information—no redundancy. It is slightly longer than absolutely necessary but fully deserves its length.
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 description adequately covers usage, output highlights, and the idempotent/safe test behavior. Since an output schema exists, it doesn't need to spell out every return field, but it still highlights the most critical ones. It also gives a workable test scenario, which is important for a tool that interacts with external websites. Minor gaps such as exact permissions or authentication details exist but are not required for calling the tool 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?
With schema coverage at 80%, the schema already documents most parameters adequately. The description adds only a slight clarification that website_url should be a public address and that the salesperson reads the site itself, but it doesn't elaborate on campaign or external_project_id beyond what the schema provides. Given the high schema coverage, the value added here is minimal and the baseline of 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 begins with a specific, action-oriented explanation: 'Give any public website an AI salesperson that talks to its visitors, answers questions about the business, and captures leads.' It clearly distinguishes itself from sibling tools like check_salesperson_status or configure_salesperson by focusing on creation and including actionable output details (salesperson_id, install script, claim_url).
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 explicitly says 'Use this when someone wants to add a salesperson, live chat, a sales assistant or a chatbot alternative to a site.' It also provides a safe test URL for trying without a real website. While it doesn't explicitly mention 'don't use this for existing salespersons—use configure instead', the context is clear that this is for creation and the sibling tool names make the alternatives obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact one-line script to add to a website so its salesperson appears for visitors, plus where to place it and whether HeySale has detected it yet. Give it the salesperson_id returned when the salesperson was created.
| Name | Required | Description | Default |
|---|---|---|---|
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| ownership | Yes | |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| preview_url | No | |
| salesperson | Yes | |
| website_url | Yes | |
| installation | Yes | |
| salesperson_id | Yes | |
| salesperson_name | Yes | |
| test_environment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only/idempotent and non-destructive; the description adds relevant behavioral detail by stating the output (script text, placement, detection status) and implying no side effects. It does not cover edge cases like unknown IDs, but this is minor for a getter.
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 sentences, front-loaded with the object and action, no fluff. The key output details, script, placement, and detection status, are packed into one efficient sentence.
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 simple read-only retrieval tool, the description covers what is returned, where the input comes from, and the primary use case. It stops short of noting error behavior or what happens if the ID is invalid/not yet installed, but the output schema likely fills that gap. Complete enough for most agent use.
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?
Input-schema coverage is 100% and the schema already explains that salesperson_id comes from create_website_salesperson. The description repeats this instructional intent without adding new parameter semantics, so the baseline of 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 clearly states a specific resource ('exact one-line script') and the expected output (script, placement, detection status). It is less explicit about how this differs from siblings like verify_salesperson_installation and check_salesperson_status, though the tool name helps disambiguate.
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?
Provides clear context: the tool is for retrieving the installation script for a website, and it tells the agent the required input (the salesperson_id returned at creation). It does not explicitly say when not to use it or name alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarise how many visitors talked to the salesperson, how many left their details, and what they asked about most. This is private business data: it is only returned to an authorised caller. Never ask a website owner for an API key — send them to HeySale instead.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| api_key | No | Developers only. Not required for setup, and never ask a website owner for one. | |
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| leads | No | |
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| ownership | Yes | |
| synthetic | No | True when the figures come from the reviewer sandbox. |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| period_days | No | |
| salesperson | Yes | |
| website_url | Yes | |
| recent_leads | No | |
| talk_minutes | No | |
| conversations | No | |
| top_questions | No | |
| salesperson_id | Yes | |
| conversion_rate | No | |
| salesperson_name | Yes | |
| test_environment | No | |
| authentication_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond the annotations: the data is private business data and is only returned to an authorized caller, and the agent must not request an API key from a website owner. No contradiction with 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?
Three sentences with no filler: the first states what the tool does, the other two convey security/authorization context. The api_key caution is slightly redundant with the schema's own api_key description, but the whole text is compact and front-loaded with the core 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?
Given that an output schema exists, the description does not need to explain the return shape. It provides the key behavioral gotcha (private data, authorized caller) and the sibling distinction is inferred. The days parameter lacks an example or default, but the schema maximum/minimum bounds suffice for correct calling.
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 67%, and the schema already documents salesperson_id and api_key well, including that the api_key is developers-only. The description adds some meaning by framing the API key context (private data, authorized caller, never ask the website owner), but does not explain about the days parameter, so it only partially supplements the schema.
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 verb ('Summarise') and resource (what the salesperson achieved: visitors talked, details left, top topics asked about). It clearly distinguishes itself from sibling tools like check_salesperson_status or get_salesperson_installation, which cover status or installation rather than performance results.
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 provides clear context: use it when you need a summary of salesperson results, with the important caution that this is private data only for authorized callers. It does not explicitly name when to use an alternative sibling, but the security guidance (never ask a website owner for an API key) is a clear behavioral constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a HeySale salesperson has actually been installed on its website and is reporting back to HeySale. Uses HeySale's own telemetry, so it works with single-page apps, tag managers and deferred script loading — never scrape the website's HTML to answer this. Give it the salesperson_id returned when the salesperson was created.
| Name | Required | Description | Default |
|---|---|---|---|
| salesperson_id | Yes | The salesperson_id returned by create_website_salesperson. |
| Name | Required | Description |
|---|---|---|
| domain | No | |
| status | Yes | Build state of the salesperson, e.g. analyzing, building, ready, failed. |
| message | No | |
| installed | No | |
| ownership | Yes | |
| expires_at | No | |
| environment | No | |
| next_action | No | Plain-language next step for the caller. |
| salesperson | Yes | |
| website_url | Yes | |
| last_seen_at | No | When the script was last seen loading. Null before installation. |
| salesperson_id | Yes | |
| detected_domains | No | |
| salesperson_name | Yes | |
| test_environment | No | |
| installation_status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral detail: it relies on HeySales telemetry, works across modern tag-manager setups, and explicitly warns against scraping. This goes beyond the annotations without contradicting them.
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 sentences carry a clear purpose, a scoping instruction, and an explicit anti-pattern warning. Every clause earns its place and the core action is front-loaded.
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 simple verification tool with one parameter, the description covers what it checksाक and how it checks it. It does not describe the return value, but no output schema was provided; still, the phrasing 'has actually been installed and is reporting back' strongly implies a boolean result.
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 input schema fully documents the single UUID parameter, so baseline is 3. The description adds the useful provenance detail that salesperson_id comes from creation-time response, which helps the agent know where to source the value.
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 action—'Check whether a HeySales salesperson has actually been installed on its website and is reporting back to HeySales'—which makes the tool's purpose unmistakable. It also distinguishes this verification goal from a generic status lookup by emphasizing actual installation and reporting.
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 operational guidance: use HeySales' telemetry rather than scraping, and handle SPA/tag manager/deferred loading scenarios. It does not explicitly contrast this tool with siblings like get_salesperson_installation or check_salesperson_status, so the differentiation is implicit rather than named.
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.
check_salesperson_status1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "detected_domains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "environment": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "installation_status": {
+ "enum": [
+ "detected",
+ "not_detected",
+ "domain_mismatch",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "installed": {
+ "type": "boolean"
+ },
+ "last_seen_at": {
+ "description": "When the script was last seen loading. Null before installation.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership"
+ ],
+ "type": "object"
+}configure_salesperson1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "authentication_required": {
+ "type": "boolean"
+ },
+ "environment": {
+ "type": "string"
+ },
+ "error_code": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "success": {
+ "type": "boolean"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "updated": {
+ "description": "Which fields were changed.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership"
+ ],
+ "type": "object"
+}create_website_salesperson1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "environment": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "free_minutes": {
+ "type": "number"
+ },
+ "installation": {
+ "additionalProperties": {},
+ "properties": {
+ "async": {
+ "type": "boolean"
+ },
+ "detection": {
+ "type": "string"
+ },
+ "installation_status": {
+ "description": "What HeySale's own telemetry currently sees.",
+ "enum": [
+ "detected",
+ "not_detected",
+ "domain_mismatch",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "placement": {
+ "type": "string"
+ },
+ "review_install_url": {
+ "description": "Sandbox only: expiring link that installs the test salesperson.",
+ "type": "string"
+ },
+ "script": {
+ "description": "The one-line script to add to the website before the closing body tag.",
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "integration_source": {
+ "type": "string"
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "preview_url": {
+ "type": "string"
+ },
+ "reused": {
+ "description": "True when an existing salesperson for that website was returned instead of a new one.",
+ "type": "boolean"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "success": {
+ "type": "boolean"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "success",
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership",
+ "installation"
+ ],
+ "type": "object"
+}get_salesperson_installation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "environment": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "installation": {
+ "additionalProperties": {},
+ "properties": {
+ "async": {
+ "type": "boolean"
+ },
+ "detection": {
+ "type": "string"
+ },
+ "installation_status": {
+ "description": "What HeySale's own telemetry currently sees.",
+ "enum": [
+ "detected",
+ "not_detected",
+ "domain_mismatch",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "placement": {
+ "type": "string"
+ },
+ "review_install_url": {
+ "description": "Sandbox only: expiring link that installs the test salesperson.",
+ "type": "string"
+ },
+ "script": {
+ "description": "The one-line script to add to the website before the closing body tag.",
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "preview_url": {
+ "type": "string"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership",
+ "installation"
+ ],
+ "type": "object"
+}get_salesperson_results1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "authentication_required": {
+ "type": "boolean"
+ },
+ "conversations": {
+ "type": "number"
+ },
+ "conversion_rate": {
+ "type": "number"
+ },
+ "environment": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "leads": {
+ "type": "number"
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "period_days": {
+ "type": "number"
+ },
+ "recent_leads": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "captured_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "company": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "email": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "interest": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "question": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "synthetic": {
+ "description": "True when the figures come from the reviewer sandbox.",
+ "type": "boolean"
+ },
+ "talk_minutes": {
+ "type": "number"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "top_questions": {
+ "items": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "theme": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ ]
+ },
+ "type": "array"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership"
+ ],
+ "type": "object"
+}verify_salesperson_installation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "detected_domains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "domain": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "environment": {
+ "type": "string"
+ },
+ "expires_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "installation_status": {
+ "enum": [
+ "detected",
+ "not_detected",
+ "domain_mismatch",
+ "unknown"
+ ],
+ "type": "string"
+ },
+ "installed": {
+ "type": "boolean"
+ },
+ "last_seen_at": {
+ "description": "When the script was last seen loading. Null before installation.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "next_action": {
+ "description": "Plain-language next step for the caller.",
+ "type": "string"
+ },
+ "ownership": {
+ "additionalProperties": {},
+ "properties": {
+ "claim_url": {
+ "description": "One-time link the website owner uses to claim the salesperson. Absent once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "manage_url": {
+ "description": "Where the owner manages the salesperson. Present once claimed.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "Whether a HeySale account owns this salesperson yet.",
+ "enum": [
+ "unclaimed",
+ "claimed"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "status"
+ ],
+ "type": "object"
+ },
+ "salesperson": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "id": {
+ "description": "The salesperson_id.",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name"
+ ],
+ "type": "object"
+ },
+ "salesperson_id": {
+ "type": "string"
+ },
+ "salesperson_name": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Build state of the salesperson, e.g. analyzing, building, ready, failed.",
+ "type": "string"
+ },
+ "test_environment": {
+ "type": "boolean"
+ },
+ "website_url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "salesperson",
+ "salesperson_id",
+ "salesperson_name",
+ "website_url",
+ "status",
+ "ownership"
+ ],
+ "type": "object"
+}check_salesperson_status1 field changedInput schema / properties / salesperson_id / descriptionPrevious value: -"The id returned when the salesperson was created."New value: +"The salesperson_id returned by create_website_salesperson."configure_salesperson3 fields changedInput schema / properties / api_key / descriptionPrevious value: -"The owner's HeySale API key, from their dashboard."New value: +"Developers only. Not required, and never ask a website owner for one."Input schema / properties / salesperson_id / descriptionAdded value: +"The salesperson_id returned by create_website_salesperson."Input schema / requiredPrevious value: -[
- "salesperson_id",
- "api_key"
-]New value: +[
+ "salesperson_id"
+]create_website_salesperson1 field changedInput schema / properties / integration_source / descriptionPrevious value: -"The platform making this call, e.g. lovable."New value: +"The AI platform making this call, e.g. claude, chatgpt, cursor, lovable, replit."get_salesperson_installation1 field changedInput schema / properties / salesperson_id / descriptionAdded value: +"The salesperson_id returned by create_website_salesperson."get_salesperson_results3 fields changedInput schema / properties / api_key / descriptionPrevious value: -"The owner's HeySale API key, from their dashboard."New value: +"Developers only. Not required for setup, and never ask a website owner for one."Input schema / properties / salesperson_id / descriptionAdded value: +"The salesperson_id returned by create_website_salesperson."Input schema / requiredPrevious value: -[
- "salesperson_id",
- "api_key"
-]New value: +[
+ "salesperson_id"
+]verify_salesperson_installationcheck_salesperson_statusconfigure_salespersoncreate_website_salespersonget_salesperson_installationget_salesperson_resultsAI support employee for any website: learns the site, answers visitors by chat and voice.
Run your website's AI support agent: knowledge, conversations, leads and live replies.
Create and manage website chatbots for European SMBs: bots, chat, and captured leads.
Create and manage website chatbots for European SMBs: bots, chat, and captured leads.
Add one secure layer between your agents and this server.
