Dated quotes of GDPR art. 28 subprocessor lists: who lists whom, what changed, and when.
Scored across 7 tools
Each tool targets a distinct query: current list, historical snapshot, single-company diffs, multi-company diffs, reverse lookup, identity resolution, and supply-chain traversal. Even though changes and changes_across share the same underlying facts, their scope is clearly different and the descriptions make that explicit.
All tool names are lowercase snake_case and reasonably concise, so there is no jarring stylistic mix. The grammatical pattern is not uniform (nouns like list and changes, verbs like resolve, prepositional phrases like as_of and in_chain), but the naming is still predictable enough for an agent to infer intent.
Seven tools is well-scoped for a read-only record service. Each tool covers a meaningful query type without redundancy, and the count feels neither bloated nor thin for the domain.
The surface covers the main record queries thoroughly: current lists, historical points, changes, reverse lookup, identity resolution, and multi-hop paths. A minor gap is the lack of any discovery or enumeration tool for finding companies or subprocessors in the record, but the core workflows are not blocked.
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 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?
With no annotations, the description carries the behavioral burden and does substantial work: it discloses that a key on a running-watch account is required, that unmatched names and unresolved rows are returned alongside paths, that rows are dated quotes, and that usage is restricted. It leaves exact output formatting unspecified but provides meaningful behavioral context beyond the schema.
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 overly long and mixes technical behavior with legal licensing and philosophical language like 'It says who to ask, never who is harmed.' Useful information is present, but several sentences about compilation protection and reader key usage could be compressed without losing essential meaning.
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 tool with no output schema, the description provides a reasonable amount of context: path semantics, authentication requirements, licensing, and resolution failure behavior. However, the hop-depth rule is ambiguous ('A second hop is a different relationship') and the exact return shape is never clarified, leaving notable gaps.
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 already documents both parameters with 100% coverage, so the baseline is 3. The description adds helpful context by framing companies as 'the companies a reader buys from' and target as 'the subprocessor to look for,' but it does not meaningfully extend the parameter semantics 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 states the core operation: given a reader's companies and a target subprocessor, return every path from those companies to that subprocessor, either directly or through a company's own list. This distinguishes the tool as a chain-traversal lookup, though it does not explicitly contrast it with siblings like named_by or resolve.
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 explicit guidance is given about when to use in_chain instead of the sibling tools. The description mentions constraints like requiring a running watch and a key, but does not state the deciding conditions between in_chain and named_by, changes, or resolve.
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_byresolveExperimental GDPR grounding: rules, preconditions, exceptions, exact quotes, and citation checks.
Compares public supplier snapshots for material changes.
Sourced history: 85,753 dated events, each quoted from a citable Wikipedia revision id.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Add one secure layer between your agents and this server.