Skip to main content
Glama
Sign In

Iris

by io.github.JCLVSH
OverviewDiscussionsAdmin

search_contacts

kick off a multi-source contact discovery job (Apify-backed). returns a job_id and contacts when ready (waits up to 90s; if status=queued, poll get_discovery_job). closed source list: google_maps, instagram, twitter, tiktok, reddit. requires generate scope.

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": {
      "keywords": "<keywords>"
    },
    "name": "search_contacts"
  }
}

Input Schema

NameRequiredDescriptionDefault
sourcesNooverride the default per-profile_type source mix. valid: google_maps, instagram, twitter, tiktok, reddit. omit to let the orchestrator pick.
keywordsYesnon-empty array of search keywords (e.g. ['boutique hotel', 'rooftop venue'])
locationNolocation for geo-scoped goals (local_business / venue / brick-and-mortar). omit for global goals (creators, b2b, saas).
campaign_idNocampaign to attach discovered contacts to on finalize
max_resultsNomax contacts to return (10-500, default 50; server clamps to plan cap)
profile_typeNoICP profile type — drives default source mix when sources is omitted
radius_milesNosearch radius in miles (default 25)
enrich_emailsNorun waterfall email enrichment (BetterContact → FullEnrich → ZeroBounce). default true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and destructiveHint=false, which is a weak signal. The description adds real behavioral context: the call waits up to 90 seconds, may come back asynchronously as queued, needs the generate scope, and runs a waterfall of external providers. It does not state cost, quota, or what happens on partial failure.

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?

It is a single dense paragraph, front-loaded with the verb and outcome. It avoids waste and puts the async caveat early. Slight terseness ('closed source list') and missing punctuation make it marginally harder to scan than it could be.

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?

For an 8-parameter discovery job with no output schema, the description covers the return values (job_id and contacts), the async polling path, the latency bound, the auth scope, and the source constraints. An agent has what it needs to call this correctly and handle the response.

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?

Schema coverage is 100%, so every parameter is already documented in the schema. The description restates the closed source enum (already in the schema) and adds little syntax or semantics beyond it. A baseline 3 is appropriate because the schema carries the parameter burden.

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 and resource ('kick off a multi-source contact discovery job') plus the backend it uses (Apify) and the return shape (job_id, contacts). It differentiates itself from the polling sibling get_discovery_job, though it never contrasts itself with search_campaign_contacts or list_contacts, so an agent still has to infer when to use this instead of those.

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

Usage Guidelines3/5

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

It gives one explicit branching rule: if status=queued, poll get_discovery_job. It also notes 'requires generate scope'. However, there is no guidance on when to use this search versus search_campaign_contacts or bulk_import_contacts, and no exclusion cases are stated. Usage is implied rather than fully mapped.

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

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