Skip to main content
Glama

Build a prospect picture

prospect_picture
DestructiveIdempotent

One picture of a person, a company, or both, for goal-style asks: who to contact, how to approach them, angles, what's changed, and why now. Optional audience (3–2,000 characters) orders why_now for your goal when checks are available; otherwise dated reasons remain newest first. ranking.by discloses goal or recency; ranking.why_now_judged counts judged reasons at the front of the top 20. Judged-no reasons leave only why_now; datapoints, claims and facts remain. The goal changes neither parts, budget admission nor charges. depth quick = verified contact and current intent signals; standard adds the company profile and funding and source-backed research; deep adds the person's recent LinkedIn posts and deep research. Returns an operation_id to poll with get_operation using the same data:read scope; the finished result has typed datapoints, research claims that each cite a source and a verbatim excerpt, why_now, every component's status with its reason, and the exact cost. Reserves the planner's maximum once and settles once: each completed component at its own verb's price plus a 3-credit assembly fee when data is returned. Eligible pooled research is selected during execution and costs 40% of its equivalent fresh component, so the discount may or may not apply after a dry-run quote; the quoted maximum never increases. An ambiguous provider outcome keeps the whole parent reservation held for operator reconciliation. budget_credits skips components that do not fit, in order, and refuses below the minimum. dry_run: true returns the plan and maxima as of evaluated_at with nothing reserved. idempotency_key is required; reuse it only to retry creation of the same picture.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNostandard
personNo
dry_runNo
audienceNo
budget_creditsNo
company_domainNoCompany website domain or URL, e.g. acme.com or https://www.acme.com/about
idempotency_keyYesA payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."New value: +"A payment_required refusal means services are stopped for unpaid billing; direct the owner to the billing link in the error. Campaigns stay paused after payment until restarted. Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  2. Changed1 schema field changed
    • addedInput schema / properties / audience
      Added value: +{
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional for search and enrichment tools: supply one to make a retry replay the original result. Required for tools that create an external side effect; reuse the same value after a timeout or an approval."New value: +"Optional for search and enrichment tools: supply one so a retry returns the original result without paying again; if that call failed with provider_unavailable, rate_limited or insufficient_credits (after a top-up), a retry runs it once more after its cooldown (30 s, or a longer retry_after_seconds; insufficient_credits as soon as the balance covers it), unless its provider may already have done the work. Required for tools that create an external side effect; reuse the same value after a timeout or an approval. A stored failure comes back with details.replayed: true; with retry_after_seconds, retry the same value after that."
  4. Added

TDQS

A3.9/5.0
Behavior5/5

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

With annotations already declaring destructive/idempotent/open-world, the description still adds substantial behavior: reservation of the planner maximum and single settlement, the 3-credit assembly fee, the 40% pooled-research discount and its uncertainty after a dry-run, the ambiguous-provider holds, budget_credits skipping order, and the fact that reuse of idempotency_key is only for retrying the same creation. That is far beyond what the annotations convey.

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

Conciseness3/5

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

The opening sentence is well front-loaded and the depth tiers are clear, but the middle is a dense run of cryptic clauses ('ranking.why_now_judged counts judged reasons at the front of the top 20', 'Judged-no reasons leave only why_now') that reference fields never defined in the schema. Information is high-value but packed into overlong sentences with weak structure.

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?

No output schema exists, and the description compensates by describing the finished result (typed datapoints, source-cited research claims with verbatim excerpts, why_now, per-component status, exact cost) and the operation_id/get_operation polling flow with the same data:read scope. It is essentially complete for this complexity, though the undefined ranking fields and nested person/company input semantics leave small gaps.

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 only 29%, so the description carries real weight: it explains what quick/standard/deep each add, that audience (3-2,000 chars) reorders why_now, that budget_credits skips non-fitting components and refuses below the minimum, and that dry_run reserves nothing. It leaves the person vs. company_domain object semantics (which identifiers are required, precedence when both are supplied) largely unexplained.

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 states a specific verb and composite resource ('One picture of a person, a company, or both') and enumerates the outputs it produces (who to contact, angles, why now), so an agent can tell it is a research/assembly tool rather than a raw lookup. It never names the sibling tools it overlaps with (enrich, research_company, find_intent), so differentiation is inferred rather than explicit.

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?

Usage context is implied by 'for goal-style asks' and by the depth tiers (quick/standard/deep) plus dry_run, which tells the agent how to scope a call. There is no explicit when-to-use-this-vs-alternatives guidance, no prerequisites, and no statement of when a cheaper sibling should be preferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources