Skip to main content
Glama

Create deal

create_deal

A deal needs a person or a company (or both). Link someone Sliq already knows by id (query_people / query_companies), or pass new_person / new_company to add them. If the person already has an open deal this refuses and names it — update that deal instead, unless the user wants a second one (then pass allow_duplicate=true). The created deal, same shape as a query_deals row.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_deal"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesDeal name, e.g. "Acme - pilot". Usually the company name.
notesNoFree-text notes.
stageNoPipeline stage by name or id (query_deals lists them). Default: the first stage.
amountNoDeal value as a plain number, e.g. 12000.
person_idNoThe contact, as a query_people `id`.
company_idNoThe company, as a query_companies `id`.
new_personNoA contact to add: name plus email, linkedin_slug (their LinkedIn slug or profile URL) or linkedin_provider_id. Used instead of person_id.
new_companyNoA company to add: name plus domain. Used instead of company_id.
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
assignee_emailNoThe owner, an active teammate's email from list_teammates (not an invited one). Default: the user.
allow_duplicateNoCreate even if this person already has an open deal.
expected_close_dateNoYYYY-MM-DD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed2 schema fields changed
    • changedInput schema / properties / new_person / anyOf
      Previous value: -[
      -  {
      -    "description": "A contact not yet in Sliq. Needs an email or a LinkedIn URL; an existing person with the\nsame email/LinkedIn is reused, not duplicated.",
      -    "properties": {
      -      "email": {
      -        "default": "",
      -        "type": "string"
      -      },
      -      "linkedin_url": {
      -        "default": "",
      -        "type": "string"
      -      },
      -      "name": {
      -        "default": "",
      -        "type": "string"
      -      }
      -    },
      -    "title": "NewPerson",
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "description": "A contact not yet in Sliq. Needs an email, a LinkedIn slug (or profile URL) or a LinkedIn\nprovider id; an existing person with the same email/LinkedIn is reused, not duplicated.",
      +    "properties": {
      +      "email": {
      +        "default": "",
      +        "type": "string"
      +      },
      +      "linkedin_provider_id": {
      +        "default": "",
      +        "description": "The contact's LinkedIn provider id (ACoAA…), if known.",
      +        "type": "string"
      +      },
      +      "linkedin_slug": {
      +        "default": "",
      +        "type": "string"
      +      },
      +      "name": {
      +        "default": "",
      +        "type": "string"
      +      }
      +    },
      +    "title": "NewPerson",
      +    "type": "object"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / new_person / description
      Previous value: -"A contact to add: name plus email or LinkedIn URL. Used instead of\nperson_id."New value: +"A contact to add: name plus email, linkedin_slug (their LinkedIn slug or\nprofile URL) or linkedin_provider_id. Used instead of person_id."
  3. Changed1 schema field changed
    • changedInput schema / properties / amount / anyOf
      Previous value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "pattern": "^(?!^[-+.]*$)[+-]?0*\\d*\\.?\\d*$",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  4. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  5. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations only declare write/non-destructive; the description adds real behavior: team-wide visibility on the Deals view, a hard refusal on duplicate open deals with an override flag, and an explicit note that the return value matches a query_deals row. It does not cover credit consumption or permission requirements for on_behalf_of, but the schema carries those.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short labeled blocks with the core purpose front-loaded and the return contract separated out; every sentence carries information. Minor redundancy exists where the summary restates the new_person / new_company rules already spelled out in the nested schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter mutation with no output schema, the definition covers the two things an agent most needs: identity requirements and the duplicate-refusal path, plus a pointer to the return shape. The gap is the unstated failure mode when neither person nor company is supplied, and that neither field is in the required list.

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

Parameters4/5

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

Schema coverage is 100%, so the 3 baseline is met by the schema alone. The description still adds cross-parameter meaning the schema does not state: person_id and new_person are mutually exclusive alternatives, at least one of person/company is effectively required, and allow_duplicate gates the duplicate check.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Create a deal in the user's CRM pipeline") and frames it with a concrete consequence: "this is how a person or company gets into the CRM" and "shows up on the Deals view for the whole team." That distinguishes it cleanly from update_deal and query_deals.

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

Usage Guidelines5/5

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

Gives explicit prerequisites ("A deal needs a person or a company (or both)") and routes the agent to siblings: query_people / query_companies to link by id, or new_person / new_company to add. It also names the fallback path — if the person has an open deal, "update that deal instead" — and the exact escape hatch (allow_duplicate=true) when the user wants a second one.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources