Skip to main content
Glama
mambalabsdev

mcp-contact-classifier

by mambalabsdev
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Contact Classifier MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

MCP server for the Mamba Labs Contact Classifier actor on Apify.

Give it a job title and it returns the department and the seniority level. Give it a name and a company domain too, and it also checks whether that person is still listed on their employer's own website. The classification is a deterministic rule table, so it needs no API key and returns the same answer for the same title every time.

Install

npx -y @mambalabsdev/mcp-contact-classifier

Claude Desktop

{
  "mcpServers": {
    "mamba-contact-classifier": {
      "command": "npx",
      "args": ["-y", "@mambalabsdev/mcp-contact-classifier"],
      "env": { "APIFY_TOKEN": "your-apify-token" }
    }
  }
}

Get an Apify token at console.apify.com/account/integrations.

Related MCP server: Company Discovery List Builder MCP Server

Tool

classify_contact

One contact in, one classified row out. Only the job title is required.

Input

Type

Required

Notes

job_title

string

yes

The contact's job title, exactly as you hold it. Classified by deterministic rules with no API key needed.

full_name

string

no

Only needed for position verification. Classification works without it. This name is never sent to any language model.

company_domain

string

no

Only needed for position verification. The company's website domain, with or without https.

verify_position

boolean

no

Check whether the person is still listed on their employer's own website. Adds roughly 3 seconds and 9 requests per contact, and needs both the name and the domain. Default false.

use_llm_fallback

boolean

no

Sends titles the rules cannot place to your own model, using the LLM_API_KEY secret environment variable on your own copy of the actor. Only the title is sent, never the person's name. Default false.

llm_provider

enum

no

openai, anthropic or google. Which provider your LLM_API_KEY belongs to. Only read when the LLM fallback is on. Default openai.

llm_model

string

no

Model id passed straight through to the provider. Only read when the LLM fallback is on. Default gpt-4o-mini.

skipCache

enum

no

Set to true to ignore cached results and classify from scratch. Default false.

Reading the output

21 flat snake_case fields, one row per contact. department is one of 12, seniority one of 12, and seniority_rank is 1 to 12 so a decision maker filter is a comparison rather than a list of strings. classification_rule names the rule that fired, which is what makes the decision auditable.

With no LLM_API_KEY set, titles the rules cannot place come back null. The row is still returned.

Billing

You are charged per contact classified, plus a small actor start fee. The deterministic classification calls no model and no third party API.

Pricing is on the actor's Apify page. Running this server consumes Apify credits.

What this server does and does not do

It is a thin client for the Apify actor. It passes your input through and returns the actor's output unchanged. Every behavior described above lives in the actor, not here.

This actor does not discover people. The name and title come from you. It classifies a title and, optionally, checks a name against a page the employer published. To find people in the first place, use People Finder.

Errors are surfaced, never swallowed. An invalid input, an invalid token, an exhausted balance, a timeout, or a run that returns anything other than a dataset all come back as an explicit tool error rather than as an empty result.

Source

The actor is on the Apify Store. This wrapper is MIT licensed.

Built by Mamba Labs

Available Tools

1 tool
classify_contactClassify ContactA
Read-onlyIdempotent

One contact in, one classified row out. Give it a job title and it returns the department, the seniority level, a seniority_rank from 1 to 12 you can filter with a comparison, and classification_rule, the named rule that fired, so every decision is auditable. The classification is a deterministic rule table: it needs no API key, calls no model, and returns the same answer for the same title every time. Only job_title is required. full_name and company_domain are read only when verify_position is on, which checks whether the person is still listed on their employer's own website and adds roughly 3 seconds and 9 requests per contact. The optional LLM fallback for titles the rules cannot place runs on your own key, set as the LLM_API_KEY secret environment variable on your own copy of the actor, and only the title is ever sent, never the person's name. With no key set those titles come back null rather than failing the row. This actor does not discover people: the name and title come from you. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

ParametersJSON Schema
NameRequiredDescriptionDefault
full_nameNoOnly needed for position verification. Classification works without it. This name is never sent to any language model.
job_titleYesThe contact's job title, exactly as you hold it. Classified by deterministic rules with no API key needed.
llm_modelNoModel id passed straight through to the provider. Only read when the LLM fallback is on. Default: "gpt-4o-mini".
skipCacheNoSet to true to ignore cached results and classify from scratch. Default: "false".
llm_providerNoWhich provider your LLM_API_KEY belongs to. Only read when the LLM fallback is on. Default: "openai".
company_domainNoOnly needed for position verification. The company's website domain, with or without https.
verify_positionNoCheck whether the person is still listed on their employer's own website. Off by default. Adds roughly 3 seconds and 9 requests per contact, and needs both the name and the domain. Default: false.
use_llm_fallbackNoOff by default. When on, titles the rules cannot place are sent to your own model using the LLM_API_KEY secret environment variable you set on your copy of this Actor. Only the title is sent, never the person's name. With no key set the Actor still returns a row, it just leaves those titles null. Default: false.

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, openWorld), the description reveals key behavioral traits: deterministic rule table (no API key, no model, same answer for same title), performance impact of verify_position (adds ~3 seconds and 9 requests), and privacy handling for LLM fallback (only title sent, never name). This is rich context that annotations do not cover.

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

Conciseness4/5

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

The description is longer than average but each sentence adds substantive information. It is front-loaded with the core purpose and then sequentially covers output, determinism, verification mode, LLM fallback, and limitations. While efficient, it could be slightly trimmed without losing value, so not a perfect 5.

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

Completeness5/5

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

The description fully contextizes the tool for an agent: it explains the output format (department, seniority, rank, rule), prerequisites (APIFY_TOKEN), constraints (not a discovery tool), edge cases (null results without LLM key), and cost implications (credits, requests). No output schema exists, so the description appropriately covers expected return values. This is complete for the tool's complexity.

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?

The input schema covers all 8 parameters with descriptions (100% coverage), giving baseline 3. The description adds relational meaning by noting that full_name and company_domain are only read when verify_position is on, and that job_title is the only required field. It also clarifies the skipCache and llm_model behavior implicitly, but does not fully explain each parameter; schema still carries most detail, so a 4 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's function with a specific verb and resource: 'One contact in, one classified row out' and 'Give it a job title and it returns the department, the seniority level, a seniority_rank... and classification_rule.' It leaves no ambiguity about what the tool does, and the 'does not discover people' note further distinguishes its scope.

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?

Provides explicit guidance on when to use the tool and what it does not do ('This actor does not discover people: the name and title come from you'). It also clarifies prerequisites (APIFY_TOKEN, credits), optional feature contexts (verify_position needs full_name and company_domain, LLM fallback requires a key), and fallback behavior when no key is set.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.0
    • First observedclassify_contact
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.8/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. Every call is unambiguously directed to classify_contact, making misselection impossible.

Naming Consistency5/5

The single tool name 'classify_contact' follows a clear verb_noun pattern and is descriptive. Consistency is trivially maintained when there is only one tool.

Tool Count4/5

The server is narrowly scoped to contact classification, and one tool covers the entire purpose. While below the typical 3-15 range, the focused design justifies the count, though it feels slightly thin.

Completeness5/5

The tool fully covers the classification operation: input a title, output department, seniority, rank, and classification rule. Optional verification and LLM fallback are integrated. No critical gaps or dead ends exist for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-contact-classifier'

If you have feedback or need assistance with the MCP directory API, please join our Discord server