CamFeed Journalism Archive
Server Details
Public read-only archive of journalist Cameron Wilson's work, appearances, and biography.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 8 of 8 tools scored.
Some tools have overlapping purposes. 'search' and 'search_journalism' both perform archive searches, with the latter being a more advanced version, which could confuse an agent. Similarly, 'fetch' and 'get_item' both retrieve items by ID, though 'get_item' offers richer detail. The other tools are more distinct in intent.
All tool names use lowercase with underscores, which is consistent. However, they deviate from a strict verb_noun pattern: some are adjective_noun (featured_work, latest_work, recommended_reading) or noun_preposition_noun (work_by_topic). This inconsistency in grammatical form slightly reduces clarity.
With 8 tools, the server is well-scoped for a journalism archive. Each tool serves a clear purpose: search, advanced search, retrieval, curated lists, topic exploration, and recent/featured works. No tool seems redundant, and the count is appropriate for the domain.
The tool surface covers common archival operations: searching, retrieving full content, and browsing by topic, recent, or featured. Minor gaps exist, such as no tool for listing all works or for date-range browsing without an advanced search filter, but these are not critical for the archive's purpose.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context by noting that it returns works 'he would point a new reader to first,' which is beyond what annotations provide.
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 with no wasted words, front-loaded with purpose. Every sentence earns its place, and the structure is efficient.
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 tool with one parameter and an output schema, the description provides all necessary context: when to use, what to expect, and no missing details.
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 describes the single parameter 'limit' with default, min, max. The description does not mention the parameter, but since schema coverage is 100%, the baseline is 3.
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 specifies the tool's purpose: returning Cameron Wilson's best/signature/recommended journalism. It uses specific verbs like 'return' and resource 'pieces', distinguishing it from siblings such as 'search' or 'latest_work'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use this when someone asks for Cameron Wilson's best, signature, representative, or recommended journalism.' This provides clear context and implicitly excludes alternative tools.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | CamFeed result id returned by search, for example camfeed-62. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, indicating a safe, deterministic read operation. The description adds 'retrieve... citation-ready text and metadata' which aligns but does not contribute significant new behavioral context.
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 efficient sentences, front-loaded with the core purpose and usage constraint. No unnecessary words, every sentence adds 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?
Given the tool's simplicity (one required parameter, output schema present, annotations covering behavior), the description fully covers what a user needs to know: when to use, what to pass, and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description for 'id'. The description reinforces this by stating 'pass the CamFeed id returned by search', but does not add new semantic detail 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 states the verb 'retrieve', the resource 'CamFeed result', and the purpose 'citation-ready text and metadata'. It distinguishes from search by specifying 'after search' and from siblings by focusing on a single document retrieval.
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?
Explicitly says 'Use this after search' and warns 'Do not use an arbitrary URL; pass the CamFeed id returned by search.' This provides clear context and exclusions, though it does not explicitly name alternative tools for other use cases.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| include_full_text | No | ||
| include_transcript | No | ||
| include_transcripts | No | ||
| include_related_content | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true, so safety is clear. The description adds value by detailing optional inclusions (full text, transcript, story bundle), which are behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with usage context, and every sentence adds value without redundancy.
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?
Given the presence of an output schema and annotations, the description adequately covers the tool's functionality, but could improve by fully parameter semantics. Overall, it provides sufficient context for an AI agent.
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 0% schema description coverage, the description compensates partially by mentioning optional retrieval of 'ABC full text, a media transcript, or an article-centred story bundle', but it does not clarify the difference between include_transcript and include_transcripts, leaving ambiguity.
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 'Get archive item or story bundle' and specifies the condition 'when a CamFeed item id is known and richer archive detail is needed', distinguishing it from sibling tools like search or fetch.
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 explicitly states when to use ('when a CamFeed item id is known and richer archive detail is needed'), but does not provide explicit when-not-to-use or name alternative tools, though context implies it.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds source (CamFeed), format (RSS and JSON), and public nature, which is useful beyond 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?
Two sentences, front-loaded, no filler. Efficient and clear.
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 an output schema present, the description covers source and intent. Missing parameter explanation reduces completeness slightly.
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?
Description does not mention the 'limit' parameter despite 0% schema description coverage. Schema provides default/min/max but description adds no semantic meaning.
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?
Description clearly states the tool returns Cameron Wilson's latest/recent published work from CamFeed RSS/JSON. It specifically ties to a person and source, but does not distinguish from siblings like featured_work or recommended_reading.
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?
Explicitly says when to use (for latest/recent work), but provides no when-not-to-use or alternatives among siblings.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| topic | No | |
| reading_list | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by indicating the tool returns a curated (not exhaustive) list, which is not in the annotations. It does not contradict any 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?
Two sentences, front-loaded with purpose, no wasted words. Highly 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?
Given 0% schema coverage and lack of parameter details, the description is incomplete. However, purpose and usage are clear, and output schema exists to describe return format.
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 0%, and the description does not explain the parameters (topic, limit) or their semantics. The description implies 'topic' but no details on limit or constraints.
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 verb ('use this when someone wants a... reading list'), the resource ('Cameron Wilson's work'), and differentiates from exhaustive enumeration, providing a specific and distinguishing purpose.
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 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'), offering clear guidance.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query about Cameron Wilson or his published work. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to repeat that. It adds value by stating the results are 'canonical, citable' and from a 'public archive,' which gives behavioral context beyond the structured annotations. No contradictions.
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 extremely concise at two sentences, with the crucial usage guidance front-loaded. Every sentence adds necessary information without any fluff, making it easy for an agent to parse quickly.
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?
Given the tool has only one parameter and an output schema exists (even if not shown), the description sufficiently covers what the tool does and how to use it. It could mention result format or pagination, but the instructional note to 'use fetch to retrieve a selected result' implies a workflow, which is adequate.
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 for the single parameter 'query' has 100% coverage with a basic description. The tool description adds meaning by specifying 'natural-language search query about Cameron Wilson or his published work,' which clarifies the expected input format and scope, going beyond the schema's generic description.
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 purpose: to search the public CamFeed archive for information about Australian journalist Cameron Wilson, including his reporting, biography, appearances, and published work. It uses a specific verb (search) and resource (public CamFeed archive), and distinguishes itself from sibling tools like 'search_journalism' which may cover broader topics.
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 explicitly indicates when to use this tool: 'Use this when someone asks about Australian journalist Cameron Wilson...' It also provides a follow-up action: 'Use fetch to retrieve a selected result.' While it does not explicitly list when not to use it or name alternatives, the context is clear enough for an agent to decide.
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.
| 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
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. Description adds behavioral nuance: query optional, filters enumerate. No contradiction, and the added context (e.g., 'pass only filters to enumerate') enhances transparency beyond 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?
Two sentences, no redundancy. First sentence delivers purpose and conditions, second gives a specific usage tip and sibling preference. Every part 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?
Given 6 optional parameters and an output schema present, the description covers purpose, usage boundaries, parameter semantics, and behavioral hints. No gaps remain; return format is handled by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, so schema already documents most parameters. Description adds meaningful guidance: 'Query is optional; pass only filters to enumerate' explains the relationship between query and filters. It also reinforces date and source filtering, providing usage-oriented semantics beyond 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?
Description clearly states this tool performs advanced searches of Cameron Wilson's public archive with specific filters (source, content type, date, transcript matching, snippets). It distinguishes from siblings by noting 'prefer search and fetch for OpenAI knowledge retrieval', making the purpose and differentiation explicit.
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?
Explicitly describes when to use this tool ('when source, content type, date filters, transcript matching, or matched snippets are needed') and when not to ('prefer search and fetch for OpenAI knowledge retrieval'). Also notes query is optional and filters alone can enumerate, providing clear usage context.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| topic | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read-only behavior. The description adds that matching is based on 'declared or derived topics, titles, and text', which is useful but not extensive. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key use case, and every part adds value. No fluff.
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 search-like tool with an output schema, the description is adequate but lacks details on the matching algorithm or which fields are searched beyond 'topics, titles, and text'. It could be more precise.
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 0%, so 2 parameters (topic, limit) are undocumented in the schema. The description mentions 'topic' as the matching criterion but does not explain 'limit' or provide details on how matching works. Missing parameter-level guidance.
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 retrieves Cameron Wilson's publications by topic, with a specific verb 'Use this when someone asks' and resource 'what Cameron Wilson has published on a particular topic', distinguishing it from siblings like 'search' which are more general.
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 explicitly says when to use the tool ('when someone asks what Cameron Wilson has published on a particular topic'), providing clear context. It does not explicitly mention when not to use or list alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!