Skip to main content
Glama

Research

research

Run prospect and company research by finding LinkedIn profiles, emails, and company data, then save the findings to your records.

Instructions

Research

Run prospect/company research and save the results — the consolidated research tool.

Lookup actions (external providers — results are returned, not stored, unless noted):

  • find_linkedin: locate a person's LinkedIn URL (id = person UUID; payload optional {name_override?, company_override?, auto_save?} — auto_save stores a high-confidence match).

  • enrich_company: scrape a company website (payload = {domain, page_type?}).

  • find_email: find a work email (payload = {first_name, last_name, domain}).

  • linkedin_fetch: pull a LinkedIn profile (payload = {linkedin_url, include_company?, include_posts?, posts_limit?}).

  • careers_parse: parse a careers page for hiring signals (payload = {domain}).

Save actions (write research rows):

  • save_person: UPDATE research on an EXISTING person — pass the person UUID as payload.person_id (preferred; refreshes researched_at and the research fields in place), or matching email/linkedin anchors. Cannot create: new prospects go through manage_person action=save_discovered with payload.person + payload.assessment. Never pass the person UUID as id — this action takes no id.

  • save_company: atomically patch sourced public company research. Pass payload={idempotency_key, name, person_id?, website?, linkedin_url?, company_summary?, company_stage?, current_priorities?, funding_data?, growth_metrics?, sources_by_field}. Omitted fields are preserved; explicit null clears. When researching a specific person's employer, ALWAYS pass their UUID as payload.person_id — the response's person_link confirms the write landed on that person's linked company (repointing an anchorless duplicate link when needed); a mismatch status means the person's touches will NOT see this research, and a conflict status is a transient race — replay the identical payload (person_id is exempt from the idempotency hash, so adding it to a replay is the supported repair). sources_by_field must contain exactly every supplied non-null research field, with entries {url, title?, observed_at}. Example: {"idempotency_key":"pipeline/example.com/save-v1","name":"Example", "website":"https://example.com","company_summary":"Example sells …", "sources_by_field":{"company_summary":[{"url":"https://example.com/about", "title":"About","observed_at":"2026-07-30T20:00:00Z"}]}}.

Batch research: every action accepts the facade's backward-compatible request cap of 100 with per-item results (partial failure is reported per item, never silent). Operators should execute the smaller policy waves documented by pipeline-fill (10 companies or 5 people at a time) so progress and retries stay bounded. find_linkedin also takes person-id arrays. Payloads are validated by the underlying route's own schema.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoTarget entity id, or an ARRAY of ids to apply the same action+payload to each (max 100; see the tool description for which entity the id names per action).
itemsNoFor create-like actions only: an array of per-item payloads processed in order with per-item results (max 100). Mutually exclusive with `id` and `payload`.
actionYesThe operation to perform — see the tool description for the action vocabulary and each action's id/payload semantics.
payloadNoAction-specific fields, validated by the underlying route's own schema (a bad field 422s with that route's precise errors). See the tool description per action.
for_companyNoOptional company ID or name (UUID, or case-insensitive EXACT name match — partial / substring matches are NOT supported; ambiguous names raise 400) to execute this tool as. Use get_operator_overview with view='companies' to list available companies. Only needed if you manage multiple companies. Access is enforced server-side: the tool resolves the value to a user_company_id and verifies the caller's membership in `company_users` — a 403 'Company not found or access denied' means EITHER the value did not match a known company OR the caller is not a member of it. The MCP operator role itself is NOT auto-granted — operators get this access by being members of each client company via `company_users` (the same row that grants any normal user access).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.2.2

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare openWorldHint=true, readOnlyHint=false, destructiveHint=false. The description adds substantial behavioral detail: explicitly stating that lookup actions return results without storing them unless auto_save is set, explaining the idempotency_key mechanism for save_company, detailing conflict (transient race, replay payload) and mismatch (person won't see research) statuses, partial-failure semantics for batches, and warning that person_id must not be passed as id. This is rich operational context beyond what annotations provide.

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 long but densely structured with clear headers (Lookup actions / Save actions / Batch research), sub-bullets per action, an example block, and a response section. The length is justified by the large action vocabulary and per-action payload schemas. Minor deduction: some redundant phrasing could be trimmed, but the structure makes navigation efficient.

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 a tool with 8 distinct actions, mixed read/write behaviors, partial-failure semantics, idempotency, and cross-tool dependencies (manage_person, pipeline-fill), the description covers the essential operational surface thoroughly: per-action payload contracts, write semantics, error/status behaviors (mismatch, conflict, 403, 422), batch caps, and cross-references to related tools. No output schema exists, but the description covers response characteristics adequately.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds extensive per-action payload semantics: exact field lists for save_company (idempotency_key, name, person_id?, website?, etc.), find_email payload {first_name, last_name, domain}, linkedin_fetch payload {linkedin_url, include_company?...}, and a full worked JSON example with sources_by_field structure. The description clearly explains the id/payload/for_company parameter distinctions and the critical warning about save_person never taking id.

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 'Run prospect/company research and save the results — the consolidated research tool,' naming the specific verb (research/run) and resource (prospects/companies). It distinguishes itself from siblings by presenting itself as the consolidated research tool versus the individual get_* and manage_* tools, and the action vocabulary (find_linkedin, enrich_company, etc.) gives concrete operation names.

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?

The description explicitly separates lookup actions (returned, not stored) from save actions (write research rows), and gives precise when-to-use guidance for each action. It even names its sibling for creating prospects: 'new prospects go through manage_person action=save_discovered,' explicitly stating when NOT to use save_person and which alternative tool to use instead. Batch usage is also explained with specific caps (10 companies or 5 people).

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

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/vruum-gtm/mcp'

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