Skip to main content
Glama
Wism-Corp

Scrupp MCP server

Official

Find work emails

scrupp_find_emails
Idempotent

Find and verify work email addresses using first name, last name, and company domain. Unverified addresses are flagged, not guessed.

Instructions

Find and verify work email addresses from first name, last name and company domain. Addresses that cannot be verified come back marked rather than guessed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
peopleYes
wait_secondsNoHow long to wait for the job before returning its id instead (default 120).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.3

TDQS

B3.3/5.0
Behavior3/5

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

The description usefully discloses an output-quality behavior: unresolvable addresses are returned marked rather than guessed. But it is silent on the operational realities implied by readOnlyHint=false and the wait_seconds parameter — that this submits an asynchronous job, may consume credits, and that results may come back as a job id.

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

Conciseness5/5

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

Two tight sentences, zero filler, with the core purpose front-loaded and the caveat about unverifiable addresses placed second where it belongs.

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

Completeness3/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 carries the burden of explaining returns; it does partially (marked results) but omits the async job model and how to retrieve results, despite wait_seconds implying a job id may be returned instead of data. Sibling scrupp_get_job exists and is never referenced.

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

Parameters3/5

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

At 50% schema coverage, the description names the three nested person fields (first name, last name, domain) but adds no format or constraint detail beyond the schema's domain example. It says nothing about the wait_seconds parameter or about passing multiple people in the array.

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

Purpose4/5

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

The description gives a specific verb pair and resource ('find and verify work email addresses') plus the required inputs (first name, last name, company domain). However it does not distinguish itself from the sibling scrupp_verify_emails, which also deals with verification, so an agent can't tell them apart from the text alone.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given. The presence of 'verify' in the description while a sibling tool is literally named scrupp_verify_emails creates ambiguity that the description does nothing to resolve, and no alternative (e.g., scrupp_find_decision_makers) is mentioned.

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