Skip to main content
Glama
ProspectAPIs

prospectapis-mcp

Official
by ProspectAPIs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

research_submit

Generate a cited prospect research brief: submit a domain, email, or name, then poll research_get until complete.

Instructions

Start a cited pre-call research brief on one prospect: company, funding, traction, competitors, news, people, risks, regions, plus a fit section when you pass context. Give exactly ONE identifier (domain, website_url, company_name, company_linkedin_url, a work email, or linkedin_url), or person_name together with company_name. Returns research_id at once; the brief takes 20 to 90 seconds, so poll research_get every 10 to 15 seconds until status is completed or failed. Costs one research at the price account_balance reports as research_price_usd, held when you submit, charged only when the brief completes and refunded in full if it fails. Free records do not apply.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNoA work email; its domain identifies the company. Free-mail addresses are refused.
domainNoThe company's domain, for example `acme.com`.
contextNoYour own product, at most 1,000 characters. Turns on the `fit` section.
purposeNoWhat the brief is for: `account_research` (default), `pre_call` (objections, discovery questions) or `outreach` (sourced hooks with draft first lines).
person_nameNoA person's name; needs company_name as well.
website_urlNoAny http(s) URL on the company's website.
company_nameNoThe company's name. With person_name, the company that person works at.
linkedin_urlNoA person's linkedin.com/in/... URL, used as a name hint only.
company_linkedin_urlNoThe company's linkedin.com/company/... URL, used as a name hint only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare non-read-only, non-destructive, open-world, but the description carries the substantive behavioral load: async 20-90s latency, polling cadence, and a full billing model (price from account_balance's research_price_usd, held on submit, charged on completion, refunded on failure, no free records).

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-loads the deliverable, then identifier rules, then async/polling behavior, then cost. Dense but every sentence carries operational information; the cost sentence is long though justified since no annotation covers billing.

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?

With no output schema, the description specifies the return value (research_id immediately, brief later) and the terminal statuses, plus timing and cost. An agent has everything needed to invoke and to follow up correctly.

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 the baseline would be 3, but the description adds semantic constraints the schema cannot express: the mutually exclusive identifier set and the person_name/company_name pairing requirement. The `context` parameter's role in enabling the `fit` section is also restated usefully.

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?

States a specific verb and resource ('start a cited pre-call research brief on one prospect') and enumerates the brief's contents. It is clearly distinguishable from the sibling research_get, which it explicitly routes to for polling.

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?

Gives precise input rules (exactly ONE identifier, or person_name + company_name) and the operational loop: poll research_get every 10-15 seconds until status is completed or failed. The alternative tool and the condition that selects it are both named.

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

Deploy Server

Other Tools