Live read-only discovery for public s&box packages, servers, and player activity.
Scored across 8 tools
Each tool targets a distinct entity or action: get_* tools retrieve details for a specific organization, package, server, activity history, or ecosystem snapshot; search_* tools find organizations, packages, or servers. The only potential overlap between aggregate tools (get_activity_history and get_ecosystem_snapshot) is clearly resolved by descriptions emphasizing history versus current totals.
All tool names follow a strict snake_case verb_noun pattern: get_<entity> for detail retrieval and search_<entity> for discovery. The only exception is get_ecosystem_snapshot, but it still fits the get_<noun> convention and is consistent with the rest.
Eight tools are well-scoped for a read-only monitoring service covering packages, organizations, servers, activity, and ecosystem totals. Each tool earns its place with no obvious redundancy.
The domain is s&box ecosystem monitoring and discovery. The surface provides search and detail retrieval for all major entities (packages, organizations, servers), plus activity history and an ecosystem snapshot, leaving no obvious gaps for read-only workflows.
Read bounded player history for public games, dedicated servers, or one game. Older aggregate points marked partialCoverage total recorded games and may omit unrecorded games.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | ||
| kind | No | game | |
| range | No | 24h | |
| maxPoints | No |
| 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 | |
| partialCoverage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavioral context that annotations cannot: that history is 'bounded' and that older aggregate points marked partialCoverage total recorded games and may omit unrecorded games, which tells the agent how to interpret incomplete results.
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 tight sentences with no filler, and the core action plus scope is front-loaded ahead of the partialCoverage caveat. Efficient, though the second sentence is dense enough that it could be split for readability.
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?
An output schema exists, so return values need not be explained, and the partialCoverage caveat is helpful. However, with four parameters at 0% schema description coverage, the description leaves range options, maxPoints limits, and the game identifier syntax undocumented, which is not quite sufficient for a tool this parameterized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for four parameters. It loosely explains the 'kind' dimension ('public games, dedicated servers, or one game') and the bounded nature of results, but never mentions the 'range' enum values, the maxPoints bound, or the game identifier format, leaving real gaps.
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?
States a specific verb and resource ('Read bounded player history') and names the scope (public games, dedicated servers, or one game). This is clear, but it does not explicitly distinguish itself from siblings like get_server or get_ecosystem_snapshot, so the agent must infer the boundary.
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 phrase 'for public games, dedicated servers, or one game' implies the situations this tool covers and loosely maps to the 'kind' parameter, but there is no explicit when-to-use versus alternatives and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read current package, player, and dedicated-server totals from s&box watch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| packages | Yes | |
| generation | Yes | |
| playersNow | Yes | |
| generatedAt | Yes | |
| canonicalUrl | Yes | |
| serversOnline | Yes | |
| serverPlayersOnline | Yes |
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.
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.
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.
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.
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.
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.
Read one organization profile with public metadata, aggregate activity, and a bounded package portfolio.
| Name | Required | Description | Default |
|---|---|---|---|
| ident | Yes |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a read-only, idempotent, non-destructive, non-open-world operation, so the safety profile is covered. The description adds minor value by noting the metadata is 'public' and the portfolio is 'bounded', hinting at result-size limits, but discloses nothing about auth needs, rate limits, or what happens with unknown idents.
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?
A single front-loaded sentence that communicates verb, resource, and payload contents with no filler. Nothing could be cut without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with a full annotation set and an output schema (so return values need no prose), the description is nearly sufficient. The only meaningful gap is that the 'ident' argument's expected format and sourcing are never addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter 'ident' carries only a regex pattern with no prose. The description does not explain that 'ident' is an organization slug/handle or how to obtain it, so it fails to compensate for the documentation gap.
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?
States a specific verb and resource ('Read one organization profile') and enumerates the payload shape (public metadata, aggregate activity, bounded package portfolio). It is clearly distinguishable from siblings like search_organizations by the 'one organization' framing, though it never names that alternative explicitly.
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 singular 'one organization' implies a direct-lookup use case versus the sibling search_organizations, but there is no explicit when-to-use/when-not-to-use statement and no mention of prerequisites such as needing a known identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read compact details, official game-jam membership, recent publisher updates, and live-server links for one public s&box package.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | game | |
| ident | Yes |
| 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 | |
| weeklyPlaytimeSeconds | No | |
| weeklyPlaytimeBaselineAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description earns credit for what it adds: the exact content bundle returned and the restriction to public packages. It stops short of noting error behavior for unknown or private idents or any auth expectations.
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?
A single front-loaded sentence with no filler; the subject (one public s&box package) and content scope are established immediately, and every clause carries 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?
An output schema exists, so return values need not be described, and annotations cover the safety profile. What remains thin is guidance on the ident/kind parameters and when to prefer this over the search siblings, but for a simple single-entity read the definition is largely 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 description coverage is 0% for two parameters, so the description must compensate and does not: neither the ident format (namespace.name pattern) nor the kind enum (game/library/map) semantics are mentioned. 'One public package' gives no usable meaning for either parameter beyond what the schema already implies.
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 states a specific verb (Read) and resource (public s&box package) and enumerates the payload sections returned (compact details, game-jam membership, publisher updates, live-server links). It implies a single-item lookup as opposed to the search_* siblings, but never names or contrasts them explicitly.
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?
Usage is only implied: 'one public s&box package' signals a single-package retrieval, but the description never says when to choose this over search_packages or get_server, and gives no prerequisites or exclusions. A reader can infer intent but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current state and related servers for one s&box dedicated-server ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| 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 |
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.
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.
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.
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.
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.
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.
Find studios, teams, and creators publishing public s&box games, maps, or libraries.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | players | |
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| sort | Yes | |
| query | Yes | |
| total | Yes | |
| results | Yes | |
| generation | Yes | |
| generatedAt | Yes | |
| contentNotice | Yes |
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.
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.
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.
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.
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.
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.
Find public s&box games, maps, or libraries with live rankings, seven-day and cumulative game playtime, official game-jam membership, and canonical source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| jam | No | Restrict games to an official s&box game jam. | |
| kind | No | game | |
| sort | No | ||
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| kind | Yes | |
| sort | Yes | |
| query | Yes | |
| total | Yes | |
| results | Yes | |
| generation | Yes | |
| generatedAt | Yes | |
| contentNotice | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful context about the data that comes back, but says nothing about pagination, ordering defaults, or result caps beyond what the schema shows.
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?
A single well-formed sentence, front-loaded with the action verb and resource. It is efficiently sized, though words are spent on enumerating return fields rather than on selection guidance.
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?
An output schema exists, so the description need not have enumerated rankings and playtime metrics; that budget would have been better spent on the four filter parameters it never explains. For a five-parameter search at 20% schema coverage, the definition leaves the agent guessing about how to actually shape a query.
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 only 20% across five parameters, and the description does not compensate: it never mentions query, kind, sort, limit, or jam semantics. Opaque enum values like 'change24h', 'score', and 'servers' are left unexplained in both places.
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?
States a specific verb ('Find') plus a concrete, scoped resource ('public s&box games, maps, or libraries'), which an agent can distinguish from the singular get_package sibling. It also names the domain-specific content returned (rankings, playtime, jam membership), so the tool's role in the ecosystem is unambiguous.
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 never says when to use this tool versus get_package, search_servers, or search_organizations; it only restates what the search finds. There are no exclusions, prerequisites, or disambiguation cues, leaving selection entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find dedicated s&box servers by name, game, or map with current occupancy and source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| map | No | ||
| game | No | ||
| sort | No | players | |
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| sort | Yes | |
| query | Yes | |
| total | Yes | |
| results | Yes | |
| generation | Yes | |
| generatedAt | Yes | |
| contentNotice | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_organization2 fields changedOutput schema / properties / portfolios / items / properties / packages / items / properties / weeklyPlaytimeBaselineAtAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / portfolios / items / properties / packages / items / properties / weeklyPlaytimeSecondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}get_package2 fields changedOutput schema / properties / weeklyPlaytimeBaselineAtAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / weeklyPlaytimeSecondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}search_packages3 fields changedInput schema / properties / sort / enumPrevious value: -[
- "players",
- "playtime",
- "change24h",
- "created",
- "updated",
- "favorites",
- "upvotes",
- "score",
- "servers"
-]New value: +[
+ "players",
+ "playtime7d",
+ "playtime",
+ "change24h",
+ "created",
+ "updated",
+ "favorites",
+ "upvotes",
+ "score",
+ "servers"
+]Output schema / properties / results / items / properties / weeklyPlaytimeBaselineAtAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / results / items / properties / weeklyPlaytimeSecondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}get_organization1 field changedOutput schema / properties / portfolios / items / properties / packages / items / properties / totalSecondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}search_packages2 fields changedInput schema / properties / sort / enumPrevious value: -[
- "players",
- "change24h",
- "created",
- "updated",
- "favorites",
- "upvotes",
- "score",
- "servers"
-]New value: +[
+ "players",
+ "playtime",
+ "change24h",
+ "created",
+ "updated",
+ "favorites",
+ "upvotes",
+ "score",
+ "servers"
+]Output schema / properties / results / items / properties / totalSecondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}get_activity_history4 fields changedOutput schema / properties / durationMs / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / durationMs / typeRemoved value: -"number"Output schema / properties / partialCoverageAdded value: +{
+ "items": {
+ "type": "number"
+ },
+ "maxItems": 200,
+ "type": "array"
+}Output schema / properties / points / items / properties / partialCoverageAdded value: +{
+ "type": "boolean"
+}search_organizations1 field changedInput schema / properties / sort / enumPrevious value: -[
- "players",
- "games",
- "packages",
- "newest",
- "name"
-]New value: +[
+ "players",
+ "games",
+ "updated",
+ "name"
+]get_organizationsearch_organizationsget_package2 fields changedOutput schema / properties / jamsAdded 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"
+}Output schema / requiredPrevious 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"
+]search_packages3 fields changedInput schema / properties / jamAdded value: +{
+ "description": "Restrict games to an official s&box game jam.",
+ "enum": [
+ "three"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / jamsAdded 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"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "ident",
- "title",
- "summary",
- "tags",
- "canonicalUrl",
- "markdownUrl"
-]New value: +[
+ "ident",
+ "title",
+ "summary",
+ "tags",
+ "jams",
+ "canonicalUrl",
+ "markdownUrl"
+]get_activity_historyget_ecosystem_snapshotget_packageget_serversearch_packagessearch_serversRead-only ArcadeOps discovery for developer docs, OAuth, OpenAPI and synthetic sandbox.
Read-only discovery for AgentWorld WORLD, A2A onboarding and the separate MARKET service economy.
Public read-only discovery of agent, model, training, task, and verification opportunities.
Read-only discovery of Framekeep capabilities, security boundaries, and public resources.
Add one secure layer between your agents and this server.