Public read-only archive of journalist Cameron Wilson's work, appearances, and biography.
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 |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
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.
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.
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.
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.
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.
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.
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. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
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.
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.
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.
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.
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.
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.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
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 |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
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.
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.
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.
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.
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.
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.
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 |
| Name | Required | Description |
|---|---|---|
| topic | No | |
| reading_list | Yes |
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.
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.
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.
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.
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.
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.
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. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
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.
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.
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.
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.
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.
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.
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. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
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.
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.
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.
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.
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.
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.
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 |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| items | Yes | |
| title | No | |
| description | No |
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.
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.
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.
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.
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.
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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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.
No comments yet. Be the first to start the discussion!
Evidence-first news archive: briefs, breaking news, search, Palestine claims, conflict monitor.
Cameron Rye's blog, projects, resume, and live site stats, plus contact and newsletter tools.
Read-only public Twitter data and TweetAPI docs for AI agents. Not affiliated with X Corp.
Forensic archive of javaBin & JavaZone origins (1998-2007) as a signed KCP knowledge web.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
