Dated quotes of GDPR art. 28 subprocessor lists: who lists whom, fourth parties, what changed, when.
Scored across 7 tools
The tools target distinct query types: current list, dated snapshot, single-company changes, multi-company changes, reverse lookup, identity resolution, and supply-chain paths. The main overlap is between scope variants like `list` vs `as_of` and `changes` vs `changes_across`, but the descriptions clearly explain the differences.
All names use lowercase snake_case, which is consistent as a formatting convention. However, the grammatical pattern is mixed: some are nouns (`list`, `changes`), some are relational phrases (`as_of`, `in_chain`, `named_by`), and one is a verb (`resolve`), so there is no predictable verb_noun or semantic pattern.
Seven tools is well within the expected range for a specialized read-only record API. Each tool covers a distinct query angle, so the set feels deliberately scoped rather than bloated or thin.
The surface covers core workflows: current and historical lists, diffs, reverse lookup, identity resolution, and multi-hop supply-chain paths. Minor gaps remain, such as no obvious way to enumerate available companies or search subprocessors beyond exact resolution, but agents can likely work around these.
What one company's list said on a given date, from the reading this record holds nearest before it, with that reading's own date, its web-archive capture where there is one, its source and its digest. Says so when the date is earlier than the first reading held. Needs a key on an account whose watch is running: this is part of the watch on disclosedby.com. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ISO date, e.g. 2024-01-01. | |
| company | Yes | A company with a list on this record: its domain (notion.so) or its name (Notion). One company per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and largely succeeds: it reveals the nearest-prior-reading lookup semantics, the edge-case behavior for out-of-range dates, the authentication prerequisite, and a read-only posture ('Free to read'). This is substantially richer behavioral disclosure than most definitions provide. There is no contradiction to check since annotations were not provided.
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 core purpose is front-loaded in the first sentence, followed by a genuinely useful edge-case note and the key/watch prerequisite. However, the final four sentences are citation and licensing boilerplate ('cite the page and the read date,' 'may never be compiled into a lead list, a prospecting feed or a sales tool') that do nothing to help an agent select or invoke the tool, roughly doubling the description's length without adding functional value.
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?
Complexity is low — two required parameters, both schema-documented, no annotations, no output schema — and the description covers the input semantics, the returned fields, the out-of-range edge case, and the prerequisite. The only real gap is the absence of an explicit return format, but given the enumerated output fields and the simple shape, the definition is sufficiently complete 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?
Both parameters are already fully documented in the schema (100% coverage), setting a baseline of 3. The description adds real value beyond the schema by defining the date parameter's semantics: the date is the as-of anchor, and the result comes from the reading held nearest before it. The company parameter gains only the context that the record must be 'one company's list,' so the added meaning is concentrated on the date 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 first sentence states a specific operation — what one company's list said on a given date, drawn from the nearest reading held before it — and lists the expected return fields (reading date, web-archive capture, source, digest). This point-in-time semantics clearly distinguishes it from siblings like changes or changes_across, though no sibling is named explicitly. The lack of an imperative verb like 'retrieve' keeps it just below the top tier.
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 supplies a prerequisite ('Needs a key on an account whose watch is running') and a scope statement ('part of the watch on disclosedby.com'), which imply when the tool is usable. It also discloses out-of-range behavior ('Says so when the date is earlier than the first reading held'). However, there is no explicit when-to-use guidance or any named alternative such as list or resolve, so an agent must infer which sibling to select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dated changes to one company's list, each derived from two readings of that list and carrying both. A change is what the page said on one date against what it said on another; it is never a claim about when a company began or ended a relationship. printed_differently marks an entry the list printed in other words with the same companies in the same countries (a name, a location's wording, the list's date line). Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO date; only changes on or after it. | |
| company | Yes | A company with a list on this record: its domain (notion.so) or its name (Notion). One company per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that changes are dated quotes, that printed_differently marks wording changes, that the data is free to read but has reuse restrictions, and that a key is one reader's own use. This is substantial behavioral context beyond the schema, though it doesn't detail rate limits or exact response format.
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 dense but front-loaded with the core definition of a change. The licensing and reuse restrictions are important but somewhat lengthy; they could be trimmed. Overall, every sentence earns its place, though the legal language could be more 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?
For a tool with 2 params, full schema coverage, and no output schema, the description is quite complete. It explains the semantics of a change, the printed_differently flag, and usage restrictions. It doesn't describe the output structure, but since there's no output schema, a brief note on return format would help. Still, the description is strong for the tool's complexity.
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 schema already documents both parameters. The description adds context about what 'company' means (domain or name) and that one company per call is allowed, which aligns with the schema. It doesn't add much beyond the schema, but the baseline of 3 is appropriate given full 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 clearly states the tool returns dated changes to one company's list, derived from two readings, and explicitly distinguishes it from claims about relationship timing. It names the resource (a company's list) and the verb (get changes), making it distinct from siblings like as_of or changes_across.
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 what a change is and what it is not, which helps an agent decide when to use it. It doesn't explicitly name alternative tools or say 'use X instead', but the context of 'one company's list' and the sibling names (changes_across, as_of) imply the scope. It could be improved by explicitly contrasting with changes_across.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The dated changes to the lists of several companies at once, each carrying the two readings it came from. The same facts as changes, gathered for one reader's own list of companies. Needs a key on an account whose watch is running: this is part of the watch on disclosedby.com. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Optional ISO date; only changes on or after it. | |
| companies | Yes |
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 a prerequisite (key with running watch), usage restrictions (protected compilation, no re-use, no lead lists), and output characteristics ('Every row is a dated quote of a company's own published page'). It doesn't mention side effects or error conditions, but for a read-like tool this is reasonable coverage.
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 verbose and includes extensive legal/licensing text that is not directly relevant for calling the tool. The core purpose is front-loaded, but then it repeats information and ends with a redundant sentence ('A key is one reader's own use.'). It could be condensed to two or three sentences without losing essential guidance.
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?
The tool has only 2 parameters, no output schema, and no annotations. The description covers prerequisites and usage restrictions, and gives some idea of output rows. However, it leaves ambiguous terms like 'the two readings' and does not specify the exact response structure or error scenarios. For a simple tool, it's adequate but not complete.
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 50% (only 'since' has a description). The tool description adds that the 'companies' parameter refers to 'several companies at once' but doesn't clarify format (identifiers vs names) or any other semantics. Since coverage is at the boundary, and the description doesn't significantly enrich parameter understanding, a 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 states the tool's function: 'The dated changes to the lists of several companies at once' and distinguishes it from the sibling 'changes' by adding 'gathered for one reader's own list of companies.' This gives a specific verb, resource, and scope, differentiating it from other tools like 'as_of' or 'in_chain'.
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 implies when to use this tool by contrasting with 'changes' (the general version) and specifying it's for the reader's own list. It also states a prerequisite: 'Needs a key on an account whose watch is running.' However, it doesn't explicitly say 'use this instead of X' or provide when-not-to-use guidance, so it's slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given the companies a reader buys from, every path from that list to one subprocessor: named directly, or named by a company whose own list names it (a fourth party, or sub-subprocessor). A second hop is a different relationship, quoted from a different page. Names that matched nothing, companies with no list read and rows that did not resolve come back beside the paths. It says who to ask, never who is harmed. Needs a key on an account whose watch is running: this is part of the watch on disclosedby.com. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | The subprocessor to look for. | |
| companies | Yes | The companies the reader buys from, by domain or name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full load and does well: it discloses that unmatched names, unread lists, and unresolved rows are returned alongside paths; notes key/account/watch requirements; clarifies it says 'who to ask, never who is harmed'; and states citation/read-date and compilation protection. Lacks details on response shape or pagination, but covers key behavioral traits.
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 long and meandering, with legal/licensing text interleaved with functional explanation. Key operational details (key requirement, what gets returned) are buried mid-paragraph. It front-loads the core path concept but then sprawls.
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 two-parameter read tool with no output schema, the description covers inputs, output composition, access requirements, and legal constraints. It omits response format details, but the described return contents (paths, alongside unmatched/unresolved items) are sufficient for an agent to know what to expect.
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 the schema already documents 'companies' and 'target'. The description contextualizes 'companies' as 'the companies the reader buys from' and 'target' as a subprocessor, but adds no new syntax or edge-case meaning beyond the schema. 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 explains that it traces paths from a reader's list of companies to a target subprocessor, naming direct and indirect (fourth-party) relationships. The 'in_chain' name plus title make the resource specific. However, the phrasing is dense and doesn't explicitly say 'returns whether target is in the supply chain' in one crisp sentence, leaving some parsing work.
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?
Implied use is checking if a target subprocessor is linked to companies a reader buys from. It contrasts with siblings only indirectly by describing multi-hop paths (vs. 'named_by' for a single hop), but no explicit when-to-use/when-not-to-use or alternative naming is provided. The licensing/key note adds context but not selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What one company's published subprocessor list says, as this record holds it: every row quoted as the company wrote it, with the purpose and location it printed, when the row was first and last seen here, the source page and the date it was read. Says so when no list for that company has been read. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | A company with a list on this record: its domain (notion.so) or its name (Notion). One company per call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses exact row contents, quoting behavior, date tracking, what happens when no list exists, and even legal/re-use restrictions. This is unusually transparent behavioral and policy context for an AI agent.
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 well-structured and front-loaded with the core content, but it repeats the 'every row' point twice and spends substantial space on legal restrictions. Most of that is useful, but the redundancy makes it less crisp than it could be.
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 complete: it explains the data returned, source attribution, empty-list behavior, and usage permissions. An agent has enough information to select and invoke 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%: the company parameter is already documented with domain-or-name guidance and a one-company-per-call restriction. The description reinforces that only one company is handled but adds no new parameter-level meaning beyond what the schema provides.
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 (one company's published subprocessor list) and what the record contains, including row-level details and the no-list case. It stops short of a crisp verb like 'returns' or 'lists,' and does not explicitly distinguish itself from sibling 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?
There is no guidance on when to use this tool versus siblings such as changes, in_chain, or as_of. The description implies this is the tool for retrieving a single company's stored list, but it never states that or offers exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which companies name one subprocessor on their published lists, with the name each company prints for it, when it was first seen on that list and when the list was read. One subprocessor per call. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| subprocessor | Yes | A subprocessor named on at least one list: its name, an alias, or its id here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it explains the output shape (companies, printed name, first-seen, read date), that each row is a dated quote from a company's published page, that it is read-only in nature, and that reuse is legally restricted. It does not cover rate limits or error behavior, but it is far more transparent than a minimal read-tool description.
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 longer than typical but every sentence carries useful information: what is returned, the one-per-call constraint, citation requirements, and licensing restrictions. The core behavior is front-loaded before the legal notice, and nothing is purely 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 single-parameter read tool with no output schema and no annotations, the description explains the return semantics, the data source, and the permitted use well enough for an agent to call it correctly. It lacks an example or explicit no-match behavior, but those are minor gaps given the simple input 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?
The input schema already describes the single subprocessor parameter with 100% coverage ('its name, an alias, or its id here'). The tool description adds 'One subprocessor per call' but does not enrich parameter semantics beyond the schema, so the schema-heavy baseline 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 clearly identifies the resource (companies' published subprocessor lists) and the specific operation: mapping a subprocessor to the companies that name it, plus the name printed, first-seen date, and read date. It does not explicitly distinguish itself from siblings like as_of, changes, or in_chain, so it lacks 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?
The description provides usage constraints ('One subprocessor per call', 'Free to read, cite and link') but never says when to use this tool versus alternatives such as list, resolve, or changes. There is no when-to-use or when-not-to-use guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What company a name on a list refers to, through this record's hand-checked identity table. Exact match only, never a guess: an unknown name comes back unresolved, which is an answer. Free to read, cite and link. Every row is a dated quote of a company's own published page: cite the page and the read date. The compilation is protected: extraction or re-use of a substantial part is not permitted, and it may never be compiled into a lead list, a prospecting feed or a sales tool. A key is one reader's own use.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name as printed on a list, or an alias. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it delivers substantially: exact-match-only behavior, unknown names returning 'unresolved' as a valid answer, read-only semantics ('Free to read'), and data provenance (dated quotes requiring page and read-date citation). The licensing restrictions add contextual depth. The main gap is that the description never discloses what a successful resolution actually returns.
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 first two sentences front-load purpose and matching behavior effectively. But the final three sentences are dense with licensing/provenance content, with some redundancy in the restriction language, and 'A key is one reader's own use' is cryptic. It is informative but slightly over-long for a single-parameter lookup 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 one-parameter tool with no annotations, the description covers matching behavior, the unresolved case, provenance, and usage restrictions. However, with no output schema present, it never explains what a successful resolution returns, leaving a real gap for an agent deciding how to interpret the result. Some of the licensing prose is also peripheral to 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 coverage is 100% — the schema already documents the parameter as 'A name as printed on a list, or an alias.' The description adds genuine value by stating the exact-match requirement and the 'never a guess' rule, which tells an agent not to pass partial, fuzzy, or approximate inputs. This meaningfully exceeds the schema-only baseline.
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 opening sentence states a specific purpose: 'What company a name on a list refers to' — a clear verb-resource pairing (resolve a name to a company identity) that distinguishes it from the temporal/relationship siblings (as_of, changes, changes_across, in_chain). However, it never explicitly contrasts itself with the closely-related named_by sibling, so full differentiation is left to inference.
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 use case — resolving a name on a list to a company — and states the matching constraint ('Exact match only, never a guess'). But it provides no explicit when-to-use vs. alternatives guidance, names no sibling tool, and offers no exclusions. The 'never a guess' line is more behavioral than routing guidance.
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.
as_ofchangeschanges_acrossin_chainlistnamed_byresolveRead-only record of AI vendor sub-processor lists, DPA notice windows and model retirements
Experimental GDPR grounding: rules, preconditions, exceptions, exact quotes, and citation checks.
Read public privacy policies: dated source excerpts, follow-up questions and change comparisons.
Run deterministic SaaS contract redlining, GDPR Art. 28 DPA & EU AI Act compliance audits.
Add one secure layer between your agents and this server.