Skip to main content
Glama
Sign In

DealMachine

by io.github.DealMachine
OverviewDiscussionsAdmin

dealmachine_enrich_name

Destructive

Finds people by name: one last_name, optionally with first_name and middle_initial, or up to 250 names in data sharing location, pagination and options. A location narrows the match. Returns paginated people with contact information including phones and emails; include_properties=true adds the properties associated with them. estimate_cost=true returns people and associated-property counts without records or credit use. Needs a connected DealMachine account with paid access. Each returned person costs one people credit and associated properties cost property credits; batching reduces requests, not credits.

Input Schema

NameRequiredDescriptionDefault
dataNoBatch of name lookups sharing location, fields and pagination. Prefer batching multiple requested lookups.
pageNoPage number (default: 1)
fieldsNoDealMachine field IDs; people fields return on each person, while property fields return under property and may cost a property credit
locationNoOptional match location by state, ZIP, county, or numeric city place ID
per_pageNoResults per page (default: 25, max: 100)
last_nameNoLast name (required for a single lookup)
first_nameNoFirst name to narrow results
estimate_costNoPreview people counts and, when include_properties=true, associated property counts and estimated credits without returning data or consuming credits
middle_initialNoMiddle initial (single character) to narrow results
include_propertiesNoInclude associated properties for each person. Costs 1 property data credit per property.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / data
      Added value: +{
+  "description": "Batch of name lookups sharing location, fields and pagination. Prefer batching multiple requested lookups.",
+  "items": {
+    "properties": {
+      "first_name": {
+        "type": "string"
+      },
+      "last_name": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "middle_initial": {
+        "maxLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "last_name"
+    ],
+    "type": "object"
+  },
+  "maxItems": 250,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / properties / last_name / description
      Previous value: -"Last name (required)"New value: +"Last name (required for a single lookup)"
    • removedInput schema / required
      Removed value: -[
-  "last_name"
-]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare readOnly=false/destructive=true/idempotent=false; the description adds the real behavioral context: a paid DealMachine account is required, each returned person costs one people credit, associated properties cost property credits, estimate_cost consumes no credits, and batching reduces requests but not credits. That is meaningful context beyond the annotations, though it never explicitly explains the write/destructive surface implied by destructiveHint=true.

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 action and mode split, then returns, then cost/auth constraints. Content is dense but every sentence carries information; the phrase 'or up to 250 names in data sharing location, pagination and options' is slightly garbled but still readable.

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 compensates by describing return shape (paginated people with phones and emails, optional attached properties) and by covering auth, credit economics, and the estimate-cost preview. For a 10-parameter, nested-object enrichment tool this is close to complete; only error/pagination edge behavior is unaddressed.

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 baseline is 3, but the description adds cost semantics the schema does not carry: include_properties=true returns associated properties and costs property credits, and estimate_cost=true returns counts without records or credit use. It also frames the data array as a shared-location batch, which is more than a parameter restatement.

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?

Opens with a specific verb and resource ('Finds people by name') and immediately distinguishes the lookup mode (single last_name with optional first_name/middle_initial) from the batch mode (up to 250 names in data). This clearly separates it from sibling enrichment tools such as enrich_email and enrich_phone.

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?

Gives clear selection guidance between single lookup, batch, adding a location to narrow, and estimate_cost=true as a dry run. It does not name the other people-oriented siblings (people_search, people_count, people_get) as alternatives, so exclusions remain implicit rather than explicit.

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

All DealMachine 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