Search thousands of B2B conferences, see every speaker and sponsor, look up where a company speaks or sponsors, and rank events by fit with the people you sell to.
Scored across 9 tools
Each tool targets a distinct resource or operation: event search, speaker search, sponsor search, company profile, event details, ICP inference/matching, taxonomy, and credits. The only potential confusion is that get_company overlaps with search_speakers/search_sponsors when filtered by company, but get_company is an aggregate view while those are granular search endpoints.
Most tools follow clear get_, search_, and icp_ snake_case conventions, making the API predictable. The lone outlier is 'credits', a bare noun instead of something like get_credits, so the pattern is not perfectly uniform.
Nine tools is well-scoped for a conference intelligence API: search, detail lookup, ICP matching, taxonomy validation, and account management all have a clear place. No tool feels redundant, and the set is neither bloated nor thin.
The set covers the full read-only workflow: discover events, speakers, and sponsors; drill into event or company details; build and apply an ICP; validate taxonomy values; and check credits. As an intelligence service, no obvious lifecycle operations are missing.
Your Onsite plan and remaining credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It implies an informational/status query but does not explicitly say it is read-only, what data it returns, whether authentication is needed, or what side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler, making it easy to parse. However, it is a fragment rather than an action sentence, and converting it to something like 'Get the current Onsite plan and remaining credits' would improve structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool this is nearly adequate: the agent knows the domain and expected content. But with no output schema and no annotations, the description should state the retrieval semantics more explicitly to be fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description adds no misleading or unnecessary parameter information; 'Onsite plan and remaining credits' hints at what the response will cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase and contains no verb indicating what the tool does, so an agent must infer that it retrieves or displays the Onsite plan and remaining credits. It at least names a distinct resource (credits/plan) that separates it from event/company/search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description never mentions alternatives, prerequisites, or situations where this tool should be chosen over siblings such as get_company or get_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything one company does on the conference circuit: events sponsored (with tier) and employees who speak. Point it at a competitor or a target account.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | company slug (e.g. datadog) or domain (datadoghq.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals output content (sponsored events with tier, speaking employees), but does not state whether data is read-only, whether it includes current/historical conferences, or if any authentication is required. The tool name 'get' implies read-only, but the description does not explicitly confirm it or discuss edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero wasted words. The most important output details are front-loaded in the first sentence, and the use case is delivered in the second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description is largely complete: it explains what the result contains and when to use it. It could mention handling of unknown slugs or whether results are time-scoped, but given the low complexity, this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'slug' with examples for both slug and domain formats (100% coverage), so the description adds no additional parameter meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific resource ('a company') and precisely enumerates what is returned: events sponsored with tier and employees who speak. This distinguishes get_company from sibling search tools and get_event by making clear it aggregates all activity for a single company rather than listing individual events or speakers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives an explicit use case: 'Point it at a competitor or a target account.' This tells an agent when the tool is appropriate and implies it is for company-level lookups rather than general search. It does not name alternative sibling tools or state exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event with its full speakers[] (name, title, company, LinkedIn) and sponsors[] (company, tier). 1 credit per person or sponsor.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | event slug, e.g. saastr-annual-2026 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose the credit cost per person or sponsor, which is valuable and non-obvious. However, it does not state whether the call is purely read-only, what happens when the slug is not found, or any limits/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the resource and the key returned structures, then adds the cost model in a compact second clause. Every part contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description adequately explains the return shape and includes the important credit cost. It could be more complete by noting the event's own fields, but 'full' combined with the nested arrays gives the agent enough to decide and call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the slug parameter already has a clear description with an example. The tool description adds no parameter-level meaning beyond 'one event', so it does not improve on what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a single event and enumerates the returned nested data: speakers[] with name, title, company, LinkedIn, and sponsors[] with company and tier. It is distinguishable from sibling search tools by emphasizing 'one event', though it never states the action verb explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use get_event versus search_events or other siblings. The description implies it is for retrieving a single known event, but it does not say 'use when you have a slug' or mention that search_events should be used for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Allowed values for personas, industries (sectors), audiences and regions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly say the tool is read-only, does not describe the response shape, and does not mention ordering, grouping, or format. The phrase 'Allowed values' weakly implies a lookup operation, but this is minimal and leaves important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It front-loads the essential content and every word contributes meaning. For a simple lookup tool, this is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description communicates the key information an agent needs: the tool provides allowed values for specific dimensions. It could be more explicit about return format, but this is a minor gap for a static enum-like lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are trivially satisfied by the empty schema. The description adds useful context by naming the taxonomy categories, but no parameter-level information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a taxonomy and enumerates exactly what it covers: personas, industries (sectors), audiences, and regions. Although it lacks an explicit verb like 'returns' or 'gets,' the noun phrase 'Allowed values for' strongly implies retrieval and distinguishes the tool from the sibling search/credits/icp tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's purpose: fetch allowed values for the listed categories. It does not explicitly state when to use it or mention alternatives, but for a zero-parameter lookup of static taxonomy data, this implied usage is reasonably clear and unlikely to be confused with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a company's website and draft its ideal customer profile (personas, industries, audiences, regions, competitors) in the values icp_match accepts. Start here when a user says 'find events for my company'. 5 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | company website, e.g. acme.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention the 5-credit cost and the output format constraint, but does not disclose potential network failures, rate limits, or side effects beyond credit consumption. It is partially transparent but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core function and output compatibility; the second gives the usage trigger and cost. Information is front-loaded and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core functionality, output format, usage trigger, and cost. It lacks explicit error handling or prerequisites, but these are minor for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, url, has 100% schema description coverage with an example ('acme.com'). The description does not add extra meaning beyond the schema, so the baseline of 3 is appropriate; it neither enriches nor detracts from the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a company's website and drafts an ideal customer profile, explicitly naming the output format as 'the values icp_match accepts'. It also distinguishes itself from siblings by referencing icp_match directly, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger: 'Start here when a user says find events for my company'. This tells the agent when to invoke it, though it does not enumerate alternatives or state when not to use it. The trigger is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe who you sell to and get upcoming events ranked by fit, each with the matching people on stage and the sponsors. Use get_taxonomy for allowed values. Geography filters are OR-ed. 1 credit per event plus 1 per person.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| limit | No | ||
| topics | No | ||
| regions | No | north-america, europe, asia, ... | |
| personas | No | e.g. engineering-leader, founder-exec, sales, marketing | |
| audiences | No | ||
| countries | No | ||
| us_states | No | 2-letter codes | |
| industries | No | ||
| include_online | No | ||
| people_per_event | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses two important behaviors: geography filters are OR-ed, and there is a credit cost of '1 credit per event plus 1 per person.' These go beyond typical descriptions and help an agent gauge both logical behavior and resource usage. However, it omits other details like whether results are read-only, pagination behavior, and output structure, though the disclosed specifics are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core purpose is front-loaded, and the geographic behavior and credit cost are stated succinctly. Every sentence earns its place, and the structure is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain the meaning or expected format of most parameters, nor the return structure (beyond events/people/sponsors), nor any default behavior. An agent would need to rely on schema names and external knowledge to call this correctly, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It clarifies that geography filters (regions, countries, us_states) are OR-ed and points to get_taxonomy for allowed values, which helps for some parameters. But it leaves many parameters unexplained (to, from, topics, personas, audiences, industries, include_online, people_per_event), and does not add meaning for them, failing to offset the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific purpose: 'Describe who you sell to and get upcoming events ranked by fit, each with the matching people on stage and the sponsors.' It distinguishes itself from sibling tools like search_events by focusing on ranking by fit and mentioning get_taxonomy for allowed values, which orients an agent on the tool's unique niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one explicit usage directive: 'Use get_taxonomy for allowed values,' which tells the agent to fetch valid taxonomy values first. However, it does not contrast icp_match with sibling tools like search_events, icp_infer, or get_event, nor does it state when this tool is preferred over alternatives. This leaves the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search conferences, congresses, expos and trade shows worldwide (any sector). Returns dates, location, sector, speaker/sponsor counts. 1 credit per row.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | event name substring | |
| to | No | YYYY-MM-DD, start_date <= | |
| city | No | ||
| from | No | YYYY-MM-DD, start_date >= | |
| limit | No | ||
| topic | No | comma-separated topics, e.g. data,devops,security | |
| offset | No | ||
| online | No | ||
| region | No | north-america | latin-america | europe | middle-east-africa | asia | oceania | online | |
| country | No | ||
| industry | No | comma-separated sectors from get_taxonomy, e.g. fintech-payments,cybersecurity | |
| upcoming | No | default true; false includes past events | |
| min_speakers | No | ||
| min_sponsors | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds some value: it discloses the return fields (dates, location, sector, speaker/sponsor counts) and the credit cost ('1 credit per row'), which is not in the schema. However, it omits meaningful behavioral traits such as default upcoming=true, pagination semantics, and how filters combine, so disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences earn their place: purpose and scope first, then return fields, then cost. No filler, no repetition of schema content, and the most decision-relevant fact (credit cost) is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter search tool with no output schema and no annotations, the description covers purpose, results, and cost but leaves gaps: pagination defaults, substring matching behavior of q, and the effect of the upcoming default are unaddressed. It is adequate for a first pass but not complete for correct invocation in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, so the description partially compensates by mapping return fields to filter categories: 'location' to city/country/region/online, 'sector' to industry/topic, and 'speaker/sponsor counts' to min_speakers/min_sponsors. But it adds no semantics for q, limit, offset, upcoming, or the online enum, leaving half the parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('conferences, congresses, expos and trade shows') with explicit global scope ('worldwide (any sector)'). It implicitly distinguishes from search_speakers and search_sponsors by naming the event entity, though it does not explicitly contrast itself with get_event or other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_event, search_speakers, or search_sponsors. 'Any sector' hints at breadth but provides no conditions, exclusions, or routing advice, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find people on stage across every event: name, title, company, LinkedIn, talk, role. Filter by company (name or domain), title, persona, sector, country, dates.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | YYYY-MM-DD, start_date <= | |
| city | No | ||
| from | No | YYYY-MM-DD, start_date >= | |
| name | No | ||
| role | No | ||
| event | No | event slug | |
| limit | No | ||
| title | No | job title substring, e.g. cto | |
| topic | No | comma-separated topics, e.g. data,devops,security | |
| offset | No | ||
| online | No | ||
| region | No | north-america | latin-america | europe | middle-east-africa | asia | oceania | online | |
| company | No | company name substring or domain | |
| country | No | ||
| persona | No | founder-exec | engineering-leader | engineer | product | design-ux | data-ai | security | marketing | sales | hr-people | finance | operations | devrel | academic-research | consultant | |
| industry | No | comma-separated sectors from get_taxonomy, e.g. fintech-payments,cybersecurity | |
| upcoming | No | default true; false includes past events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the scope ('across every event') and the 'upcoming' default behavior ('default true; false includes past events') in the schema, but the description itself does not mention pagination, rate limits, or that results are limited to people who actually appeared on stage. The description adds some context beyond the schema but leaves behavioral details to the parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core purpose ('Find people on stage across every event') before listing filters. Every phrase earns its place, though the filter list is dense and could be slightly more structured. It is appropriately sized for a 17-parameter search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 17 parameters, no output schema, and no annotations, the description gives a solid overview of what is searched and what filters exist, but it does not explain the response shape, pagination behavior, or how the 'upcoming' default affects results. The schema fills in some gaps, but the description alone would not fully prepare an agent to invoke the tool correctly for complex queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 59%, so the schema documents many parameters but leaves several (city, name, country, event, online, region) without descriptions. The tool description compensates by listing the filter dimensions (company, title, persona, sector, country, dates) and the return fields, which helps an agent infer the meaning of undocumented parameters like country and city. It does not fully document every parameter, but it adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb ('Find') and resource ('people on stage across every event'), then enumerates the exact fields returned (name, title, company, LinkedIn, talk, role) and the filter dimensions (company, title, persona, sector, country, dates). This distinguishes it from sibling search tools like search_events and search_sponsors, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool searches ('people on stage across every event') and lists filter dimensions, which implies when to use it: when you need speaker/person data rather than events or sponsors. However, it does not explicitly say when not to use it or name alternatives such as search_events or search_sponsors, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find companies sponsoring or exhibiting at events, a public budget signal. Filter by company, kind, tier, sector, country, dates.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | company name substring or domain | |
| to | No | YYYY-MM-DD, start_date <= | |
| city | No | ||
| from | No | YYYY-MM-DD, start_date >= | |
| kind | No | ||
| tier | No | ||
| event | No | event slug | |
| limit | No | ||
| topic | No | comma-separated topics, e.g. data,devops,security | |
| offset | No | ||
| online | No | ||
| region | No | north-america | latin-america | europe | middle-east-africa | asia | oceania | online | |
| country | No | ||
| industry | No | comma-separated sectors from get_taxonomy, e.g. fintech-payments,cybersecurity | |
| upcoming | No | default true; false includes past events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral context. It clearly indicates a read-oriented search operation ('Find companies') and frames results as public budget signals, but it does not disclose defaults (e.g., upcoming=true), pagination behavior, response shape, or any data-freshness caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences with no filler. The core purpose is front-loaded, and the 'public budget signal' qualifier adds context without bloating the text. A minor deduction for the slightly redundant filter list that partially restates schema property names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, no annotations, and no output schema, the description alone is under-specified. It does not explain defaults (upcoming), pagination (limit/offset), value formats for multi-value params (topic, industry), or the meaning of 'tier' and 'city', leaving an agent to infer too much for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 53%, so the description should compensate. It maps loosely to several parameters ('company' to q, 'kind' to kind, 'tier' to tier, 'sector' to industry, 'country' to country, 'dates' to from/to), but it omits many params (event, topic, region, online, limit, offset) and uses 'sector' while the schema names the field 'industry', introducing possible confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find companies sponsoring or exhibiting at events.' It also states the unique angle ('a public budget signal') and enumerates the filter dimensions, making it distinct from sibling tools like search_events and search_speakers without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a public budget signal' implies a use case, but the description does not explicitly say when to prefer this over alternatives such as search_events or get_company, nor does it mention any exclusions. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
creditsget_companyget_eventget_taxonomyicp_infericp_matchsearch_eventssearch_speakerssearch_sponsors
Add one secure layer between your agents and this server.