A
licenseA
qualityA
maintenanceSource-aware archive for timeline-shift folklore, Mandela Effect reports and collider myths.
10
32 npm
MIT
CamFeed Journalism Archive
Server Details
Public read-only archive of journalist Cameron Wilson's work, appearances, and biography.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 98.8% over 43 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A3.9/5.0
Scored across 8 tools
Disambiguation2/5
Multiple tools overlap in purpose: search vs. search_journalism both search but differ in advanced filters; fetch vs. get_item both retrieve by ID but with different output types; featured_work vs. recommended_reading both return curated lists. The descriptions help somewhat but boundaries remain unclear for an agent.
Naming Consistency2/5
Tool names mix styles: bare verbs (fetch, search), verb_noun (get_item, search_journalism), and descriptive phrases (featured_work, latest_work, recommended_reading, work_by_topic). No consistent pattern across all names.
Tool Count5/5
With 8 tools covering search, retrieval, and curated lists, the count is well-scoped for a specialized journalism archive. Each tool serves a distinct niche, and the number is within the ideal 3-15 range.
Completeness4/5
The surface covers the major workflows: general search, advanced search, item retrieval, and curated/featured lists. Minor gaps like bulk listing or topic enumeration without search exist but are addressable via search_journalism.
Available Tools
8 toolsfeatured_workFeatured workARead-onlyIdempotentInspect
Use this when someone asks for Cameron Wilson's best, signature, representative, or recommended journalism. Return the pieces he would point a new reader to first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds meaningful context by explaining the curation behavior—'the pieces he would point a new reader to first'—which goes beyond a trivial read operation. It does not disclose edge cases or response details, but the additional curation rationale warrants a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the usage trigger, and contains no fluff or redundant information. Every word contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, annotations covering safety, and an output schema (though not shown), the description is largely complete. It clearly explains the tool's purpose and selection criteria. The only notable omission is how the 'limit' parameter behaves, but that is a minor gap given the tool's simplicity and the schema's constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'limit' with no description (schema coverage 0%). The description does not mention 'limit' at all, failing to compensate for the lack of schema documentation. While the parameter's name, type, default, and constraints are somewhat self-explanatory, the description should clarify that 'limit' controls the number of returned pieces, so it earns only 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns Cameron Wilson's best, signature, representative, or recommended journalism. It uses a specific verb ('return') and identifies the exact resource and selection criteria, distinguishing it from siblings like 'latest_work' or 'recommended_reading' by focusing on his personal curation for new readers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when someone asks for Cameron Wilson's best, signature, representative, or recommended journalism,' which is a clear trigger condition. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5 but is stronger than a 3 because the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch a CamFeed documentARead-onlyIdempotentInspect
Use this after search to retrieve the complete citation-ready text and metadata for one public CamFeed result. Do not use an arbitrary URL; pass the CamFeed id returned by search.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | CamFeed result id returned by search, for example camfeed-62. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context that the operation is for one public result and yields citation-ready text and metadata. It does not introduce new behavioral details beyond annotations, but the additional context about input rules (using search result id) adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence front-loads the purpose and usage timing; the second provides a critical constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with a schema and output schema, the description covers when to use it, what to pass, and what to expect. It is adequate for an agent to select and invoke the tool correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'id' documented as 'CamFeed result id returned by search, for example camfeed-62.' The description reinforces this by instructing to use the CamFeed id from search, but adds no new meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'the complete citation-ready text and metadata for one public CamFeed result.' It specifies the resource (CamFeed result) and the action (retrieve). It also distinguishes itself by requiring a CamFeed id returned by search, differentiating from arbitrary URL fetches and sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this after search.' It also provides a clear when-not: 'Do not use an arbitrary URL; pass the CamFeed id returned by search.' This gives direct context and a constraint, fulfilling the when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_itemGet archive item or story bundleARead-onlyIdempotentInspect
Use this when a CamFeed item id is known and richer archive detail is needed. Optionally retrieve ABC full text, a media transcript, or an article-centred story bundle containing commentary, appearances, and social context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| include_full_text | No | ||
| include_transcript | No | ||
| include_transcripts | No | ||
| include_related_content | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (read-only, idempotent, non-destructive). The description adds context about optional enrichments and bundle contents, which is useful beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling 30 words. Front-loaded with usage guidance and a succinct list of optional features. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return format is covered. The description addresses use case and optional features. The only notable gaps are the dual transcript parameter ambiguity and the unexplained 'ABC full text', but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain parameters. It describes the options (full text, transcript, related content) but leaves ambiguity between include_transcript and include_transcripts (singular vs plural). It does not explicitly map each flag to its parameter name, which could confuse an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific use case: retrieving archive detail for a known CamFeed item id. It mentions optional enrichments (full text, transcript, story bundle) which distinguish it from siblings like search or latest_work that do not focus on id-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening 'Use this when a CamFeed item id is known' provides a clear condition for invocation. However, it does not explicitly mention alternatives or when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
latest_workLatest workARead-onlyIdempotentInspect
Use this when someone asks for Cameron Wilson's latest or recent published work. Return recent public items from the same canonical source as CamFeed RSS and JSON.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds that items are 'recent public items' from a 'canonical source' (CamFeed RSS and JSON), which clarifies data scope and provenance beyond the annotations. This is useful context without contradicting the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences, front-loaded with the usage trigger. Every word earns its place, and it avoids redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one well-defined parameter, strong annotations, and an output schema, the description is adequate. It clarifies the source and public nature of the data without needing to explain return values (covered by output schema) or safety (covered by annotations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the single 'limit' parameter at all. While the schema provides a self-explanatory name, default, and bounds, the low coverage means the description should compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns recent public items for Cameron Wilson, with a specific verb ('return') and resource ('published work'). It doesn't explicitly distinguish itself from sibling tools like featured_work or work_by_topic, but the 'latest or recent' framing provides enough specificity for a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when someone asks for Cameron Wilson's latest or recent published work,' giving a clear trigger condition. It does not mention when not to use it or name alternatives, but the context is sufficiently clear for a tool of this simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommended_readingRecommended readingARead-onlyIdempotentInspect
Use this when someone wants a short, curated reading list of Cameron Wilson's work on a topic. Do not use it for exhaustive archive enumeration.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| topic | No | |
| reading_list | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the output is curated and short, and that exhaustive enumeration is not the intended use, which complements the annotation without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary use case and an explicit exclusion. No unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only recommendation tool with an output schema, the description covers purpose and usage boundaries. However, the lack of parameter semantics is a minor gap given the 0% schema coverage, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain parameters. It does not mention 'topic' or 'limit' at all, leaving the agent to infer their meanings. The schema provides a default and bounds for limit, but no semantic context is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing a short, curated reading list of Cameron Wilson's work on a topic. It also distinguishes itself from exhaustive archive enumeration, differentiating it from sibling search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when someone wants a short, curated reading list') and when not to use ('Do not use it for exhaustive archive enumeration'), giving clear guidance relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Cameron Wilson's journalismARead-onlyIdempotentInspect
Use this when someone asks about Australian journalist Cameron Wilson, his reporting, biography, appearances, or published work. Search the public CamFeed archive and return canonical, citable results. Use fetch to retrieve a selected result.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query about Cameron Wilson or his published work. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| results | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by stating results are 'canonical, citable' and that 'fetch' should be used to retrieve a selected result, which clarifies the tool's output nature and workflow 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the trigger condition and concise about the operation and next step. Every phrase earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, strong annotations, and an output schema, the description covers the essential context: when to use it, what it searches, and the follow-up action. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'query' parameter as a natural-language search. The description does not add significant parameter-level detail beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool searches Cameron Wilson's journalism, reporting, biography, appearances, and published work. It names the resource (public CamFeed archive) and the action (search), making the purpose highly specific and distinguishable from generic search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('when someone asks about Australian journalist Cameron Wilson'), which is clear. However, it does not name alternatives or exclusion criteria, such as when to use the sibling 'search_journalism' instead, so it falls short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_journalismAdvanced journalism searchARead-onlyIdempotentInspect
Use this for advanced searches of Cameron Wilson's public archive when source, content type, date filters, transcript matching, or matched snippets are needed. Query is optional; pass only filters to enumerate. Prefer search and fetch for OpenAI knowledge retrieval.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date or datetime; include items published on or before this. | |
| from | No | ISO date or datetime; include items published on or after this. | |
| kind | No | Filter by item kind. | |
| limit | No | ||
| query | No | Free-text search across title, summary, body, article full text, media transcripts, and quotes. | |
| source | No | Filter by underlying source. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: 'Query is optional; pass only filters to enumerate' and mentions transcript matching and matched snippets, which are operational details beyond basic read-only semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: first defines purpose and triggers, second clarifies optional query and alternative tool preference. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, output schema, and 6 params, the description covers purpose, usage, and exclusions. It does not describe enumeration details or pagination, but limit parameter and output schema mitigate this. Slight gap is acceptable given structured metadata richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (5 of 6 params described; limit lacks a description). The description only groups parameters into categories ('source, content type, date filters') without adding new meaning, so it does not significantly supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies 'advanced searches of Cameron Wilson's public archive' with concrete triggers: source, content type, date filters, transcript matching, matched snippets. It also distinguishes from siblings by stating 'Prefer search and fetch for OpenAI knowledge retrieval,' making it clear this tool is for archive-specific advanced querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when source, content type, date filters, transcript matching, or matched snippets are needed.' It also names alternatives ('search and fetch') and clarifies optional query behavior, providing solid selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
work_by_topicWork by topicARead-onlyIdempotentInspect
Use this when someone asks what Cameron Wilson has published on a particular topic. Match declared or derived topics, titles, and text.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only and idempotent. The description adds useful behavioral detail: it matches 'declared or derived topics, titles, and text', indicating fuzzy or broad matching rather than exact match only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the usage trigger, and each sentence adds value. No redundant or filler language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a small parameter set, an output schema, and clear annotations. The description covers purpose and matching behavior sufficiently. It could be more explicit about how it differs from 'search' or 'search_journalism', but the topic-specific focus makes it adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'topic' is matched against topics, titles, and text, and may include derived topics. However, it does not add meaning for the 'limit' parameter, which remains self-explanatory only through the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to retrieve what Cameron Wilson has published on a particular topic. The verb 'use this when' plus the specific subject (Cameron Wilson) and matching logic (topics, titles, text) distinguishes it from sibling tools like latest_work or featured_work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this when someone asks about Cameron Wilson's publications on a particular topic. It does not list exclusions or alternatives, but the context is clear enough for an agent to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
search_journalism1 field changed- changed
Input schema / properties / kind / enumPrevious value: -[ - "news article", - "blog post", - "newsletter commentary", - "mastodon post", - "appearance", - "video clip" -]New value: +[ + "news article", + "blog post", + "newsletter commentary", + "mastodon post", + "appearance", + "audio", + "video clip" +]
8 tool updates
- First observed
featured_work - First observed
fetch - First observed
get_item - First observed
latest_work - First observed
recommended_reading - First observed
search - First observed
search_journalism - First observed
work_by_topic
Related MCP Connectors
Israeli news in Hebrew and English: stories, sources, comparisons, coverage gaps, people and trends.
Evidence-first news archive: briefs, breaking news, search, Palestine claims, conflict monitor.
Living, source-backed timelines of long-running events, with a quote and source per entry.
Cameron Rye's blog, projects, resume, and live site stats, plus contact and newsletter tools.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenance📇 ☁️ - Capture web pages as cryptographically signed, tamper-evident evidence. Ed25519 signatures, RFC 3161 timestamps, and WACZ archives. Four tools: capture_url, get_capture, list_captures, verify_capture.5 npm1MIT
- AlicenseAqualityAmaintenanceRead-only, source-linked news intelligence for AI agents: search The Neural Ledger's stories, retrieve story details with citations and revision history, and resolve related entities and assets. It is an evidence layer, not a trading or execution service.82MIT
- AlicenseNot gradedqualityDmaintenanceReal-time curated knowledge API for AI agents. Updated Mon/Wed/Fri from 31 sources covering AI/tech, startups, alternative markets, and emerging markets — no scraping or storage required.1MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.