The vr-org-mcp server provides read-only access to VR.org's VR/AR/XR content with no API keys or configuration required. Here's what you can do:
Search & browse news – Retrieve the latest headlines from VR.org's aggregated feed, filtered by category (hardware, gaming, software, enterprise, AR, XR) or keyword
Get trending topics – Discover what's currently trending across the VR/AR/XR feed
List & read original articles – Browse VR.org's editorial content (reporting, opinion, guides) and fetch full article content by slug
Browse upcoming events – Get upcoming VR/AR/XR industry conferences, expos, and launches sorted by date
Find VR deals – Access curated product picks (headsets, accessories, AR glasses) with prices and retailer links, filterable by section
Compare headsets – Side-by-side comparison of two VR headsets by name (partial names accepted), including price, badges, and descriptions
View rankings – Get VR.org's current ranked lists of top VR games and top VR apps/utilities
List news sources – See all sources VR.org aggregates with per-source article counts
Explain VR topics – Get canonical short answers and pillar-page links for common VR/AR/XR questions (e.g. "what is VR", "best headset", "VR for beginners")
Use MCP resources – Attach latest news, original articles, events, or guides as context
Use prompts – Get headset recommendations by budget/use case, draft a weekly VR roundup, or explain a VR topic grounded in VR.org's canonical answers
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., "@vr-org-mcp what are the latest VR deals?"
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.
Read-only Model Context Protocol server for VR.org, a dedicated VR / AR / XR news publication and aggregator.
It gives any MCP-compatible agent (Claude Desktop, Claude Code, Cursor, Continue, and others) one-call access to live VR, AR, and XR news, VR.org's original editorial (including full article text), the VR/AR/XR events calendar, curated headset deals, buyer-guide answers, and top-game and top-app lists.
Eleven tools, five resources, and three prompts. Zero keys. Zero writes. Zero payments.
Run it directly with npx (no global install needed):
npx vr-org-mcpOne-click: download vr-org-mcp-0.3.2.mcpb and double-click it to install into Claude Desktop. Or configure manually:
Add to your claude_desktop_config.json:
{
"mcpServers": {
"vr-org": {
"command": "npx",
"args": ["-y", "vr-org-mcp"]
}
}
}claude mcp add vr-org -- npx -y vr-org-mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"vr-org": {
"command": "npx",
"args": ["-y", "vr-org-mcp"]
}
}
}VR.org also runs the same tools as a remote server over MCP's streamable-HTTP transport, so web clients (ChatGPT connectors, Claude.ai connectors) can use it with no local install:
https://vr.org/mcpHuman setup walkthrough for every client: vr.org/connect.
Related MCP server: korean-news-mcp
Tool | What it returns |
| Latest VR / AR / XR headlines from the live feed, with optional category filter and keyword match |
| Topics currently trending across the feed |
| Summaries of VR.org's own editorial articles, newest first |
| Full content of one original by slug: metadata, canonical URL, and the article body HTML |
| Upcoming VR / AR / XR industry events (conferences, expos, launches), soonest first |
| Curated product picks with prices, badges, and retailer links |
| Side-by-side of two headsets (partial names accepted) |
| Current ranked top VR games list |
| Current ranked top VR apps and utilities list |
| The news sources VR.org aggregates, with counts |
| Canonical short answer plus pillar-page link for a common question |
Browsable MCP resources an app can attach as context:
Resource | Contents |
| Latest aggregated VR / AR / XR headlines |
| Index of VR.org's newest original articles |
| Upcoming VR / AR / XR industry events |
| VR.org's canonical pillar-guide answers in one doc |
| Full HTML body of any original article (resource template) |
Prompt | What it does |
| Recommends a headset from VR.org's picks given a budget and use case |
| Drafts a weekly VR / AR / XR roundup from the feed and originals |
| Explains a VR topic grounded in VR.org's canonical answer |
Every tool composes VR.org's public JSON API (https://vr.org/api/*) into a single agent-friendly response. The server is a thin proxy: it holds no secrets, writes nothing, and cannot move money.
VR.org's editorial is controlled, but the live feed also carries third-party RSS headlines. To keep a malicious or compromised upstream headline from manipulating the calling model, every tool output is:
Sanitized. Control characters and zero-width / direction-override characters are stripped from every string.
Capped. Serialized responses are limited to 50 KB so a large payload cannot flood the agent's context window.
Inputs are validated before any outbound request and every free-text parameter is length-capped at the schema layer. Errors are returned as structured, non-echoing objects rather than raw stack traces; on the rare path where an error string reaches the caller it runs through the same output scrub as a tool result, with any credential-shaped substring redacted and the text capped, and is flagged with isError.
The API base URL is fixed to https://vr.org in source and cannot be overridden, so the server can only ever talk to VR.org.
Env var | Default | Purpose |
| (none) | Optional suffix appended to the outbound User-Agent |
npm install
npm run dev # run from source over stdio
npm run build # compile to dist/
npm test # run the offline test suite
npm run typecheck # type-check without emittingContent provenance. Feed results now carry a provenance field on every item, either vr_org_editorial (written and edited by VR.org) or third_party_feed (a headline or snippet relayed verbatim from an outside publisher). Any response containing relayed text also carries a content_notice saying to treat that text as data rather than instructions, and the vrorg://news/latest resource carries the same notice in prose. This is additive metadata, so existing fields and existing consumers are unaffected.
The point is to let a calling client tell which text VR.org actually stands behind. It follows the August 2026 GhostSplice research on splitting instructions across MCP channels, whose core mitigation is that clients should treat server output as data. This server is not a vector for that attack (it never requests sampling, its tool descriptions are static literals, and every value that can flow back in as a tool argument is validated against a strict allowlist), but it does relay text it did not write, and now it says so.
Also bumps @modelcontextprotocol/sdk to 1.30.0 and pins four transitive dependencies of the SDK's HTTP transport that carried advisories. This server is stdio-only and never loads that transport, so the pins are hygiene rather than an exposure fix. npm audit --omit=dev reports zero vulnerabilities.
Error-path hardening: tool errors now pass through the same output scrub as tool results, with secrets redacted and error text capped. All free-text parameters gain schema-level max lengths. No behavior change for valid inputs.
MIT. A VR.org project.
Returns a side-by-side of two headsets (price, badge, description, retailer links) drawn from VR.org's curated catalog. Accepts partial names like 'Quest 3' or 'PSVR2'.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First headset name (partial match allowed). | |
| b | Yes | Second headset name (partial match allowed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds value by specifying the data source (VR.org's curated catalog) and partial name matching behavior, which are not covered by 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 with no wasted words. The first sentence summarizes the purpose and output, and the second adds a key usage detail (partial name acceptance). Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only comparison tool with no output schema, the description adequately covers what is returned (price, badge, description, retailer links) and how to use the parameters. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions that already state partial match allowed. The description reinforces this but does not add new meaning beyond what the schema provides. The examples given are helpful but not essential.
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 a side-by-side comparison of two headsets with specific fields (price, badge, description, retailer links). This verb+resource combination is unique among siblings, none of which perform comparisons.
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 to use it for comparing two headsets, accepts partial names, and provides examples like 'Quest 3' and 'PSVR2'. While it doesn't specify when not to use it or name alternatives, the context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns VR.org's current ranked list of the top VR apps and utilities.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. Description adds context about the result being a ranked list and current, which is useful behavioral info 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?
Single sentence with no wasted words. Front-loaded with purpose. Ideal conciseness.
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 no parameters and no output schema, description sufficiently explains what is returned (ranked list of top VR apps and utilities). Could mention sorting or update frequency but fine as is.
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?
No parameters exist and schema coverage is 100%, so description does not need to add parameter details. Baseline 4 applies per rubric for 0-parameter tools.
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 uses verb 'returns' with specific resource 'VR.org's current ranked list of the top VR apps and utilities'. It clearly distinguishes from sibling 'get_top_vr_games' by specifying apps/utilities instead of games.
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?
Description implies usage when top VR apps list is needed, but provides no explicit guidance on when to use vs alternatives or exclusions. Lacks when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns VR.org's current ranked list of the top VR games.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it returns a 'ranked list' and 'current', but annotations already convey read-only and non-destructive behavior. Minimal additional value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, description is adequate. Could elaborate on list format or entry details, but not essential for agent 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?
No parameters, so no need to explain parameter semantics. Schema coverage is trivially 100%. Baseline 4 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?
Clearly states the verb 'returns', resource 'ranked list of the top VR games', and source 'VR.org'. Distinguishes from siblings like get_top_vr_apps by specifying games.
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?
No explicit when-to-use or alternatives. However, the name and sibling tools make usage clear. OpenWorldHint suggests broad applicability, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full content of a single VR.org original article by its slug: metadata (title, author, date, category, tags, snippet), the canonical URL, and the article body HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The article slug, e.g. 'why-vr-is-the-perfect-horror-machine'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing exactly what data is returned (metadata, URL, body HTML). It does not contradict annotations and provides useful additional 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, focused sentence that front-loads the purpose and efficiently lists return values. No extraneous 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 low complexity (one required parameter, read-only, no nested objects, no output schema), the description fully covers what the tool does and what it returns. No 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?
Schema description coverage is 100% for the single 'slug' parameter. The description reinforces its purpose with an example but does not add new semantic meaning beyond the schema's existing description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns full content of a VR.org original article by slug, listing included metadata (title, author, date, category, tags, snippet, canonical URL, body HTML). This clearly distinguishes it from sibling tools like list_vr_originals, which only list articles.
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 via slug but provides no guidance on when to use this tool versus alternatives like search_vr_news or list_vr_originals. No explicit when-not-to-use or prerequisite context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns VR.org's current curated product picks (headsets, accessories, AR glasses) with prices, badges, and retailer links. Optionally filter to one section.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional section filter, e.g. 'headsets'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is known. Description adds context about returned data (prices, badges, links) but lacks details on data freshness, authentication, or error behavior. Adds some value beyond annotations but not extensive.
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 succinct sentences with no redundancy. Front-loaded with key information and zero filler.
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 low complexity (one optional param, no output schema), the description adequately covers what the tool returns and the optional filter. Minor gap: no mention of return format or number of items, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description reinforces the optional filter but adds no new semantic meaning beyond what the schema already provides. 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?
Description uses specific verb 'Returns' with clear resource 'VR.org's current curated product picks' and lists categories (headsets, accessories, AR glasses). It distinguishes from sibling tools like 'compare_vr_headsets' and 'get_top_vr_apps' by focusing on deals/prices.
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?
Description mentions optional filtering but provides no explicit guidance on when to use vs. alternatives like 'compare_vr_headsets'. Usage is implied through context but lacks when-not or exclusionary advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns upcoming VR, AR, and XR industry events (conferences, expos, launches) from VR.org's events calendar, soonest first. Set include_past to also include events that have already ended.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 10). | |
| include_past | No | Include events that have already ended (default false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that events are from VR.org's events calendar and sorted soonest first. No contradictions, and it adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states the main purpose, the second gives a usage hint for the include_past parameter. No wasted words, well-structured.
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 no output schema, the description provides the source (VR.org), ordering (soonest first), and parameter hint (include_past). For a simple two-parameter list tool, this is fairly complete, though could mention return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (limit, include_past) are documented in the schema. The description only mentions include_past explicitly, not adding significant meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns upcoming VR/AR/XR industry events from VR.org's calendar, sorted soonest first, with examples (conferences, expos, launches). This is specific and distinct from sibling tools like compare_vr_headsets or get_top_vr_apps.
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 clear context: events are 'upcoming' and 'soonest first', and explicitly mentions the include_past parameter for including past events. It does not explicitly state when not to use it, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the topics currently trending across VR.org's aggregated VR / AR / XR feed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint, so the description adds context by specifying the source as 'aggregated VR/AR/XR feed', which is beyond the annotations. No behavioral traits are hidden.
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 sentence that is clear and concise, with no unnecessary words.
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 no parameters and no output schema, the description adequately explains what it returns. It could mention return format or update frequency, but current completeness is sufficient.
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 no parameters, and schema description coverage is 100%. According to scoring rules, baseline is 4 for zero parameters. The description does not need to add parameter details.
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 it 'returns the topics currently trending across VR.org's aggregated VR / AR / XR feed', which is a specific verb and resource. It differentiates from sibling tools like get_top_vr_apps and get_top_vr_games by focusing on general trending topics rather than specific categories.
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 for getting trending topics, but does not explicitly state when to use this tool vs alternatives or when not to use it. Given the sibling list, the context suggests it is for broad trends, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns summaries of VR.org's own editorial articles (original reporting, opinion, retrospectives, and guides), newest first. Optionally filter by category.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 15). | |
| category | No | Optional category filter: hardware, gaming, software, enterprise, ar, or xr. Omit for all categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral context (newest first ordering, optional filtering) but does not disclose additional traits beyond the schema and 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 concise sentences, front-loaded with the main action, no wasted words. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with 2 optional params and good annotations, the description covers what is returned (summaries), ordering, and optional filtering. No output schema needed. Complete for its complexity.
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 both parameters well-described. The description adds 'Optionally filter by category' which mirrors the schema. With full schema coverage, a score of 3 is appropriate as description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Returns', resource 'summaries of VR.org's own editorial articles', and specifies types of original content (reporting, opinion, etc.). It distinguishes from siblings like 'get_vr_article' (full article) and 'search_vr_news' (general news). Also mentions ordering (newest first) and optional category filter.
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?
Description indicates optional category filter and ordering. While it doesn't explicitly state when not to use this tool versus alternatives, the context of sibling tool names (e.g., 'search_vr_news', 'get_vr_article') provides clear differentiation. The description is adequate for guiding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the news sources VR.org aggregates, with per-source article counts and status, plus aggregate totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the agent knows it's a safe read operation. The description adds value by specifying the return structure (per-source counts, status, totals), which is not in 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 a single, concise sentence that effectively communicates the tool's output. No unnecessary words or details.
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?
Despite lacking an output schema, the description fully explains the return value: per-source article counts and status plus aggregate totals. This is sufficient for a simple list tool with no parameters.
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 zero parameters with 100% description coverage. Per the calibration rule, 0 params baseline is 4. The description does not need to explain parameters as there are none.
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 it returns news sources with per-source article counts, status, and aggregate totals. It uses specific verbs and resources and is distinct from sibling tools like compare_vr_headsets or get_top_vr_apps.
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 lacks explicit guidance on when to use this tool versus alternatives. While siblings are different, there is no 'when to use' or 'when not to use' context. The usage is implied by being the only source-listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the latest VR, AR, and XR headlines from VR.org's live aggregated feed (8 VR-native sources plus filtered general tech). Optionally filter by category and match a keyword in the title or snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-50 (default 20). | |
| query | No | Optional keyword to match in the title or snippet. | |
| category | No | Optional category filter: hardware, gaming, software, enterprise, ar, or xr. Omit for all categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds context about the feed source and optional filters but does not disclose additional behavioral traits like rate limits, pagination, or ordering beyond 'latest'.
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 only two sentences, front-loaded with main purpose, no wasted words. Each sentence provides 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?
Despite lacking an output schema, the description explains it returns 'headlines' from a live feed, implying snippets and titles. It mentions the feed source and optional filters, making it fairly complete for a search tool. Missing explicit ordering info, but 'latest' implies chronological.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no new meaning beyond the schema, just restates the optional filters. 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 it returns VR/AR/XR headlines from a specific source (VR.org's live aggregated feed) with optional filters. It distinguishes itself from siblings like get_vr_article (likely full article) and get_vr_trending (maybe trending) by being a broad search/list tool.
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?
No explicit guidance on when to use this tool vs alternatives like get_vr_trending or list_vr_sources. The description does not mention when not to use it or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a canonical VR.org answer and the authoritative pillar-page link for a common VR / AR / XR question (for example 'what is vr', 'best headset', 'ar glasses', 'vr for beginners').
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The topic or question, e.g. 'what is vr' or 'best vr headset'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns a canonical answer and link, consistent with annotations. No additional behavioral traits beyond what annotations provide, so baseline 3.
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?
Single sentence with no wasted words. Efficiently communicates the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficient. It explains the tool's purpose and what it returns. However, it could clarify the format of the answer (e.g., text vs. structured data).
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 covers 100% of parameters. The description adds meaningful examples ('what is vr', 'best headset') that clarify acceptable inputs, providing extra context beyond 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 returns a canonical VR.org answer and authoritative link for common VR/AR/XR questions, with specific examples. It distinguishes itself from sibling tools which are more specialized (e.g., compare_vr_headsets, get_top_vr_apps).
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 example questions implying usage, but does not explicitly state when to use this tool versus siblings or when not to use it. With 11 sibling tools, more guidance is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of VR.org content: headsets, apps, games, articles, deals, events, trending, originals, sources, news, and explainers. No two tools have overlapping purposes.
Most tool names follow a verb_noun pattern (e.g., get_vr_article, list_vr_sources). However, vr_explain reverses the order, breaking the otherwise consistent prefix convention.
With 11 tools, the set is well-scoped for a VR/AR/XR content API. Each tool serves a clear and necessary function, and the count is neither too sparse nor overwhelming.
The tool set provides thorough read-only coverage of VR.org's content: headset comparison, top lists, articles, deals, events, trending topics, editorial content, sources, news search, and FAQ. No obvious gaps for the intended domain.
Dive into the latest and greatest from the tech world with our Hacker News MCP server.
Read-only MCP server for RZ AI Labs — query its services, workshops, and contact info.
Read-only MCP server for live Polymarket, Kalshi, Limitless odds; Manifold sentiment.
Read-only MCP server for Flamel.ai's public content: company overview, blog, case studies, FAQs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/evanatpizzarobot/vr-org-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
