s&box watch

Server Details

Live read-only discovery for public s&box packages, servers, and player activity.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-18 13:22
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-09-10 19:42 across 8 tools

Disambiguation5/5

Each tool targets a clearly distinct resource or operation: search tools find entities, get tools retrieve specific entities, while activity and snapshot tools cover time-series and aggregate data. There is no meaningful overlap between the tool purposes.

Naming Consistency5/5

All tools follow a predictable verb_noun pattern: get_ for single-resource reads and search_ for discovery queries. The naming is uniform and makes the tool set easy to navigate.

Tool Count5/5

Eight tools is well-scoped for a read-only watch/analytics service covering packages, organizations, servers, activity, and ecosystem totals. Each tool earns its place without redundancy or bloat.

Completeness5/5

For a read-only monitoring service, the tool surface is complete: all major resource types are searchable and retrievable, with activity and aggregate snapshot coverage. No obvious dead ends or missing core operations are apparent.

Available Tools

8 tools

get_activity_historyGet s&box player activity historyB

Read-onlyIdempotent

Inspect

Read bounded player history for all public games, all dedicated servers, or one game.

ParametersJSON Schema

Name	Required	Default
`game`	No
`kind`	No	game
`range`	No	24h
`maxPoints`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`game`	No
`kind`	Yes
`range`	Yes
`apiUrl`	Yes
`points`	Yes
`summary`	Yes
`version`	Yes
`bucketed`	Yes
`available`	Yes
`durationMs`	Yes
`generation`	Yes
`canonicalUrl`	Yes

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the 'bounded' qualifier and the three scope modes, which are useful behavioral context beyond the annotations. However, it does not disclose other behaviors like rate limits, pagination, or whether results are aggregated, so it adds only minor extra transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the verb first and the scope options succinctly. Every word earns its place, with no fluff or redundancy. It is appropriately concise for a read operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters (all optional) and an output schema, the description does not fully prepare an agent to call it correctly. It fails to explain parameter semantics, the meaning of 'bounded', or how to specify each scope (e.g., when to set kind vs game). The presence of an output schema reduces the need to describe return values, but input semantics remain under-explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. The description only hints at scopes without mapping to parameters (game, kind, range, maxPoints). It doesn't explain what 'game', 'kind', 'range', or 'maxPoints' do, nor how the three scopes correspond to parameter combinations. This is a significant gap for a 4-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Read') and resource ('player history') with three explicit scopes (all public games, all dedicated servers, or one game). It is distinct enough from sibling tools (which target packages, servers, and snapshots) to avoid immediate confusion, though it doesn't explicitly call out any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. It implies it is for historical activity but never states conditions like 'use this when you need player history' or 'do not use this for live data.' Without explicit when-to-use or when-not-to-use instructions, an agent cannot easily determine if this is the right tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_ecosystem_snapshotGet s&box ecosystem snapshotA

Read-onlyIdempotent

Inspect

Read current package, player, and dedicated-server totals from s&box watch.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`packages`	Yes
`generation`	Yes
`playersNow`	Yes
`generatedAt`	Yes
`canonicalUrl`	Yes
`serversOnline`	Yes
`serverPlayersOnline`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description's 'Read' aligns with the annotations readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and there is no contradiction. It does not add behavioral context beyond what the annotations already provide, such as data freshness, caching, or rate limits, but the annotation coverage already establishes the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. Every word contributes to identifying the action, the data categories, and the source, making it appropriately sized for a zero-parameter read-only tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only snapshot tool with an output schema present and comprehensive annotations, the description is complete. An agent knows exactly what data will be retrieved, and no additional setup, side effects, or prerequisites need to be disclosed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter-specific semantics are unnecessary. The schema description coverage is effectively 100% because there is nothing to document. The description still clarifies what the snapshot contains, which is sufficient for calling the tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read') and identifies the exact resource: current package, player, and dedicated-server totals from s&box watch. This clearly differentiates it from sibling tools like get_package or get_server, which operate on individual entities rather than aggregate ecosystem totals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is implied: an agent should call this when it needs current aggregate counts of packages, players, or dedicated servers. However, there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives, so the agent must infer usage from the resource scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_organizationGet an s&box organizationC

Read-onlyIdempotent

Inspect

Read one organization profile with public metadata, aggregate activity, and a bounded package portfolio.

ParametersJSON Schema

Name	Required	Description	Default
`ident`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`stats`	Yes
`apiUrl`	Yes
`generation`	Yes
`portfolios`	Yes
`generatedAt`	Yes
`markdownUrl`	Yes
`analyticsUrl`	Yes
`canonicalUrl`	Yes
`organization`	Yes
`contentNotice`	Yes
`analyticsApiUrl`	Yes

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description aligns with by saying 'Read'. The description adds content details (public metadata, aggregate activity, bounded portfolio) but does not disclose any additional behavioral aspects like auth requirements, rate limits, or error behavior. With annotations covering safety, this is adequate but not enhanced beyond the baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the primary action ('Read one organization profile') and then lists the data components. There is no fluff or redundancy; every word contributes to understanding the tool's scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (so return values are likely documented) and annotations cover the safety profile, the description provides adequate context for when to call the tool. However, the lack of parameter explanation and the absence of any guidance on selecting this tool over search_organizations leaves gaps in the overall completeness. It is functional but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has only one parameter 'ident' with a pattern but no description. The tool description provides zero explanation of what 'ident' means or how to format it. With schema description coverage at 0%, the description must compensate, but it fails to mention the parameter entirely. This is a critical gap for an agent trying to invoke the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read' and the resource 'organization profile', and specifies the content (public metadata, aggregate activity, bounded package portfolio). It implies a single-object fetch distinct from search tools, but does not explicitly name sibling alternatives like search_organizations, so it lacks the direct contrast that would earn a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus the sibling tools (e.g., when to use get_organization vs search_organizations). It only describes what it does, leaving the selection entirely to inference from the tool name and schema. No exclusions or context about prerequisites are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_packageGet an s&box packageA

Read-onlyIdempotent

Inspect

Read compact details, official game-jam membership, recent publisher updates, and live-server links for one public s&box package.

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No		game
`ident`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`jams`	Yes
`tags`	Yes
`ident`	Yes
`score`	No
`title`	Yes
`created`	No
`creator`	No
`sboxUrl`	No
`summary`	Yes
`updated`	No
`updates`	Yes
`upvotes`	No
`fileSize`	No
`downvotes`	No
`favorites`	No
`generation`	Yes
`playersNow`	No
`supportsVr`	No
`totalUsers`	No
`description`	Yes
`generatedAt`	Yes
`liveServers`	Yes
`markdownUrl`	Yes
`momentum24h`	No
`canonicalUrl`	Yes
`totalSeconds`	No
`updatesTotal`	Yes
`contentNotice`	Yes
`totalSessions`	No
`playersPeak24h`	No
`supportsController`	No

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description doesn't need to restate safety. It adds meaningful behavioral scope: public-only packages, compact details rather than full package data, and live-server links, which go beyond what annotations and schema alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense, front-loaded sentence with no filler or repetition of structured fields. Every phrase adds information about scope or returned content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with two parameters and an output schema, the description covers the main data categories and the public-only restriction. It doesn't explicitly address parameter format or failure cases, but the schema fills most of that gap; a brief usage-routing note would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'ident' or 'kind' parameters. The agent must infer the author.package identifier format and the filtering role of 'kind' entirely from the schema. The description provides only a loose hint that the resource is a package.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Read') and names a precise resource ('one public s&box package'), then lists the exact data categories returned. The 'one public' scope clearly differentiates it from search_packages without needing to open the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for fetching a known, single public package, but it never explicitly says when to prefer it over search_packages or the other sibling tools. Usage context is present but left to inference rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_serverGet an s&box serverA

Read-onlyIdempotent

Inspect

Read the current state and related servers for one s&box dedicated-server ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`map`	No
`game`	No
`name`	Yes
`online`	Yes
`players`	No
`gameTitle`	No
`generation`	Yes
`lastSeenAt`	No
`maxPlayers`	No
`firstSeenAt`	No
`generatedAt`	Yes
`markdownUrl`	Yes
`canonicalUrl`	Yes
`contentNotice`	Yes
`playersPeak24h`	No
`relatedServers`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety traits. The description adds that the tool returns both current state and related servers, but it does not explain what 'related' means or disclose any other behavior, so it adds only modest context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the verb and resource without any filler. Every phrase earns its place: 'current state', 'related servers', and 'one s&box dedicated-server ID' all carry useful meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has low complexity: one required parameter, an output schema, and rich annotations. The description is sufficient for an agent to invoke it correctly. The only minor gap is that 'related servers' is left undefined, though this does not block correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the sole parameter 'id' is meaningfully clarified by the description's 's&box dedicated-server ID' phrasing. The schema already provides the pattern and required status, and with only one self-explanatory parameter, the description sufficiently compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('read') and names the exact resource ('current state and related servers' for one s&box dedicated-server ID). It clearly signals singular lookup by ID, which differentiates it from search_servers and the other sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this when you have a specific server ID and need its current state plus related servers. It does not explicitly name alternatives or exclusions, but the singular-ID framing makes the intended usage obvious relative to the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_organizationsSearch s&box organizationsA

Read-onlyIdempotent

Inspect

Find studios, teams, and creators publishing public s&box games, maps, or libraries.

ParametersJSON Schema

Name	Required	Default
`sort`	No	players
`limit`	No
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`sort`	Yes
`query`	Yes
`total`	Yes
`results`	Yes
`generation`	Yes
`generatedAt`	Yes
`contentNotice`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already cover read-only, non-destructive, and idempotent behavior. The description adds value by disclosing that results are limited to *public* organizations publishing specific content types, which is behavioral scope beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the action, no filler or repetition of schema data. Efficient and immediately scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the general search purpose but omits how result matching works fro query or what the sort enums mean (`players`, `games`). With all parameters optional and an output schema likely present, the agent can still call it, but there is a gap between 'can call' and 'can call confidently with correct parameters'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage for parameters is minimal (only names, types, defaults, max). The description does not clarify what `query` matches (name? description?), what `sort` order values mean (e.g., 'players', 'updated'), or how the default behaves. With 3 parameters and low schema description coverage, the description should compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Find') and names its target resource ('studios, teams, and creators') plus the scope ('publishing public s&box games, maps, or libraries'). An agent knows exactly what this tool returns and what sort of content it covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the intended search use clear, but gives no guidance on when to choose this over related tools (e.g., a direct organization lookup). It does not state exclusions or common search patterns, so it stops at adequate rather than directing usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_packagesSearch s&box packagesA

Read-onlyIdempotent

Inspect

Find public s&box games, maps, or libraries with live rankings, official game-jam membership, and canonical source URLs.

ParametersJSON Schema

Name	Required	Description	Default
`jam`	No	Restrict games to an official s&box game jam.
`kind`	No		game
`sort`	No
`limit`	No
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`kind`	Yes
`sort`	Yes
`query`	Yes
`total`	Yes
`results`	Yes
`generation`	Yes
`generatedAt`	Yes
`contentNotice`	Yes

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds useful behavioral context about the result content (live rankings, game-jam membership, canonical URLs), which goes beyond annotations. It does not disclose pagination or rate limits, but annotations make it a safe read operation, so the added context justifies a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource, with no filler. It efficiently communicates the core purpose and key distinguishing features.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return format is covered. However, the description lacks guidance on when to use the tool vs alternatives and does not clarify the semantics of sort, limit, or query. For a search tool with five parameters, this is a moderate gap, making it minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 20% (only 'jam' has a description). The description hints at 'kind' (games, maps, libraries) and 'jam' (game-jam) but does not explain 'sort', 'limit', or 'query'. With low schema coverage, the description should compensate but only partially does, leaving agents uncertain about key parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Find') and a specific resource ('public s&box games, maps, or libraries'), and highlights distinct features (live rankings, official game-jam membership, canonical source URLs). This clearly differentiates it from sibling tools like search_servers (which searches servers) and get_package (which likely retrieves a specific package).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for searching packages, but it does not explicitly state when to use it versus alternatives like get_package or search_servers. There are no exclusion conditions or scenarios where another tool should be preferred, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_serversSearch live s&box serversA

Read-onlyIdempotent

Inspect

Find dedicated s&box servers by name, game, or map with current occupancy and source URLs.

ParametersJSON Schema

Name	Required	Default
`map`	No
`game`	No
`sort`	No	players
`limit`	No
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`sort`	Yes
`query`	Yes
`total`	Yes
`results`	Yes
`generation`	Yes
`generatedAt`	Yes
`contentNotice`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by labeling the data as live/current occupancy and promising source URLs, which tells the agent what kind of data to expect. No behavior contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One 16-word sentence that front-loads the action and resource before adding search facets and result contents. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only search with an output schema, defaults, enums, and safety annotations already in the structured data, the description covers the essential call intent and key response characteristics. Nothing critical to a first correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must carry parameter meaning; 'by name, game, or map' maps directly to query, game, and map. However, sort and limit are left to their schema names and defaults, with no explanation of sort semantics or bounds, so compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific verb 'Find' and the resource 'dedicated s&box servers,' then names the search facets (name, game, map) and key result data (occupancy, source URLs). This is enough to distinguish the tool from siblings such as get_server (single server) and search_packages (packages).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for broad server discovery by filtering criteria, which separates it from get_server, but it never explicitly states when to choose one sibling over another or lists exclusions. There is no 'when not to use' or alternative-naming guidance, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 10, 2026

Changedsearch_organizations1 field changed

changedInput schema / properties / sort / enum

Previous value: -[
-  "players",
-  "games",
-  "packages",
-  "newest",
-  "name"
-]New value: +[
+  "players",
+  "games",
+  "updated",
+  "name"
+]

2 tool updatesSep 9, 2026
- Addedget_organization
- Addedsearch_organizations

2 tool updatesSep 4, 2026

Changedget_package2 fields changed

addedOutput schema / properties / jams

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "deadline": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "ident": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "ident",
+      "title",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "ident",
-  "title",
-  "summary",
-  "tags",
-  "canonicalUrl",
-  "markdownUrl",
-  "generation",
-  "generatedAt",
-  "contentNotice",
-  "description",
-  "updatesTotal",
-  "updates",
-  "liveServers"
-]New value: +[
+  "ident",
+  "title",
+  "summary",
+  "tags",
+  "jams",
+  "canonicalUrl",
+  "markdownUrl",
+  "generation",
+  "generatedAt",
+  "contentNotice",
+  "description",
+  "updatesTotal",
+  "updates",
+  "liveServers"
+]

Changedsearch_packages3 fields changed

addedInput schema / properties / jam

Added value: +{
+  "description": "Restrict games to an official s&box game jam.",
+  "enum": [
+    "three"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / results / items / properties / jams

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "deadline": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "ident": {
+        "type": "string"
+      },
+      "title": {
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "ident",
+      "title",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / results / items / required

Previous value: -[
-  "ident",
-  "title",
-  "summary",
-  "tags",
-  "canonicalUrl",
-  "markdownUrl"
-]New value: +[
+  "ident",
+  "title",
+  "summary",
+  "tags",
+  "jams",
+  "canonicalUrl",
+  "markdownUrl"
+]

6 tool updatesSep 1, 2026
- First observedget_activity_history
- First observedget_ecosystem_snapshot
- First observedget_package
- First observedget_server
- First observedsearch_packages
- First observedsearch_servers

Related MCP Connectors

ArcadeOps Public Discovery A
io.github.Damso74
Read-only ArcadeOps discovery for developer docs, OAuth, OpenAPI and synthetic sandbox.
API Testing Documentation Access Developer Tools
31
COTRUGLI Agent Recruitment A
tech.cotrugli
Public read-only discovery of agent, model, training, task, and verification opportunities.
AI & Machine Learning Autonomous Agents
51
Framekeep Public Discovery A
com.framekeep
Read-only discovery of Framekeep capabilities, security boundaries, and public resources.
Documentation Access Security Developer Tools
31
Yenta Directory A
ai.yentaknows
Anonymous, read-only cross-venue discovery of partner-approved venues, cities, destinations.
Travel & Transportation Location Services Search
211

Related MCP Servers

nostr-mcp
Social Media Web3 & Decentralized Tech
DiegoYegros
A
license
A
quality
B
maintenance
A read-only MCP server for safely exploring Nostr, enabling agents to resolve identifiers, fetch profiles and events, query notes, and inspect relay metadata. It does not accept private keys or publish events.
Updated a month ago (2026-08-22 06:02 UTC)
5
6 npm
MIT
taskmarket-mcp
Blockchain Web3 & Decentralized Tech Cryptocurrency
eltociear
A
license
Not graded
quality
C
maintenance
MCP server exposing TaskMarket's public, read-only discovery tools so agents can browse and inspect funded onchain tasks on Base without a wallet.
Updated a month ago (2026-08-12 08:05 UTC)
MIT
bruno-mcp
API Testing Developer Tools Documentation Access
TheDMPV
A
license
A
quality
B
maintenance
Read-only MCP server for indexing and searching Bruno API collections. Enables endpoint discovery and contract retrieval without executing requests.
Updated 2 months ago (2026-07-29 20:34 UTC)
8
15 npm
MIT
MCP Registry
Developer Tools
SanjhaiPrakash18
A
license
Not graded
quality
C
maintenance
Provides MCP clients with a searchable registry of MCP servers, enabling discovery and publishing of servers.
Updated 4 days ago (2026-09-14 14:25 UTC)
3 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?