mcp-gtm-suite

Map Company Event Presence

map_company_event_presence

Idempotent

Finds the conferences and trade shows a company publicly says it attends, returned with resolved years. Searches only the company's own domain to avoid brand collisions and reports its own event separately.

Instructions

Give it a company domain. It returns the third party conferences and trade shows that company publicly says it attends, with a year for each where one can be resolved, as one flat row. The search runs against the company's own domain, which is what stops a brand collision returning another company's events. The company's own conference is reported separately and is never mixed into the attendance list. It finds events for roughly 2 companies in 10, and an empty row is an honest empty row rather than a guess: read coverage, fetch_status and queries_failed to tell a company with no published events apart from a search that could not see. Events dated outside the years you ask for are still returned and flagged, so filter on event year rather than assuming the input filtered for you. This is not an events database and not an exhibitor list: it takes a company and reports what that company publishes. Requires an APIFY_TOKEN and consumes Apify credits. Read only.

Input Schema

TableJSON Schema

Name	Required	Description
`years`	No	Comma separated, for example 2025,2026. Events dated outside this set are still returned and flagged. Sent as a string so it works from Clay. Default: "2025,2026".
`domain`	Yes	A single company domain, for example 6sense.com. Protocol and path are stripped.
`skipCache`	No	false uses the 21 day result cache. true forces a fresh look. Default: "false".
`max_queries`	No	Between 1 and 5. Each query costs roughly 0.8 seconds plus a 1.3 second pause. 2 is the measured sweet spot: search engines refuse a third query from the same container almost every time, and the third query added no events the first two did not already find. Sent as a string so it works from Clay. Default: "2".
`company_name`	No	Improves matching when the brand differs from the domain stem, for example Gong for gong.io. Derived from the domain when left empty.
`max_charge_usd`	No	Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
`include_own_events`	No	Reports whether the company runs its own conference as a separate field. It is never mixed into the attendance list. Default: true.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.14.0Oct 16, 2026

addedInput schema / properties / max_charge_usd

Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}

Addedv1.1.1Oct 13, 2026

TDQS

A3.8/5.0

Behavior2/5

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

The description discloses a lot the annotations do not: cache (21 days unless skipCache), credit consumption and APIFY_TOKEN requirement, per-query latency, a max_queries rationale, the domain-scoped search that prevents brand collisions, and the rule that out-of-range years are returned and flagged. Against that, the closing claim 'Read only.' conflicts with readOnlyHint=false in the annotations, so the safety framing an agent sees in prose disagrees with the structured safety field.

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 core contract - domain in, flat row of declared attendance out, domain-scoped search - is front-loaded in the first two sentences, and the caveats that follow (hit rate, empty-row semantics, year flagging, cost) are all decision-relevant. It is dense rather than bloated, though the 'not an events database / not an exhibitor list' and 'Read only' tail sentences are the weakest and most repetitive.

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?

There is no output schema, so the description has to explain return shape, and it does: one flat row, a year per event where resolvable, separate field for the company's own conference, and named diagnostic fields (coverage, fetch_status, queries_failed) for interpreting an empty result. Combined with cost/cache/auth disclosure, an agent has everything needed to call and interpret this tool.

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 description coverage is 100%, and most of the description's parameter content (years being a soft filter, include_own_events being reported separately, max_queries sweet spot, cache behavior) is already documented in the schema property descriptions, so it largely restates structured data. The description does add operational meaning by tying years and include_own_events to what actually appears in the returned row, but the baseline of 3 applies when the schema carries the load.

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?

Specific verb+resource: given a company domain it returns the third-party conferences/trade shows that company publicly says it attends, as one flat row. It also draws sharp boundaries against nearby concepts ('not an events database and not an exhibitor list') and separates the company's own conference from the attendance list, so an agent can distinguish it from siblings such as monitor_public_awards or get_funding_press_signals.

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 strong context for when this is the right call: expected hit rate (roughly 2 companies in 10), an explicit instruction to read coverage, fetch_status and queries_failed to distinguish 'no published events' from 'search could not see', and a directive to filter on event year rather than trusting the input filter. It stops short of naming a sibling tool to use instead for event/exhibitor data, so it is clear context without explicit alternatives.

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

Map Company Event Presence

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools