Shared voxel world for AI agents. Extend First Light at the world centre over HTTP or MCP; no auth.
Apply 1 to 512 place/remove ops in one call. Ops run in order; results come back per op.
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states that ops execute in order and that results are returned per op, which implies non-atomic, individually reported operations. It does not, however, explain failure handling or whether partial success is possible, though the per-op result phrasing strongly suggests it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The batch nature is front-loaded, followed by the two most important execution traits: ordering and per-op results. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested array with up to 512 operation objects, no output schema, and no annotations. The description explains the core batch concept but omits critical invocation details such as coordinate expectations, whether op/type/builder have defaults, what the per-op results look like, and how errors are reported. This is not enough for an agent to confidently construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented x, y, z, op, type, and builder fields. It only restates that the tool handles place/remove ops and has a 1–512 item range, which mostly mirrors the schema's minItems/maxItems. It does not explain coordinate semantics, default values for optional fields, or the meaning of builder.
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 action—batch place/remove operations—and the batch size range (1 to 512). It clearly differentiates itself from single-op siblings like place_cube and remove_cube by emphasizing that many ops are applied in one call, so an agent can identify this as the batching 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?
The description implies usage for applying many place/remove operations at once, but it never explicitly says when to choose this over place_cube or remove_cube, nor does it mention when not to use it (e.g., for a single operation). The context is understandable but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove every cube that carries the given builder handle. Bounded per call.
| Name | Required | Description | Default |
|---|---|---|---|
| builder | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the operation is bulk and 'Bounded per call,' but the bound is unspecified. It also does not disclose whether the handle must be your own, whether removal is permanent, or what happens when the per-call bound is reached, which are significant gaps for a destructive tool.
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 short sentences with no filler or redundancy. The core operation and the 'bounded per call' constraint are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter bulk destructive tool with no annotations and no output schema, the description leaves critical operational information unknown: the actual per-call bound, behavior when the bound is exceeded, whether another builder's handle can be passed, and reversibility. It is not complete enough for an agent to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says builder is a required string. The description adds the key meaning that builder is a handle carried by cubes and determines which cubes are removed. However, it does not specify the handle format, how to obtain it, or any ownership constraints, so compensation for the 0% schema coverage is only 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 uses a concrete verb ('Remove'), identifies the resource ('every cube that carries the given builder handle'), and the title clarifies scope ('your own cubes'). The bulk scope distinguishes it from the sibling remove_cube, though it does not explicitly name that alternative.
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 implied: use this when clearing all cubes associated with a builder handle. There is no explicit when-not or alternative guidance, and the sibling remove_cube is not referenced, so an agent must infer when the single-cube operation would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill every cell of a box with one block type. Up to 4096 cells.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes | ||
| type | Yes | ||
| builder | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does add two real constraints not visible in the schema — 'Up to 4096 cells' (a hard scope limit) and 'one block type' (uniformity). However, it never states whether the fill overwrites existing blocks, what happens when the volume exceeds 4096, or whether the operation can destroy prior builds, which are the high-stakes questions for a bulk mutator.
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, action first and constraint second, with zero filler. The second sentence earns its place by disclosing the 4096-cell limit, and both sentences are front-loaded and 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?
This is a high-volume world mutator (up to 4096 cells) with no annotations and no output schema, so the description's burden is heavy. It covers the core operation and the cell cap, but leaves unexplained the builder parameter, overwrite/destructive behavior, limit-exceeded behavior, and how to choose it over the sibling build/place tools. An agent does not have enough information to call this safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints that type is the fill material and from/to define the box extent, both largely derivable from the schema itself. The builder parameter is completely unexplained, and coordinate semantics (inclusive bounds, min/max normalization) are unaddressed, leaving a significant gap given the zero-coverage 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 states a specific action ('Fill every cell of a box') with a concrete resource and the single-block-type constraint, and the title adds the 'axis-aligned' qualifier. This implicitly separates it from singular siblings like place_cube and remove_cube, but it never names a sibling or an explicit differentiator, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance anywhere in the two sentences. An agent choosing between this bulk fill, the singular place_cube, or the general build tool must infer the boundary from the name and description alone. No exclusions or alternative mentions appear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the cube at a coordinate, or null if that cell is empty.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| z | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the null-if-empty behavior, but it does not mention coordinate bounds, out-of-range errors, or explicitly confirm that this is a pure read with no side effects.
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 one compact sentence that states the tool's purpose and its most important conditional behavior. There is no filler or unnecessary repetition of the title.
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 single-cube getter, the description covers the basic read and empty-cell behavior. However, with no output schema and no annotations, it omits the structure of the returned cube and coordinate bounds, leaving some ambiguity for the agent.
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 needed to compensate for x, y, and z. It only says 'at a coordinate,' which confirms they are grid coordinates but does not define ranges, origin, units, or what kinds of values are valid.
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 ('Return'), a specific resource ('the cube at a coordinate'), and a key condition ('null if that cell is empty'). This clearly distinguishes it from sibling read tools like get_region and get_overview, which cover broader areas.
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-coordinate wording implies this tool is for fetching one specific cube, but there is no explicit guidance about when to prefer it over get_region or get_overview, or when not to use it. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The coarse top-surface raster behind the homepage's isometric view, plus a small ASCII preview.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output contents (raster and ASCII preview), giving some transparency. However, there is no mention of side effects, permissions, or error behavior, and the lack of annotations means the description carries the full burden.
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 directly states the tool's output. It contains no unnecessary words or redundant 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?
Given the tool has no parameters and no output schema, the description sufficiently explains what the tool provides. It could be slightly more detailed about the raster format, but the essential information is present.
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 and the schema coverage is 100%, so the baseline score is 4. The description does not need to explain parameters that do not exist.
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 indicates the tool returns a coarse top-surface raster and an ASCII preview, which distinguishes it from other getters like get_cube or get_region. However, it lacks an explicit verb like 'returns' and could be more direct about the resource being retrieved.
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 guidance is provided on when to use this tool instead of alternatives like get_world_stats or get_region. The description does not mention any scenario or context that would lead an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the exact cubes inside an axis-aligned box.
| Name | Required | Description | Default |
|---|---|---|---|
| d | Yes | ||
| h | No | ||
| w | Yes | ||
| x | Yes | ||
| y | No | ||
| z | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List,' which hints at a non-destructive read, but discloses nothing about return format, ordering, coordinate edge cases, or performance.
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 with zero filler, front-loaded with the verb 'List.' Every word earns its place and the sentence communicates the tool's essential function immediately.
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 6 parameters, 0% schema description coverage, no annotations, and no output schema, the one-line description leaves too much unspecified: parameter semantics, required-vs-optional meaning, and return shape. An agent would struggle to construct a correct call without additional external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 6 integer parameters, and the description must compensate. It gives the geometric context of an 'axis-aligned box' but does not explain how x, z, w, d, y, h map to coordinates and dimensions, nor which parameters are optional beyond what the required list 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 ('List') and resource ('cubes') with a clear scope ('inside an axis-aligned box'), so an agent can recognize it as a read-style region query. However, it does not explicitly differentiate itself from the sibling tool 'get_observable', even though the resource and operation make the purpose reasonably distinct.
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?
There is no guidance on when to use this tool versus the sibling 'get_observable' and no mention of exclusions or preconditions. The description only implies a use case (querying cubes in a box) without any decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total cubes, per-block counts, active builders, world bounds, and current limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It gives a useful inventory of the data returned and 'get' implies a read-only operation, but it does not explicitly state that there are no side effects, nor does it describe the response format or any dynamic/cached behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, front-loaded list with no filler. It could have used a verb such as 'Returns' to read as a proper sentence, but it earns its place and avoids redundancy with the title.
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 zero-parameter getter, the description is mostly adequate, but the absence of an output schema means the return structure is not clear. It also does not explain what 'current limits' means or how active builders are counted, leaving minor ambiguity for an agent.
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 and 100% schema coverage, so there is nothing for the description to document. The phrase 'world stats' and the listed data categories are sufficient context for an agent to understand the scope.
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 enumerates the specific contents returned: total cubes, per-block counts, active builders, world bounds, and current limits. The title supplies the verb+object, making the purpose understandable. However, it does not differentiate itself from the similarly named get_overview sibling.
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?
There is no guidance on when to use this tool versus get_overview or the other getter siblings. The description merely lists outputs and leaves selection entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place or replace a single cube. Coordinates are integers in [0,1000); y=0 is ground.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| z | Yes | ||
| type | Yes | ||
| builder | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: placing can also replace an existing cube. It also states the coordinate domain and that y=0 is ground, which is useful. However, with no annotations provided, it does not cover return behavior, error cases, or other side effects.
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 short sentences deliver the essential behavioral and coordinate information with no filler. The action is front-loaded and the constraints are relevant and 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 tool with 5 parameters, no annotations, no output schema, and no parameter documentation, the description is too thin to fully prepare an agent. It explains coordinates and replacement but omits builder semantics, type selection guidance, and expected return or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for x/y/z via '[0,1000)' and 'y=0 is ground', but it says nothing about the type enum or the optional builder parameter. Parameter semantics are only partially explained.
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 and resource ('Place or replace a single cube') and differentiates it from siblings like fill_box or remove_cube by emphasizing the single-cube scope. It is immediately clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'single cube' implies this is for individual placement rather than bulk operations, but there is no explicit guidance on when to choose this over fill_box, build, or remove_cube. The coordinate constraints provide usage context, but alternative routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the cube at a coordinate.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| z | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'clear' and does not reveal what happens when no cube exists at the coordinate, whether the operation is permanent, if it affects neighboring cubes, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or repetition. The action is front-loaded, making it easy to scan, though it may be too sparse for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and three required parameters, the description is incomplete for an agent. Missing context includes failure behavior for absent cubes, coordinate bounds, idempotency, and return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only says 'at a coordinate', which weakly ties x, y, and z together, but it does not explain their meaning, ordering, ranges, or coordinate system beyond what their names imply.
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?
Describes a specific action (clear) on a specific resource (cube) identified by a coordinate, so an agent can tell this removes one cube. It is distinguishable from place_cube and get_cube by the action and singular target, though it does not explicitly differentiate from clear_mine or fill_box.
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 guidance is given on when to use this tool versus siblings like place_cube, fill_box, or clear_mine. There are no exclusions, prerequisites, or alternative conditions described.
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. Dates show when Glama detected each change.
buildclear_minefill_boxget_cubeget_overviewget_regionget_world_statsplace_cuberemove_cubeClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Hosted MCP server for live public-data APIs and Skills for AI agents.
Cloudflare Workers MCP server: ai-agent-scratchpad
Give an AI agent a body in a Zero 3D voxel world: perceive, move, build, chat, remember.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: querying single cubes, regions, overviews, stats, and performing single or bulk modifications. Even though build overlaps with individual place/remove operations, its batch nature differentiates it clearly.
All tools follow a consistent lowercase_with_underscores naming convention. Verbs clearly indicate actions (get, place, remove, clear, fill, build), making the toolset predictable and easy to navigate.
With 9 tools, the set is well-scoped for a cube world manipulation server. It provides both granular operations (place_cube, remove_cube) and higher-level bulk operations (build, fill_box, clear_mine) without unnecessary redundancy.
The toolset covers the full lifecycle of cube manipulation: querying (get_cube, get_region, get_overview, get_world_stats), creating (place_cube, build, fill_box), and deleting (remove_cube, clear_mine). No essential operations for a Minecraft-like environment are missing.
