Connects to The Guardian's archives dating back to 1999, providing access to over 1.9 million articles. Enables searching the archive, retrieving full article text, exploring tags, finding related content, analyzing publication trends over time, and getting journalist profiles. Supports queries by date, length, author, and section.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@guardian-mcp-server search for articles about AI regulation from the last year"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that connects an LLM to the archives (since 1999) of The Guardian, including the full text of all articles — more than 1.9 million of them. Useful for real-time headlines, journalism analysis, and historical research.
A Guardian Open Platform API key is required. You can get one here: https://open-platform.theguardian.com/access/
The Guardian offers generous API access for non-commercial use of the archives, including up to 1 call/second and 500 calls/day. (See the full Terms & Conditions. Commercial use requires a different license.)
To install:
npx guardian-mcp-serverSample MCP client configuration:
{
"mcpServers": {
"guardian": {
"command": "npx",
"args": ["guardian-mcp-server"],
"env": {
"GUARDIAN_API_KEY": "your-key-here"
}
}
}
}Related MCP server: NYTimes MCP
guardian_search: search the archive for articles
Use thedetail_level parameter to determine the size of the API response and optimize performance: minimal (headlines only), standard (headlines, summaries, and metadata), or full (all content, including full article text).
{
"query": "climate change",
"section": "environment",
"detail_level": "minimal",
"from_date": "2024-01-01",
"order_by": "newest"
}guardian_get_article: retrieve individual articles
{
"article_id": "https://www.theguardian.com/politics/2024/dec/01/example",
"truncate": false // full content by default
}guardian_search_tags: search through The Guardian's 50,000-plus hand-assigned tags
guardian_find_related: find articles similar to an article (via shared tags)
guardian_get_article_tags: returns tags assigned to any article
{
"article_id": "politics/2024/example"
}guardian_lookback: historical search by date
guardian_content_timeline: analyze Guardian content on a particular topic over a defined period
{
"query": "artificial intelligence",
"from_date": "2024-01-01",
"to_date": "2024-06-30",
"interval": "month"
}guardian_top_stories_by_date: estimates editorial importance; The Guardian's API doesn't natively return data to differentiate between Page 1 stories and inside briefs, and this tries to hack a ranking together
{
"date": "2016-06-24", // Brexit referendum day
"story_count": 5
}guardian_topic_trends: compare multiple topics over time with correlation analysis and competitive rankings
{
"topics": ["artificial intelligence", "climate change", "brexit"],
"from_date": "2023-01-01",
"to_date": "2024-12-31",
"interval": "quarter"
}guardian_author_profile: generate profiles of Guardian journalists and what they cover
{
"author": "George Monbiot",
"analysis_period": "2024"
}guardian_longread: search The Long Read series, the paper's home for longform features
guardian_browse_section: browse recent articles from specific sections
guardian_get_sections: fetch all available Guardian sections
guardian_search_by_length: filter articles by word count
guardian_search_by_author: search articles by byline
guardian_recommend_longreads: get personalized Long Read recommendations based on interest
{
"count": 3,
"context": "I'm researching technology, especially AI",
"topic_preference": "digital culture"
}MIT license.
Generate comprehensive profile analysis for a Guardian journalist
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | Author/journalist name to analyze | |
| analysis_period | No | Year to analyze (e.g., "2024") or use from_date/to_date | |
| from_date | No | Start date (YYYY-MM-DD) - alternative to analysis_period | |
| to_date | No | End date (YYYY-MM-DD) - alternative to analysis_period |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'generate comprehensive profile analysis', implying a read-only operation that synthesizes data, but lacks details on what the analysis includes (e.g., metrics, trends, summaries), potential limitations like data availability, or output format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('generate') and resource, making it easy to parse quickly. Every part of the sentence contributes essential information, earning 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 the tool's complexity (analyzing journalist profiles with date ranges), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'comprehensive profile analysis' entails, how results are structured, or any behavioral traits like rate limits or data sources. This leaves significant gaps for an agent to use the tool effectively.
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 description coverage is 100%, with clear descriptions for all parameters (e.g., 'author/journalist name to analyze', date alternatives). The description adds no additional semantic context beyond the schema, such as examples of author names or date format nuances. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 'generate' and resource 'comprehensive profile analysis for a Guardian journalist', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'guardian_search_by_author', which might also involve author-related analysis, leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'guardian_search_by_author' and 'guardian_content_timeline' that might overlap in analyzing author content, there's no indication of specific use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse recent articles from a specific Guardian section
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Section ID (use guardian_get_sections to find valid IDs) | |
| days_back | No | How many days back to search (default: 7) | |
| page_size | No | Number of results, max 200 (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'browse recent articles' implies a read-only operation, it doesn't specify important behavioral aspects like whether results are paginated (beyond the page_size parameter), what format the articles are returned in, whether there are rate limits, or authentication requirements. The description is minimal and lacks the behavioral context needed for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently communicates the core purpose without any wasted words. It's appropriately sized for a straightforward browsing tool and front-loads the essential information. Every word earns its place in this concise formulation.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate but has clear gaps. It states what the tool does but lacks behavioral context, usage guidance, and output information. Without annotations or output schema, the agent must rely on the description alone, which doesn't provide complete context for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all three parameters well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description, which applies here.
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 action ('browse recent articles') and resource ('from a specific Guardian section'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'guardian_top_stories_by_date' or 'guardian_content_timeline' which might also retrieve articles, though the 'section' focus provides some implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools for retrieving Guardian content (e.g., guardian_search, guardian_top_stories_by_date, guardian_content_timeline), there's no indication of when this section-based browsing is preferred over other methods. The input schema mentions using guardian_get_sections to find valid IDs, but this is parameter documentation, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze content timeline for a topic over time showing trends and peaks
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic or search terms to analyze over time | |
| from_date | Yes | Start date (YYYY-MM-DD) | |
| to_date | Yes | End date (YYYY-MM-DD) | |
| interval | No | Time interval for analysis | |
| section | No | Filter by section (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analysis and output ('trends and peaks') but fails to describe critical behaviors like data sources, rate limits, authentication needs, error handling, or output format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words, but could be slightly more structured by explicitly mentioning key parameters or output details to enhance clarity without sacrificing brevity.
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 complexity of analyzing timelines with trends and peaks, no annotations, and no output schema, the description is incomplete. It should explain the return format (e.g., time-series data), data sources, or limitations to adequately guide the agent, but it provides only a high-level overview.
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%, so the schema fully documents all parameters. The description adds no additional meaning beyond the schema, such as explaining how 'query' relates to 'trends' or the impact of 'interval' on analysis. Baseline 3 is appropriate as the schema handles parameter documentation.
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 with specific verbs ('analyze content timeline') and resources ('for a topic over time'), and it distinguishes the output ('showing trends and peaks'). However, it doesn't explicitly differentiate from sibling tools like 'guardian_topic_trends' or 'guardian_lookback', which might have overlapping functionality, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context on prerequisites, exclusions, or comparisons to sibling tools such as 'guardian_topic_trends' or 'guardian_search', leaving the agent with no usage direction beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve full content of a specific Guardian article
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | The Guardian article ID or full URL (e.g., "politics/2024/dec/01/example" or "https://www.theguardian.com/politics/2024/dec/01/example") | |
| show_fields | No | Fields to include (default: headline,standfirst,body,byline,publication,firstPublicationDate) | |
| truncate | No | Whether to truncate content to preview length (default: false for full content) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'retrieves full content' but doesn't mention authentication requirements, rate limits, error handling, or what the output looks like (e.g., format, size). For a read operation with zero annotation coverage, this is a significant gap in transparency about how the tool behaves beyond the basic action.
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 a single, clear sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a straightforward retrieval tool, making it easy 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's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally complete. It covers the basic action but lacks details on output format, error cases, or behavioral constraints. With no output schema, the description should ideally hint at return values, but it doesn't, leaving gaps in context.
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%, so the schema fully documents all three parameters (article_id, show_fields, truncate). The description doesn't add any parameter-specific details beyond what's in the schema, such as examples for show_fields beyond the default or implications of truncation. Baseline 3 is appropriate when the schema does the heavy lifting.
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') and resource ('full content of a specific Guardian article'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like guardian_search or guardian_browse_section, which would require mentioning it fetches a single article by ID rather than searching or browsing, but the specificity of 'specific Guardian article' implies this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'specific Guardian article', suggesting it's for when you have a known article ID or URL. However, it doesn't explicitly state when to use this tool versus alternatives like guardian_search (for finding articles) or guardian_get_article_tags (for tags of an article), nor does it mention prerequisites or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed tag information for a specific Guardian article
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | Guardian article ID or full URL to inspect tags for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'detailed tag information' but doesn't specify what that includes (e.g., tag names, categories, counts), whether it's a read-only operation, potential rate limits, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed tag information' entails, how results are structured, or any behavioral traits like error handling. For a tool that presumably returns data, more context is needed to understand its output and usage fully.
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 description coverage is 100%, with the 'article_id' parameter fully documented in the schema as accepting either an ID or full URL. The description doesn't add any meaning beyond this, such as examples or format specifics, so it meets the baseline of 3 where the schema does the heavy lifting.
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 action ('Get detailed tag information') and the target resource ('for a specific Guardian article'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'guardian_search_tags' or 'guardian_get_article', which would require a 5, but it's unambiguous about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'guardian_search_tags' (for searching tags) or 'guardian_get_article' (which might include tags as part of article data). It simply states what the tool does without context about its specific use case or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available Guardian sections
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but fails to describe key traits: whether it's a read-only operation, if it requires authentication, potential rate limits, the format of returned data (e.g., list of section names with IDs), or any pagination behavior. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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 a single, clear sentence that directly states the tool's function without any fluff or redundant information. It is front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place by conveying essential information.
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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on behavioral aspects like authentication needs or return format, which are important for a read operation. Without annotations or output schema, the description should provide more context to be fully complete, but it meets the basic requirement for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to compensate for any parameter gaps, as there are none to document. It appropriately focuses on the tool's purpose without unnecessary parameter details, aligning with the baseline for zero parameters.
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 action ('Get') and the resource ('all available Guardian sections'), making the purpose immediately understandable. It distinguishes this from siblings like guardian_browse_section (which likely retrieves content within a specific section) and guardian_search (which searches across content). However, it doesn't specify the verb 'list' or 'retrieve' explicitly, which slightly reduces precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing all sections, but provides no explicit guidance on when to use this versus alternatives like guardian_browse_section or guardian_search. It lacks context about prerequisites, such as whether authentication is required or if this is a foundational step for other operations. The usage is inferred from the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search specifically for articles from The Long Read series
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search terms within Long Read articles | |
| from_date | No | Start date (YYYY-MM-DD format) | |
| to_date | No | End date (YYYY-MM-DD format) | |
| page_size | No | Results per page, max 200 (default: 10) | |
| page | No | Page number (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches for articles but doesn't describe key behaviors like pagination handling (implied by 'page' and 'page_size' parameters), rate limits, authentication needs, or what the search results include (e.g., article metadata). For a search tool with 5 parameters and no annotations, this leaves significant gaps in understanding how it operates.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Search specifically for articles from The Long Read series'), earning its place with zero waste. This is appropriately sized for the tool's complexity.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., search scope, result format), usage context compared to siblings, and output expectations. For a search tool with moderate complexity and no structured support, the description should provide more guidance to compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all 5 parameters (e.g., 'query' for search terms, date formats, pagination defaults). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'query' interacts with the Long Read series or date range constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
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: 'Search specifically for articles from The Long Read series.' It specifies the verb 'search' and the resource 'articles from The Long Read series,' making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'guardian_recommend_longreads' or 'guardian_search,' which could provide similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over sibling tools such as 'guardian_search' (general search) or 'guardian_recommend_longreads' (recommendations), nor does it specify any prerequisites or exclusions. Usage is implied but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find top stories from a specific date or date range
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Specific date (YYYY-MM-DD) or start of range | |
| end_date | No | End date for range (YYYY-MM-DD) | |
| section | No | Filter by section | |
| page_size | No | Number of results (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: what 'top stories' means (ranking criteria, source), whether results are paginated beyond page_size, rate limits, authentication requirements, or what the output format looks like. The description is minimal and lacks operational 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?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with clear parameters documented in the schema, though it could benefit from additional context about usage 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 tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'top stories' means, how results are ranked/selected, what the output format is, or when to use this versus similar tools like guardian_top_stories_by_date. The description provides basic purpose but lacks the context needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema - it mentions date/date range filtering which aligns with the date and end_date parameters, but provides no extra context about format, constraints, or usage patterns.
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 ('Find') and resource ('top stories'), specifying the scope as 'from a specific date or date range'. It distinguishes from some siblings like guardian_get_article (single article) or guardian_search (general search), but doesn't explicitly differentiate from guardian_top_stories_by_date which appears similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like guardian_top_stories_by_date (which appears to serve a similar function) or guardian_search (which might also find stories by date). No context about prerequisites, limitations, or typical use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get personalized Long Read recommendations based on context and preferences
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of recommendations (default: 3, max: 10) | |
| context | No | Context about interests, current conversation, or what you're looking for | |
| from_date | No | Earliest publication date to consider (default: 3 months ago) | |
| topic_preference | No | Specific topic or theme preference (e.g., "climate change", "technology", "culture") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'personalized' recommendations but doesn't explain how personalization works (e.g., based on user history, real-time context), what the output format is, or any limitations like rate limits or data freshness. This leaves significant gaps for an AI agent to understand the tool's behavior.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does ('Get personalized Long Read recommendations') and the basis for it ('based on context and preferences'), making it easy 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 complexity of a personalized recommendation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., how recommendations are generated, output format), usage context relative to siblings, or practical examples. This makes it inadequate for an AI agent to fully leverage the tool's capabilities.
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 100% description coverage, providing clear details for all 4 parameters (e.g., defaults, constraints). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'context' and 'topic_preference' interact or examples of effective usage. With high schema coverage, the baseline score 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's purpose: 'Get personalized Long Read recommendations based on context and preferences.' It specifies the action ('Get'), resource ('Long Read recommendations'), and personalization criteria. However, it doesn't explicitly differentiate from siblings like 'guardian_longread' or 'guardian_search_by_length', which might offer similar content discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'guardian_longread' (likely fetches a specific longread), 'guardian_search' (general search), and 'guardian_search_by_length' (length-based search), there's no indication of when this personalized recommendation tool is preferred over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Guardian articles with flexible filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search terms (can be empty to browse all content) | |
| section | No | Filter by section ID (get available sections via guardian_get_sections) | |
| tag | No | Filter by tag (over 50,000 available tags) | |
| from_date | No | Start date (YYYY-MM-DD format) | |
| to_date | No | End date (YYYY-MM-DD format) | |
| order_by | No | Sort order: 'newest', 'oldest', 'relevance' (default: 'relevance') | |
| page_size | No | Results per page, max 200 (default: 20) | |
| page | No | Page number (default: 1) | |
| show_fields | No | Comma-separated fields to include (headline,standfirst,body,byline,thumbnail,publication) | |
| production_office | No | Filter by office: 'uk', 'us', 'au' | |
| detail_level | No | Response detail level: 'minimal' (fast), 'standard' (default), 'full' (complete) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Search' implies a read operation, the description doesn't address important behavioral aspects like rate limits, authentication requirements, response format, pagination behavior (beyond what's in the schema), or whether this is a real-time search versus cached results. For a complex 11-parameter search tool, this is insufficient 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?
The description is a single, efficient sentence that immediately communicates the core function. There's no wasted verbiage or unnecessary elaboration. It's appropriately sized for a search tool and front-loads the essential information.
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 complexity (11 parameters, no annotations, no output schema, and 15 sibling tools), the description is inadequate. It doesn't help the agent understand what this search returns (no output schema), how it differs from specialized sibling searches, or important behavioral constraints. For a tool in this rich ecosystem, the description should provide more contextual guidance about when and how to use it effectively.
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 description coverage is 100%, so all parameters are well-documented in the schema itself. The description adds minimal value beyond what's already in the schema - it mentions 'flexible filtering options' which aligns with the many filter parameters, but doesn't provide additional semantic context about how these filters interact or which combinations are most useful. This meets the baseline expectation when schema coverage is complete.
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 ('Search') and resource ('Guardian articles'), making the purpose immediately understandable. It also mentions 'flexible filtering options' which hints at capabilities. However, it doesn't specifically differentiate this tool from its many siblings (like guardian_search_by_author or guardian_search_by_length), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling search tools available. With 15 sibling tools including multiple specialized search variants (by author, by length, tags, etc.), the agent receives no help in selecting the appropriate search tool for different scenarios. The mention of 'flexible filtering options' is too vague to serve as meaningful usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Guardian articles by specific author/journalist
| Name | Required | Description | Default |
|---|---|---|---|
| author | Yes | Author name to search for | |
| query | No | Additional search terms within author's articles | |
| section | No | Filter by section ID | |
| from_date | No | Start date (YYYY-MM-DD format) | |
| to_date | No | End date (YYYY-MM-DD format) | |
| order_by | No | Sort order: 'newest', 'oldest', 'relevance' (default: 'newest') | |
| page_size | No | Results per page, max 200 (default: 20) | |
| page | No | Page number (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool searches articles by author but doesn't disclose behavioral traits like pagination behavior (implied by 'page' and 'page_size' parameters), rate limits, authentication needs, error conditions, or what the response looks like (no output schema). This is inadequate for a search tool with 8 parameters.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a search tool. 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?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, pagination, error handling, or how it differs from sibling search tools. For a parameter-rich search operation, more context is needed to guide the agent effectively.
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%, so the schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify author name format or how 'query' interacts with 'author'). Baseline 3 is appropriate when schema does the heavy lifting.
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: 'Search Guardian articles by specific author/journalist' - a specific verb ('search') and resource ('Guardian articles') with a clear filter ('by specific author/journalist'). However, it doesn't explicitly distinguish this from sibling tools like 'guardian_search' or 'guardian_search_by_length', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'guardian_search' (general search) or 'guardian_author_profile' (author metadata), nor does it specify prerequisites or exclusions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Guardian articles filtered by word count range
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search terms (optional) | |
| min_words | No | Minimum word count (default: 0) | |
| max_words | No | Maximum word count (default: unlimited) | |
| section | No | Filter by section ID | |
| from_date | No | Start date (YYYY-MM-DD format) | |
| to_date | No | End date (YYYY-MM-DD format) | |
| order_by | No | Sort order: 'newest', 'oldest', 'relevance' (default: 'newest') | |
| page_size | No | Results per page, max 200 (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'search' implies a read-only operation, the description doesn't address important behavioral aspects like authentication requirements, rate limits, pagination behavior (beyond the 'page_size' parameter), error conditions, or what the response format looks like (no output schema exists).
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 a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a search tool and front-loads the essential information (search + word count filtering).
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 moderate complexity (8 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It identifies the core filtering dimension (word count) but doesn't provide context about how this integrates with other search capabilities, what constitutes a 'Guardian article' in this context, or typical use cases for word count filtering.
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%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'word count range' which corresponds to 'min_words' and 'max_words' parameters, but provides no extra context about how these interact with other parameters like 'query' or 'section'.
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: 'Search Guardian articles filtered by word count range.' It specifies the action (search), resource (Guardian articles), and key filtering dimension (word count range). However, it doesn't explicitly differentiate from sibling tools like 'guardian_search' or 'guardian_longread' which might also involve searching or filtering by length.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 14 sibling tools including 'guardian_search' (general search) and 'guardian_longread' (likely for longer articles), there's no indication of when word count filtering is preferred over other search methods or when this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through Guardian's 50,000+ tags to find relevant ones
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term for tag names | |
| page_size | No | Results per page, max 200 (default: 20) | |
| page | No | Page number (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the scale ('50,000+ tags') but fails to describe key behaviors like pagination handling, rate limits, authentication needs, or what the search results include (e.g., tag names, IDs, metadata). This leaves significant gaps in understanding how the tool operates.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could be slightly more informative by including key behavioral details without sacrificing brevity.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on return values (e.g., structure of tag results), error handling, or performance considerations, making it inadequate for an agent to fully understand the tool's context and usage.
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%, so the input schema fully documents the three parameters (query, page_size, page) with descriptions and constraints. The description adds no additional parameter semantics beyond what the schema provides, such as search syntax or result format details, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search through') and resource ('Guardian's 50,000+ tags'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'guardian_search' or 'guardian_get_article_tags', which could involve tag-related operations, leaving room for ambiguity in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'guardian_search' or 'guardian_get_article_tags'. It lacks context about use cases, exclusions, or comparisons with sibling tools, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare trends of multiple topics over time with correlation analysis
| Name | Required | Description | Default |
|---|---|---|---|
| topics | Yes | List of topics/keywords to compare (max 5) | |
| from_date | Yes | Start date (YYYY-MM-DD) | |
| to_date | Yes | End date (YYYY-MM-DD) | |
| interval | No | Time interval for comparison |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'correlation analysis' which hints at statistical behavior, but doesn't describe what the output looks like, whether it requires authentication, rate limits, or data sources. For a tool with 4 parameters and no output schema, this is inadequate 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?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized and front-loaded with the main purpose, 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's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'trends' or 'correlation analysis' means in practice, what data source is used, or what format the results will be in. For a comparative analysis tool, this leaves significant gaps in understanding.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (like explaining what 'correlation analysis' means in terms of parameters). Baseline 3 is appropriate when the schema does the heavy lifting.
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 with specific verbs ('compare trends', 'correlation analysis') and resources ('multiple topics over time'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'guardian_content_timeline' or 'guardian_lookback' which might also involve time-based analysis, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools like 'guardian_search' or 'guardian_content_timeline' that might handle similar data. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get intelligently ranked top stories for a specific date using editorial prioritization
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date to analyze (YYYY-MM-DD) | |
| story_count | No | Number of top stories to return (default: 10, max: 20) | |
| section | No | Filter by section (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'intelligently ranked' and 'editorial prioritization,' hinting at ranking behavior, but lacks details on what this entails (e.g., criteria, source of prioritization). It doesn't disclose rate limits, authentication needs, error handling, or output format (no output schema exists), which are critical for a read operation with ranking logic.
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 a single, efficient sentence that front-loads the core purpose. Every word earns its place: 'Get' (action), 'intelligently ranked top stories' (resource and behavior), 'for a specific date' (key constraint), 'using editorial prioritization' (method). No redundancy or fluff, making it highly scannable and informative.
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 3 parameters with full schema coverage and no output schema, the description is minimally adequate. It clarifies the tool's focus on date-based, ranked stories but lacks details on ranking mechanics, output structure, or sibling differentiation. For a read-only tool with editorial logic, more behavioral context would improve completeness, though the concise purpose statement meets basic needs.
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%, so the schema fully documents parameters (date, story_count, section). The description adds no parameter-specific semantics beyond implying date relevance and ranking. It doesn't explain optional vs. required parameters or interactions between them, relying entirely on the schema. Baseline 3 is appropriate as the schema handles parameter documentation.
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: 'Get intelligently ranked top stories for a specific date using editorial prioritization.' It specifies the action ('Get'), resource ('top stories'), and key constraints ('for a specific date', 'intelligently ranked', 'editorial prioritization'). However, it doesn't explicitly differentiate from siblings like guardian_search or guardian_content_timeline, which might also retrieve stories by date.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like guardian_search (which might search stories by date) or guardian_content_timeline (which might provide chronological content). There's no indication of prerequisites, exclusions, or comparative advantages, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between search-related tools (e.g., guardian_search, guardian_search_by_author, guardian_search_by_length) that could cause minor confusion, though their descriptions help differentiate them. Tools like guardian_get_article and guardian_get_article_tags are clearly separate, and others like guardian_content_timeline and guardian_topic_trends serve unique analytical functions.
All tool names follow a consistent snake_case pattern with a 'guardian_' prefix, using clear verb_noun combinations (e.g., guardian_browse_section, guardian_search_tags). This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style or structure.
With 16 tools, the count is slightly high but reasonable for a server focused on Guardian content access and analysis, covering browsing, searching, and trend analysis. It might feel a bit heavy, but each tool appears to serve a specific function without obvious redundancy, fitting the domain's scope.
The tool set provides comprehensive coverage for interacting with Guardian content, including retrieval (get_article), browsing (browse_section, get_sections), searching (search, search_by_author, search_by_length), analysis (content_timeline, topic_trends), and specialized features (longread, recommend_longreads). There are no apparent gaps for the stated purpose, enabling agents to perform a wide range of tasks without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Guardian Open Platform: content search, articles, sections, tags. Free dev key.
GOV.UK Content + Search APIs (every gov.uk page + full search)
Real-time news search across 500,000+ sources in 60+ languages with sentiment and entities.
Search 18M+ legal documents worldwide — case law, legislation, and doctrine across 110+ countries.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbenton/guardian-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
