Search and read VI Update and Good Day (U.S. Virgin Islands news) and The Straight Record.
Scored across 8 tools
Most tools target clearly different needs (find vs. read vs. browse vs. meta), and descriptions explicitly differentiate fetch (raw text) from get_good_day_edition/get_straight_record_edition (structured editions). However, latest vs. list_items overlap (list_items newest-first can emulate latest), and claims_of_the_week duplicates content already returned by get_straight_record_edition on Sundays, forcing the agent to reason about which to pick.
Two tools follow a clean get_<resource> pattern, but the rest are bare verbs/nouns in mixed styles (fetch, search, latest, about, list_items, claims_of_the_week). Readable and snake_case throughout, but no single predictable convention ties the set together.
Eight tools is well-scoped for an archive covering three publications: discovery (search/list_items/latest), retrieval (fetch and two structured edition getters), and orientation (about, claims_of_the_week). No tool feels redundant enough to remove and none of the core workflows is squeezed into an overloaded tool.
The surface covers the full read lifecycle for all three publications: discovery, paging, full-text retrieval, structured edition access, and scope explanation. Minor gaps remain—search cannot be date-bounded or filtered by verdict/section, and there is no explicit tool to enumerate publications or their metadata beyond the free-text about.
What this server holds: how many published items each publication has, the date range each covers, when the VI Update and Good Day data were last refreshed, how each publication is credited, and what is not included. Use for questions about scope, or before reading an empty search as a gap in coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds useful behavioral context by disclosing that the tool reports coverage counts, refresh recency, publication credits, and what is not included, which helps the agent understand the limitations of the data.
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 definition is compact and front-loaded: it first states what the server holds, then gives the operational use case. Both sentences carry useful information without redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema informational tool, the description is complete enough to tell an agent what coverage details are available and why to call it. It covers counts, date ranges, refresh status, credit information, exclusions, and the main use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify beyond the baseline. The description does not need to explain parameter meanings, and the empty schema is consistent with a no-argument informational 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 names a specific meta-resource: server coverage, per-publication counts, date ranges, refresh timestamps, credits, and exclusions. An agent can distinguish this from sibling tools like search, list_items, fetch, latest, and edition getters because it is explicitly about scope rather than retrieving content.
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 usage conditions: questions about scope, or checking coverage before interpreting an empty search as missing data. It does not explicitly name alternative tools or when not to use it, but the intended context is clear from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Claim of the Week fact check from Straight Record Sunday editions, newest first: the claim as quoted, who said it and when, the verdict and the analysis, with the edition date, URL and citeAs line. Use for what The Straight Record has fact-checked. Verdicts are the edition's assessment as of its date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many, 1 to 50. Default 10. |
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 real value beyond that: it discloses the sort order ('newest first') and a substantive caveat that 'Verdicts are the edition's assessment as of its date', warning the agent that verdicts are point-in-time snapshots rather than current judgments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and then the payload contents, ending with the usage cue. The enumeration of returned fields is dense but each item is informative; the only mild redundancy is restating the resource name in the second sentence.
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 correctly compensates by listing the returned fields (claim text, speaker, date, verdict, analysis, edition date, URL, citeAs). Combined with annotations covering the safety profile, an agent has what it needs to call this correctly; only pagination behavior for the limit is left implicit.
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 a single parameter at 100% schema description coverage, the schema already documents limit ('How many, 1 to 50. Default 10.'). The description contributes only indirectly via the 'newest first' ordering, which implies the limit truncates the most recent entries; it never mentions the parameter, its range, or the default. 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?
Names a specific resource (the Claim of the Week fact check from Straight Record Sunday editions) with a verb-like scope and an ordering guarantee ('newest first'). It enumerates what each record contains, so an agent knows exactly what it is retrieving. It stops short of explicitly contrasting itself with the sibling get_straight_record_edition, which is the closest potential confusion.
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?
'Use for what The Straight Record has fact-checked' gives a positive usage context, which is more than nothing. However, there is no exclusion guidance and no pointer to alternatives such as get_straight_record_edition for full editions or search for targeted lookups, so an agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The full text of one published item, by the id search or a list returns (such as "viupdate:", "goodday:036" or "straightrecord:042") or by its public URL. Use for reading an article or edition before quoting or summarizing it. Returns up to 40,000 characters at a time inside a fence labeled as untrusted data; a longer item continues from next_offset. Metadata carries the date, the credit, the citeAs line and, for a VI Update article with a video, the Facebook link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from search, latest or list_items, or the item's public URL. | |
| offset | No | Character position to start from, for the next window of a long item. Default 0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent read, but the description adds materially more: a 40,000-character window per call, continuation via next_offset, and the fact that content is returned inside a fence labeled as untrusted data. It also discloses what metadata accompanies the text (date, credit, citeAs line, Facebook link for video VI Update articles), so an agent knows both the truncation model and the response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the identifier question, then the intended use, then the return contract. No filler; even the metadata enumeration in the final sentence earns its place because there is no output 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?
With no output schema, the description carries the return contract and does so adequately: windowing limit, continuation mechanism, untrusted-data fencing, and metadata fields. Combined with the annotations, an agent has everything needed to call this correctly and interpret the result.
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 alone would justify a 3. The description still adds value by giving concrete id formats and by explaining that offset/next_offset produces the next window of a long item, which ties the two parameters together in a way the schema's per-field text does not.
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?
States a specific verb and resource ('The full text of one published item') and pins down the two accepted identifiers — an id from search or a list, with concrete format examples like 'viupdate:<slug>' and 'goodday:036', or a public URL. This is enough for an agent to distinguish it from search, latest, and list_items without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage context ('Use for reading an article or edition before quoting or summarizing it') and points to search/latest/list_items as the source of ids, which implicitly routes the agent's workflow. It does not explicitly exclude the edition-specific siblings (get_good_day_edition, get_straight_record_edition), so the reader must infer that this is the generic path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Good Day, This Week edition in full and in structure, by its number (such as "036" or "36"), or the newest when no number is given. Use for the week's stories with their sources, the tracked weekly items (WAPA, government, federal, infrastructure), By the Numbers and Also This Week. Good Day is an automated news digest and analysis, operated by Brian Louden, and each edition says so in its byline.
| Name | Required | Description | Default |
|---|---|---|---|
| edition | No | Edition number, such as "036" or 36, or the edition URL. Default: the newest edition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered and the bar is lower. The description adds provenance (automated digest, operated by Brian Louden, stated in the byline) but nothing operational — no edition size, no note on what 'in structure' means for the response, no behavior when an edition number is out of range or malformed.
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 resource and its identifier, with the content listing following in a single compact sentence. The closing aside about Brian Louden and the byline is not needed for tool selection and the phrase 'in full and in structure' is imprecise filler, but the text stays short and readable overall.
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-optional-parameter read with no output schema and rich annotations, the definition covers identity, identifiers, and content sections adequately. It remains incomplete about the return shape ('in structure' is never explained), response size for a full edition, and how it relates to the latest and get_straight_record_edition siblings.
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% and already documents the edition number/string and the newest default, so the baseline is 3. The examples ('036' or '36') merely restate the schema's own example, and the description omits the edition-URL form the schema explicitly supports, so it adds no meaning beyond the structured field.
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?
Names the specific resource (one 'Good Day, This Week' edition) and the two retrieval modes (by number, or newest by default), so the agent knows exactly what comes back. 'In full and in structure' is vague and does not clearly differentiate it from siblings like latest or fetch, which matters since 'newest when no number is given' overlaps with a tool literally named latest.
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 does say what to use it for ('the week's stories with their sources, the tracked weekly items, By the Numbers and Also This Week'), which is real usage context rather than tautology. But it never names an alternative or a when-not: nothing tells the agent whether to prefer latest for the newest edition, or fetch/search/list_items for other needs, leaving the default-newest behavior potentially colliding with the latest sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One Straight Record edition in full, by its id (such as "042", "42" or "P001", or the edition URL), or the newest when no id is given. Use for reading every story's The Gap, Left Said, Right Said and The Record (or The Record So Far), with sources, verbatim quotes and their attributions, per-story anchor URLs, Consensus Watch, and on Sundays the Claim of the Week and Democracy Watch. Facts are as of the edition date.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Edition id, such as "042" or "P001", or an edition URL. Default: the newest edition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that by enumerating the returned sections (The Gap, Left Said, Right Said, The Record, Consensus Watch, Sunday-only Claim of the Week and Democracy Watch) and by flagging the data-freshness caveat that facts are as of the edition date.
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 addressing rule and default are front-loaded in the first clause, with content scope and freshness caveat following. The long run-on section enumeration is dense but each item carries information, so little is wasted.
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 correctly takes on the return-shape burden and describes the edition's contents and the Sunday variation. Only minor gaps remain, such as error behavior for an unknown or malformed id.
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%, and the schema already documents both the id forms and the newest-edition default. The description's examples ("042", "42", "P001", URL) largely restate that, adding little semantic meaning beyond the structured field, so 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?
States a specific verb and resource ("get one Straight Record edition in full") plus the exact addressing modes (id, alternate id forms, or URL) and the no-arg default. This clearly distinguishes it from siblings like get_good_day_edition, latest, and search without requiring the schema to be opened.
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?
"Use for reading every story's..." gives explicit usage context, and the default-to-newest behavior is stated. It stops short of naming when to prefer siblings such as latest, fetch, or search, so there is no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest published items: by default the newest VI Update articles, the newest Good Day, This Week edition and the newest Straight Record edition; or the newest items of one publication. Use for "what is new" or for current coverage. Each item has an id for fetch, its date, headlines or an excerpt, a URL and a citeAs line.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items per publication, 1 to 20. Default 5 for VI Update and 1 for each edition series when all three are asked for; 5 for one publication. | |
| section | No | One publication: "vi_update", "good_day" or "straight_record". Default: all three. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes further by disclosing the shape of each returned item — id usable with fetch, date, headline or excerpt, URL, citeAs — which helps the agent chain into fetch. It does not mention ordering ties, pagination, or what happens when a publication has no recent items.
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 default behavior is front-loaded and the alternative (single publication) follows, then the item shape. The semicolon-chained opening sentence is dense but readable; the quoted use case and the return-shape clause both earn their place.
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, yet the description compensates by enumerating the returned fields and pointing at fetch for full retrieval. With only two well-documented optional parameters and rich annotations, an agent has what it needs to call this correctly; only error/empty-result behavior is unstated.
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%, and the schema already documents both limit and section including the per-publication default counts. The description restates the default composition (all three publications) but adds no new syntax, enum values, or edge-case 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 states precisely what is returned: the newest published items from VI Update, Good Day, This Week and Straight Record by default, or the newest items of a single publication. That is a concrete resource plus scope, not a restatement of the name. It stops short of naming a sibling tool to contrast with, so an agent must infer how this differs from list_items or claims_of_the_week.
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?
"Use for 'what is new' or for current coverage" gives explicit when-to-use context that an agent can match against a user request. There is no when-not guidance and no sibling is named as the alternative for deeper or historical browsing, which is the main gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published items of one publication, newest first, optionally between two dates, with paging. Use for browsing what a publication ran in a week, month or year. VI Update articles are dated by the date the article shows; Good Day and Straight Record editions by their publication date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items, 1 to 50. Default 20. | |
| offset | No | How many items to skip, for the next page. Default 0. | |
| date_to | No | Latest date, inclusive: a year, a month (its last day) or a day. | |
| section | Yes | Which publication: "vi_update" (VI Update articles), "good_day" (Good Day, This Week editions) or "straight_record" (The Straight Record editions). | |
| date_from | No | Earliest date, inclusive: a year (2026), a month (2026-10) or a day (2026-10-05). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavior beyond that: newest-first ordering, optional inclusive date bounds, paging, and section-specific dating rules.
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 definition is three tight sentences with the core purpose front-loaded, followed by a concrete use case. The section-dating caveat is non-obvious and earns its place.
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 read-only listing tool with five fully described parameters and no output schema, this covers scope, ordering, paging, and date semantics well. The main remaining gap is explicit routing versus siblings like search, latest, or the edition-specific getters.
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 parameters are already well documented. The description adds meaning beyond the schema by explaining that VI Update articles are dated by the displayed article date while Good Day and Straight Record are dated by publication date.
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 ('Published items of one publication'), the date-range filter, ordering ('newest first'), and paging, and it states the browsing use case. It does not explicitly name sibling tools such as search, latest, or fetch, so sibling differentiation is implied rather than stated.
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 usage context: browsing what a publication ran in a week, month, or year. It does not say when not to use this tool or name alternatives like search or latest, so exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across published VI Update articles, Good Day, This Week editions and The Straight Record editions, or one of them. Use for finding coverage of a person, place, agency or event. Each result has an id for fetch, a title, a URL with a story anchor where there is one, a snippet, a match tier (exact phrase, all words, some words) with the reason, and its own citeAs line. Results are ranked by tier, then by whether the headline carries the match; across all three publications they take turns within a tier. Paging uses offset and next_offset. Facts are as of each item's date.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results, 1 to 25. Default 10. | |
| query | Yes | Words or a phrase, such as "WAPA rationing" or "Strait of Hormuz". | |
| offset | No | How many ranked results to skip, for the next page. Default 0. | |
| section | No | Limit to one publication: "vi_update", "good_day" or "straight_record". Default: all three. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent and closed-world, so the description goes further by disclosing ranking logic (tier, then headline match, round-robin across the three publications), the match-tier vocabulary, paging via offset/next_offset, and the freshness caveat 'Facts are as of each item's date.' That is real behavioral context beyond 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?
Purpose is front-loaded in the first clause and the rest is packed with payoff sentences about result shape and ranking. The ranking/tie-break sentence is long, but it is not padding — every sentence conveys a distinct fact.
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?
Output schema is absent, and the description verifies the return contract by listing id, title, URL with anchor, snippet, match tier plus reason, and citeAs. Ranking, paging and freshness are covered. Only minor gaps remain: no mention of empty-result behavior or limits on the query string beyond the schema's maxLength.
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 query, limit, offset and section are already documented; the description adds only the paging mechanic (offset/next_offset exists as a return field) and the implied per-publication scope. It does not add query syntax or limit-range meaning beyond what the schema states, 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?
States a specific verb ('Keyword search') plus the exact resources covered (VI Update articles, Good Day, This Week, The Straight Record) and the scope option ('or one of them'). This clearly separates it from siblings like fetch, latest and list_items.
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?
'Use for finding coverage of a person, place, agency or event' gives an explicit use case, and 'Each result has an id for fetch' quietly routes the agent to the follow-up tool. There is no explicit when-not-to-use or comparison against latest/list_items for browsing recent items.
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.
aboutclaims_of_the_weekfetchget_good_day_editionget_straight_record_editionlatestlist_itemssearchSearch Virgin Islands newspapers page by page, 1865 to 2001, with the gaps in every run named.
Search and read U.S. Virgin Islands public records: laws, court records, audits, hearings, reports.
Puerto Rico news summaries and live island conditions from 787daily, read-only over MCP.
Add one secure layer between your agents and this server.