Sells companies' data to AI labs for them: prices, buyers, deals, rulings and a free valuation.
Scored across 10 tools
The find_* tools split cleanly by entity (buyers, lots, vendors) and the search_* tools by resource (cases, deals, prices), so most selection is unambiguous. The one soft edge is the pricing cluster — get_market_rates (aggregate medians), search_prices (individual observations) and value_data (computed valuation) all concern price and could be confused at a glance, though the descriptions do draw the line explicitly.
Every tool follows the same snake_case verb_noun pattern (find_buyers, search_deals, get_market_rates, list_datasets, value_data). No mixed conventions, camelCase, or vague one-word names anywhere in the set.
Ten tools is well within a comfortable range, and each maps to a distinct research artifact (terms, buyers, lots, vendors, rates, prices, deals, cases, datasets, valuation). Nothing feels padded or conspicuously absent for the stated scope.
The surface covers the market from most angles: supply (lots, vendors), demand (buyers), pricing (rates, observations, valuation), legal (cases, software terms) and bulk export (datasets). Two minor gaps: there is no single-record detail tool (e.g. get_deal/get_case by id), and find_lots explicitly says no holder is named, implying a holder registry exists but isn't exposed.
For a business system (Slack, Microsoft 365, Google Workspace, Salesforce, HubSpot, Zendesk, Zoom, GitHub, Notion and more): whether the holder can export its data, what the vendor's API terms say about training AI on data pulled through them, our reading of the content's rights risk, and the clauses word for word. Research from public sources, not legal advice. Without system, lists the systems on file.
| Name | Required | Description | Default |
|---|---|---|---|
| system | No | The system's name, such as "Slack" or "Zendesk". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and a closed domain, so the safety profile is covered. The description adds real context beyond that: the data is sourced from public research, it is explicitly not legal advice, and omitting the parameter switches the tool into a listing mode. These are useful behavioral disclosures the annotations do not carry.
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?
Front-loaded with the domain and immediate examples of what is returned, followed by a short caveat and fallback sentence. Every clause carries information, though the long parenthetical vendor list makes the first sentence dense.
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?
No output schema exists, so the description must convey returns, and it does: export feasibility, API training terms, rights-risk assessment, and quoted clauses. Combined with annotations that cover safety, an agent has enough to call it correctly; only the concrete response shape is left unspecified.
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%, so the single optional `system` parameter is already documented, giving a baseline of 3. The description adds meaning beyond the schema by specifying the behavior when the parameter is omitted (returns the systems on file), which is genuinely useful for an optional parameter.
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 names the resource (a business system such as Slack, Zendesk) and enumerates exactly what the tool surfaces: export rights, vendor API terms on training AI, a rights-risk reading, and verbatim clauses. It is far more specific than the name alone, though it reads as a list of return facts rather than a crisp verb+resource, and no sibling overlaps this domain so differentiation is implicit.
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?
It gives clear context for invocation and an explicit conditional fallback: 'Without `system`, lists the systems on file.' It also frames the tool as 'Research from public sources, not legal advice,' which sets expectations. No alternatives are named, but none of the siblings compete, so exclusion guidance is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Organisations with a public way to sell them data, with their own published terms: what they want, what they pay, when they pay, who removes personal data, eligibility, and what they pay an introducer. Largest published figure first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind of data: company-records (Company records), source-code (Source code), video (Video and footage), audio-speech (Audio and speech), images (Images), text-archives (Text and archives), datasets-environments (Datasets, tasks and environments), physical-world (Physical-world data), expert-work (Expert and human work). | |
| limit | No | How many rows to return (default 10, at most 50). | |
| query | No | Words that must all appear in the buyer's name or terms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, covering the safety profile. The description adds one genuine behavioral trait beyond that: results are ordered 'largest published figure first', which is not derivable from annotations.
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?
It is a single sentence with no filler, but it is a dense, slightly awkward run-on that crams the returned field list into one clause rather than front-loading the core action. Informative but not well structured.
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 no output schema, the description carries the burden of describing return content and does so by enumerating the term fields returned plus sort order. It is largely complete for a read-only finder, though it omits any notion of result shape or pagination behavior.
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 100%, so kind, limit and query are fully documented in the schema. The description adds nothing about parameter semantics, so the 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?
The description states a specific resource and scope: organisations that publicly buy data, along with the term fields returned (what they pay, eligibility, introducer fee). Combined with the title it is clear what the tool returns, but it does not differentiate from siblings like search_deals or get_market_rates.
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 explicit when-to-use or when-not-to-use guidance, and no named alternative among the siblings. The usage is only implied by the resource described (buyers), leaving the agent to infer when this beats get_market_rates or search_deals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every lot publicly on offer in the catalogues the lot index reads each day (companies' records, codebases, footage, speech, environments), in one vocabulary: kind, industry, years of history, systems, size, what its catalogue says about the rights and whether it is ready, each linked to its catalogue's own page. We have not checked any catalogue's claims. No holder is named. Longest history first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind of data: company-records (Company records), source-code (Source code), video (Video and footage), audio-speech (Audio and speech), images (Images), text-archives (Text and archives), datasets-environments (Datasets, tasks and environments), physical-world (Physical-world data), expert-work (Expert and human work). | |
| limit | No | How many rows to return (default 10, at most 50). | |
| query | No | Words that must all appear in the lot's title, line of business or systems. | |
| rights | No | "settled": the lot's own catalogue says its holder has the rights with nothing left to confirm; "open": the catalogue names conditions or consent still to confirm. We have not checked either. | |
| industry | No | The holder's industry, as this site names industries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add context—and it does meaningfully: 'We have not checked any catalogue's claims. No holder is named,' plus the note that each row links to the catalogue's own page. Those trust/provenance caveats are not derivable from the annotations and materially affect how an agent should present results.
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?
Front-loaded with the core scope in the first clause, and the trailing caveats (unverified claims, no named holder) are short and load-bearing. The parenthetical kind list ('companies' records, codebases, footage, speech, environments') partially duplicates the kind enum, but overall there is little waste.
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 no output schema, the description carries the return-shape burden and does so: it lists the returned facets and the catalogue-page link, and flags the verification/attribution limits. For a read-only, zero-required-parameter search across 5 well-documented params, an agent has enough to call and interpret it, though result ordering ('Longest history first') is the only paging/sort guidance given.
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 100%, including per-enum explanations for kind, rights and industry, so the baseline is 3. The description's phrase 'in one vocabulary' plus the rights/readiness framing reinforces the model but adds no syntax or format detail beyond what the schema already documents.
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 names a specific resource and scope: 'Every lot publicly on offer in the catalogues the lot index reads each day,' and enumerates the facets (kind, industry, years of history, systems, size, rights, readiness). It is clearly distinguishable in substance from party-oriented siblings like find_buyers/find_vendors, but it never names an alternative to route against, so it stops short of full sibling differentiation.
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?
Usage is only implied—an agent can infer this is the tool for browsing catalogued data on offer, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. list_datasets, find_vendors). No prerequisites or exclusion conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vendors that sell training data, RL environments, evaluations, expert work or annotation to AI developers, each with what it says it sells and where its data comes from in its own words, and whether it says it pays holders for data. A to Z, not ranked.
| Name | Required | Description | Default |
|---|---|---|---|
| buys | No | Only vendors that say they buy, license or pay for data from its holders. | |
| from | No | Where it says its data comes from: licensed, customer, experts, captured, synthetic, replica, public ("licensed" means licensed from the companies or creators that hold it). | |
| limit | No | How many rows to return (default 10, at most 50). | |
| query | No | Words that must all appear in the vendor's name or what it sells. | |
| sells | No | What the vendor sells: rl-environments, datasets, human-data, evals, annotation, simulation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuinely new behavioral context: results contain what each vendor claims to sell and where data comes from 'in its own words', whether it claims to pay holders, and that the list is alphabetical rather than ranked.
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?
One dense but purposeful sentence describing the vendor record, followed by a three-word ordering note. The subject (vendors) is front-loaded; nothing is redundant, though the first sentence is long enough to be slightly hard to scan.
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 no output schema, the description carries the return-shape burden and does so (fields returned, self-reported nature, alphabetical ordering). All five filters are fully documented in the schema and annotations cover the safety profile, so nothing needed for a correct call is missing.
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%, so the baseline is 3, but the description adds a meaningful semantic layer: the returned attributes are self-reported claims ('in its own words', 'says it sells', 'says it pays holders'), which maps to the 'sells', 'from', and 'buys' filters and clarifies they select on vendor claims rather than verified facts.
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 names a specific verb+resource ('Vendors that sell training data, RL environments, evaluations, expert work or annotation to AI developers') and even lists the sub-categories sold. It does not explicitly name or contrast with the sibling 'find_buyers', so differentiation is left implicit through the supply-side framing.
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?
Usage is only implied: describing the tool as the supply-side ('sells... to AI developers') implicitly routes the agent away from 'find_buyers', and 'A to Z, not ranked' hints at ordering. There is no explicit when-to-use, when-not, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median, middle half and range per comparable unit (per hour of video or audio, per image, per task, per company, per title, and more) for each kind of AI training data and each side of the market, computed from published prices. Without kind, returns every rate the evidence supports a median for.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people), products (Data products). | |
| side | No | The side of the market: pay (Paid to the people who make it), offer (Offered to holders), licence (Sales that happened), listing (Asking prices off the shelf), collection (Made to order), cost (Cost to produce). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. Beyond that, the description adds meaningful behavioral context: it reports aggregate statistics computed from published prices, describes the comparable units, and explains what happens when `kind` is omitted. It does not contradict the annotations.
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 with no wasted text. It front-loads the core purpose and uses the second sentence to explain default behavior when `kind` is absent.
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 no output schema, the description carries the burden of explaining return content, and it does so by naming the statistics and comparable units returned. It is nearly complete for a read-only rates query, though it does not specify response structure, pagination, or how sparse evidence is represented.
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 100%, with both `kind` and `side` fully enumerated and described in the input schema. The description reinforces that `kind` and `side` segment the rates and notes the omitted-`kind` behavior, but it adds little parameter detail beyond the already rich 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 clearly states the tool returns market-rate statistics (median, middle half, range) for AI training data, broken down by kind and market side, computed from published prices. It is specific about the resource and output measures, but it does not explicitly distinguish this from sibling tools such as search_prices or value_data.
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 explains the default behavior when `kind` is omitted, which is useful usage context. However, it does not state when to use this tool versus alternatives like search_prices, find_buyers, or value_data, so the agent must infer the selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every table behind these tools as a CSV and JSON download (our compilation of the tables under CC BY 4.0; quotes keep their sources' terms, and article text is not covered), with row counts, review dates and the permanent copies with their DOIs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds genuinely useful non-structural context: licensing (CC BY 4.0 compilation, quotes retain source terms, article text excluded) and the fact that permanent copies with DOIs accompany the downloads. It still says nothing about response size, pagination, or download mechanics.
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?
It is a single sentence, but a long and heavily parenthetical one whose licensing aside interrupts the core statement of what the tool returns. The most useful framing ('every table ... as a CSV and JSON download') is front-loaded, but the structure is dense rather than crisp.
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 no output schema and no parameters, the description carries the burden of describing the return payload, and it does: datasets as CSV/JSON plus row counts, review dates and DOI-backed permanent copies. Licensing terms are also covered. It is close to complete for such a simple tool, though it never explicitly frames itself as a listing operation.
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 no parameters, so per the baseline there are no parameter semantics to document and the description adds nothing further. A 4 is the appropriate baseline for a zero-parameter tool.
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 the resource precisely — 'every table behind these tools as a CSV and JSON download' — with the metadata included (row counts, review dates, DOIs), so an agent can tell this is the dataset catalogue rather than a search tool. It never states an explicit action verb (list/retrieve), and it does not name a sibling it differs from, which keeps it short of a 5.
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 when-to-use guidance and no mention of alternatives. The description never says to call this to discover available data before using search_cases, search_deals, value_data, etc., nor does it distinguish itself from those siblings. Zero-parameter listing makes usage fairly obvious, but the definition offers no routing help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lawsuits, rulings, settlements and regulatory actions over data used to train AI, with parties, claim, amounts, outcome, status and the source. Newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind of case: guidance, lawsuit, regulatory action, ruling, settlement. | |
| limit | No | How many rows to return (default 10, at most 50). | |
| query | No | Words that must all appear, such as a party ("Anthropic"), a court or a kind of content ("books"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds the sort order ('Newest first') and the breadth of the record set (guidance through settlements), but says nothing about result volume, truncation, or how empty queries behave.
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 compact sentences with zero filler: the first front-loads scope and returned fields, the second front-loads ordering. Nothing is repeated from the schema or annotations.
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 no output schema, the description usefully enumerates the returned fields and the default sort, which is the information an agent needs to interpret results. It stops short of describing pagination or how a no-parameter call behaves (all filters optional), a minor gap for a 3-param search tool.
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 100%, so `kind`, `limit` and `query` are already fully documented in the schema, including the enum values, default of 10, max of 50, and the 'all words must appear' semantics. The description's field list refers to outputs rather than parameters, so it adds no parameter meaning beyond the schema; 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?
The description names the specific resource (lawsuits, rulings, settlements, regulatory actions over AI training data) and enumerates the fields returned (parties, claim, amounts, outcome, status, source), which is far more specific than the tool title alone. It is distinguishable from siblings like search_deals and search_prices, though it never states the verb 'search/filter' explicitly, leaving the retrieval action implied by the name.
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 when-to-use guidance, no mention of when another tool (e.g. check_software_terms) would be a better fit, and no statement of prerequisites. The only contextual clue is 'Newest first', which describes ordering rather than when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Licences of data to AI companies disclosed since July 2023: licensor, licensee, content, use (training or display), term, value where disclosed, with a verbatim quote and the source. Newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| use | No | What the data is used for. | |
| limit | No | How many rows to return (default 10, at most 50). | |
| query | No | Words that must all appear, such as a licensor, a licensee ("OpenAI") or a kind of content ("news"). | |
| since | No | Only deals on or after this date (YYYY, YYYY-MM or YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: results are ordered newest-first and coverage is bounded to disclosures since July 2023, which the annotations do not convey.
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?
A single dense sentence that front-loads the resource scope, then lists the returned fields and ordering, with zero filler. Nothing could be cut without losing information.
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 no output schema, the description usefully compensates by enumerating the returned fields (licensor, licensee, content, use, term, value, verbatim quote, source) and the sort order. The remaining gap is usage guidance and result-volume behavior, which is only partly covered by the limit parameter in the schema.
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 100%, including enum values for 'use' and the date pattern for 'since', so the schema carries all parameter meaning. The description adds no syntax or filter-combination detail beyond what the schema already states, making the baseline 3 correct.
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 names a specific resource (disclosed AI data licensing deals) and enumerates the returned fields, so an agent knows exactly what kind of record set this is. It is distinguishable from siblings like search_cases and search_prices by resource, though it never uses an explicit verb to say it performs a search/lookup.
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 when-to-use statement, no prerequisites, and no mention of alternative tools (e.g. value_data or get_market_rates) for related licensing questions. Usage must be inferred entirely from the resource description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The individual price observations behind the market rates: what a lab, vendor, marketplace or court said data was paid, offered, listed or sold for, with the figure as published, the figure per unit, the date, the source's own words and a link. Newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people), products (Data products). | |
| side | No | The side of the market: pay (Paid to the people who make it), offer (Offered to holders), licence (Sales that happened), listing (Asking prices off the shelf), collection (Made to order), cost (Cost to produce). | |
| limit | No | How many rows to return (default 50, at most 50). | |
| query | No | Words that must all appear, such as a company ("Shutterstock"), a language ("hindi") or a kind of record ("egocentric"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent lookup. The description adds useful behavioral context beyond annotations: results are newest first and include the published figure, per-unit figure, date, source wording, and link.
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 dense sentence that front-loads the core purpose and return contents. It is efficient, though the sentence is long enough that slight structural trimming would improve scanability.
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 no output schema, the description carries the burden of explaining returned values, and it does so by naming the published figure, per-unit figure, date, source quote, and link. Ordering is also disclosed, so an agent has enough context to call and interpret the tool 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 enum descriptions fully explain kind and side. The description does not add parameter-level meaning beyond the schema, so the baseline score of 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 states a specific resource: individual price observations behind market rates, including what was paid, offered, listed, or sold. It clearly distinguishes this from aggregate market-rate data, which is the relevant sibling contrast.
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 'behind the market rates' implies this tool is for underlying evidence rather than aggregates, but it does not explicitly say when to use it instead of get_market_rates or other price-related siblings. Usage is inferable but not well guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What published prices imply for a holding of data: a low-to-high range in US dollars with the arithmetic behind it. Call it first with only kind to get the questions and their answer ids, ask the holder, then call again with answers. Questions not answered are taken at their defaults and marked as assumed. An indication, not an offer.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | What is being valued: records (Company records), code (Codebases), video (Video and footage), speech (Audio and speech), images (Images), text (Text and archives), robotics (Robot and physical-world data), environments (Simulated environments), tasks (Graded tasks and benchmarks). | |
| answers | No | Answer ids by question id, as returned in `questions` (for video, for example {"hours": "1000-10000"}); every answer is one of the listed answer ids, sent as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive, so safety is covered; the description then adds behavior annotations cannot express: the two-phase question/answer protocol, the shape of the return value, and how unanswered inputs are defaulted and flagged. This is meaningful context beyond the structured fields.
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?
Four sentences, front-loaded with the purpose and output before the calling protocol. Every sentence carries distinct information (output shape, call sequence, defaults, disclaimer) with no restatement of the name or schema.
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?
There is no output schema, so the description must explain the return value, and it does: a low-to-high USD range, the supporting arithmetic, and a `questions` payload with answer ids. Combined with the stated defaulting rule, an agent has everything needed to drive both calls 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?
With 100% schema coverage the schema already documents both parameters, and the `answers` schema even gives the {hours: 1000-10000} example. The description still adds real semantics: that `kind` alone is a valid first call, that answer values must be listed answer ids sent as text, and that omissions default. It does not add format detail for the returned questions themselves.
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 computation ('what published prices imply for a holding of data') and names the concrete output ('a low-to-high range in US dollars with the arithmetic behind it'). That distinguishes it from the sibling lookup tools (search_prices, get_market_rates) which find prices rather than value a holding.
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?
It prescribes an explicit two-step procedure: call first with only `kind` to get the questions and answer ids, ask the holder, then call again with `answers`. It also covers the non-happy path ('questions not answered are taken at their defaults and marked as assumed') and sets expectations with 'an indication, not an offer.'
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.
value_data2 fields changedInput schema / properties / kind / descriptionPrevious value: -"What is being valued: records (Company records), code (Codebases), tasks (Training tasks), video (Video and footage), speech (Audio and speech), images (Images), text (Text and archives), environments (Simulated environments), robotics (Robot and physical-world data)."New value: +"What is being valued: records (Company records), code (Codebases), video (Video and footage), speech (Audio and speech), images (Images), text (Text and archives), robotics (Robot and physical-world data), environments (Simulated environments), tasks (Graded tasks and benchmarks)."Input schema / properties / kind / enumPrevious value: -[
- "records",
- "code",
- "tasks",
- "video",
- "speech",
- "images",
- "text",
- "environments",
- "robotics"
-]New value: +[
+ "records",
+ "code",
+ "video",
+ "speech",
+ "images",
+ "text",
+ "robotics",
+ "environments",
+ "tasks"
+]get_market_rates2 fields changedInput schema / properties / kind / descriptionPrevious value: -"The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people)."New value: +"The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people), products (Data products)."Input schema / properties / kind / enumPrevious value: -[
- "company",
- "code",
- "video",
- "audio",
- "images",
- "text",
- "environment",
- "physical",
- "people"
-]New value: +[
+ "company",
+ "code",
+ "video",
+ "audio",
+ "images",
+ "text",
+ "environment",
+ "physical",
+ "people",
+ "products"
+]search_prices2 fields changedInput schema / properties / kind / descriptionPrevious value: -"The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people)."New value: +"The kind of data: company (Company records), code (Source code), video (Video and footage), audio (Audio and speech), images (Images), text (Text and archives), environment (Datasets, tasks and environments), physical (Physical-world data), people (Work by people), products (Data products)."Input schema / properties / kind / enumPrevious value: -[
- "company",
- "code",
- "video",
- "audio",
- "images",
- "text",
- "environment",
- "physical",
- "people"
-]New value: +[
+ "company",
+ "code",
+ "video",
+ "audio",
+ "images",
+ "text",
+ "environment",
+ "physical",
+ "people",
+ "products"
+]find_lots1 field changedInput schema / properties / rights / descriptionPrevious value: -"\"settled\": the owner holds the rights with nothing left to confirm; \"open\": conditions or consent still to confirm."New value: +"\"settled\": the lot's own catalogue says its holder has the rights with nothing left to confirm; \"open\": the catalogue names conditions or consent still to confirm. We have not checked either."find_vendors1 field changedInput schema / properties / buys / descriptionPrevious value: -"Only vendors that say they buy, license or pay for data from its owners."New value: +"Only vendors that say they buy, license or pay for data from its holders."find_lotsfind_vendorssearch_prices1 field changedInput schema / properties / limit / descriptionPrevious value: -"How many rows to return (default 10, at most 50)."New value: +"How many rows to return (default 50, at most 50)."value_data1 field changedInput schema / properties / answers / descriptionPrevious value: -"Answer ids by question id, as returned in `questions` (for example {\"hours\": \"1000\"})."New value: +"Answer ids by question id, as returned in `questions` (for video, for example {\"hours\": \"1000-10000\"}); every answer is one of the listed answer ids, sent as text."check_software_termsfind_buyersget_market_rateslist_datasetssearch_casessearch_dealssearch_pricesvalue_dataEstimate what your company's operational data is worth to AI labs. Counts only, never content.
Free SME valuation, sell-readiness, M&A pricing, partner and deal-referral tools in EN/FR/ES/PT.
Guidance on selling or licensing company data to AI labs: deal steps, de-identification, compliance.
Company and market intelligence, news, enrichment, and agentic workflows for dealmakers.
Add one secure layer between your agents and this server.
