Skip to main content
Glama
Sign In

Salesbot - B2B outreach LinkedIn MCP Server with CRM and email

by cz.salesbot
OverviewDiscussionsAdmin

add_companies_to_crm

Idempotent

Create or update CRM company records. Pass prospect_company_ids for companies imported from LinkedIn, and/or companies for any company you found yourself (web search, read_company_website, the user's list) — no LinkedIn page needed, name is enough. Companies are matched to existing CRM records by name (ignoring case, diacritics and legal suffixes) or domain; matches only get empty fields filled, nothing is overwritten. Returns crm_company_id values; the company can exist in CRM before any contact is known.

Input Schema

NameRequiredDescriptionDefault
companiesNo
prospect_company_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / companies
      Added value: +{
+  "items": {
+    "properties": {
+      "headcount": {
+        "type": "number"
+      },
+      "industry": {
+        "type": "string"
+      },
+      "linkedin_url": {
+        "description": "LinkedIn company page URL, if known.",
+        "type": "string"
+      },
+      "location": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "notes": {
+        "description": "Account note, e.g. why the company fits.",
+        "type": "string"
+      },
+      "website": {
+        "description": "Company website URL.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "name"
+    ],
+    "type": "object"
+  },
+  "maxItems": 50,
+  "type": "array"
+}
    • removedInput schema / properties / prospect_company_ids / minItems
      Removed value: -1
    • removedInput schema / required
      Removed value: -[
-  "prospect_company_ids"
-]
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (idempotent, non-destructive), the description discloses the core matching semantics: matching by name (ignoring case/diacritics/legal suffixes) or domain, with matches only getting empty fields filled and nothing overwritten. It also states the return value (crm_company_id) and that a company can exist before any contact is known, richly explaining why the operation is idempotent and safe.

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

Conciseness4/5

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

Front-loaded with the core purpose, then parameter routing, then matching/return semantics — each sentence carries information. It is dense but every clause earns its place; a slightly tighter split would read better than the single long paragraph.

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

Completeness4/5

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

With no output schema, the description steps in to explain the return (crm_company_id values) and the matching/merge behavior, which is what an agent most needs to call this correctly. It leaves minor gaps (batch size limits, behavior when a company already fully matches), but is substantially complete.

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

Parameters4/5

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

Top-level schema description coverage is 0%, so the description carries the burden of explaining parameters — and it does: prospect_company_ids = LinkedIn imports, companies = self-sourced records where 'name is enough'. It adds genuine meaning beyond the bare schema, though it omits the maxItems caps (50/100) and the item field semantics.

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

Purpose5/5

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

The opening sentence states a specific verb+resource ('Create or update CRM company records'), and the following sentences scope the two input paths and the upsert/matching behavior. This lets an agent distinguish it from update_crm_company (single-record edit), get_crm_company, and add_contacts_to_crm without opening any schema.

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

Usage Guidelines4/5

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

It gives clear per-parameter usage guidance: use prospect_company_ids for LinkedIn-imported companies, and/or companies for self-sourced ones (web search, read_company_website, user list). It stops short of naming alternatives or explicit when-not-to-use conditions (e.g., vs update_crm_company or import_linkedin_company_list), so it lands below the top tier.

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

All Salesbot - B2B outreach LinkedIn MCP Server with CRM and email toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources