worldlabs-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct function: world generation from various sources, retrieval, deletion, spatial broadcasting, avatar spawning, and media upload. The descriptions clearly differentiate tools even where they overlap in purpose (e.g., different generation inputs).
Naming Consistency4/5
Most tools follow snake_case with verb_noun patterns (e.g., generate_world_from_image, delete_world). Minor inconsistencies include 'list_worlds' vs 'get_world' (plural vs singular) and 'worldlabs_help' which breaks the pattern. Overall, the naming is predictable and clear.
Tool Count4/5
Twenty tools cover the domain of 3D world generation, management, and interaction without feeling bloated. While slightly above the ideal range, each tool serves a distinct purpose and contributes to a complete workflow.
Completeness4/5
The tool set provides comprehensive coverage for world generation (multiple input types), CRUD operations (create, read, list, delete), spatial interactions, and media upload. Minor gaps like an update tool are absent but likely unnecessary given the immutability of generated worlds.
Average 3.7/5 across 19 of 20 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 53 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the basic action without describing whether the TV is persistent, if it can be moved, or any side effects. The agent is left guessing about runtime behavior.
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, concise and front-loaded. No wasted words.
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?
Despite 6 parameters and no schema descriptions, the description is too sparse. An output schema exists but is not described. The tool's function is complex enough to warrant more details about placement, orientation, and results.
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?
Schema coverage is 0%, so the description must compensate. It only mentions the video_url implicitly; none of the positional parameters (x, y, z, rotation_y, scale) are explained. The defaults in the schema are unhelpful without context.
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 clearly states the tool's purpose: placing a virtual TV screen playing a Veo 3.1 video. It uses specific verbs and resources, and distinguishes from siblings, as no other tool mentions placing a TV.
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?
No guidance on when to use this tool versus alternatives. There are no prerequisites, context, or exclusionary conditions mentioned. The agent has no help deciding between this and other tools like spawn_agent_avatar or broadcast_spatial_audio.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior. It mentions that the viewer will 'attempt to ground the avatar on the collider mesh,' but does not disclose other important behaviors such as whether the operation is destructive, requires permissions, or affects the scene state beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded, but it omits necessary parameter details. It is concise but at the expense of completeness.
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?
Despite having an output schema (not shown), the description lacks details about return values, parameter constraints, and the grounding behavior. With five parameters and zero schema descriptions, it is insufficient for reliable invocation.
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 should compensate. It does not explain any of the five parameters beyond their names and defaults, leaving their purpose and constraints ambiguous.
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 the specific verb 'materialize' and clearly identifies the resource as an 'animated agent avatar' in the 3D scene, which distinguishes it from sibling tools like broadcast_spatial_audio or generate_world_from_text.
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?
No guidance on when to use this tool versus alternatives is provided. There is no mention of prerequisites, context, or exclusions, leaving the agent without clear direction on selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only mentions async return via operation_id but lacks details on lifecycle, failure modes, rate limits, or constraints like video size/duration.
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?
Two sentences, very concise and front-loaded with purpose. No wasted words.
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?
Output schema exists but description fails to connect operation_id to sibling get_operation for polling. Missing details on completion, error handling, or video requirements.
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?
Schema description coverage is 100%, so baseline 3 applies. Description adds no extra meaning beyond schema; merely restates parameter roles.
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?
Description clearly states 'Generate a 3D world from a public video URL' – specific verb (generate) and resource (3D world) with source identified. Distinguishes from siblings like generate_world_from_image and generate_world_from_text.
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?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned. Only states 'Returns immediately with an operation_id' without explaining polling or completion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose any behavioral traits like ordering, default sort, or that it returns a paginated list. The minimal description leaves agents uninformed about important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. While efficient, it could include a bit more context (e.g., pagination hint) without becoming overly verbose.
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 the presence of an output schema (which likely documents return fields), the description's brevity is partially excusable. However, there are no annotations and no explanation of pagination or the absence of filtering options, leaving some gaps.
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?
The input schema already provides clear descriptions for both parameters (page_size and page_token). The description adds no extra semantic context beyond what the schema offers, but with 100% schema coverage, a score of 3 is baseline.
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 'List previously generated worlds' uses a specific verb ('List') and a distinct resource ('previously generated worlds'), clearly distinguishing it from sibling tools like get_world (single world) or generation tools.
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?
No guidance is provided on when to use this tool versus alternatives such as get_world or the various generation tools. The context would significantly benefit from an explicit usage suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions connecting to the Spatial Voice Agent but does not describe any side effects, permission requirements, or state dependencies (e.g., whether the viewer must be active). This lack of detail hinders safe invocation.
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 extremely concise: two sentences that front-load the action and quickly explain the mechanism. Every word contributes value, making it easy for an agent to parse.
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 and the input schema covers all parameters, the description is minimally adequate. However, it lacks any mention of prerequisites (e.g., active viewer) or behavior when conditions are not met, leaving potential gaps for an agent relying solely on this description.
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?
All parameters are already well-documented in the input schema (100% coverage). The description adds little beyond 'spatial' and '3D world' context, which is already implied by the schema's coordinate parameters. Thus, baseline 3 is appropriate.
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 clearly states the tool's purpose: broadcasting a spatial voice notification to the active World Labs Spark Viewer, narrating specific locations. It uses specific verbs and resource, and implies differentiation from sibling 'broadcast_spatial_audio' by focusing on voice notification and text-to-speech via Gemini TTS.
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 provides no explicit guidance on when to use this tool versus alternatives like 'broadcast_spatial_audio'. It implies usage for narrating locations but does not specify when not to use it or mention any prerequisites such as having an active viewer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it generates a world, omitting any details about side effects, permissions, rate limits, or the nature of the operation (e.g., synchronous/asynchronous).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundancy. However, it is slightly too minimal and could incorporate more context without becoming verbose.
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 complexity (6 parameters, many siblings, output schema exists), the description omits important contextual information like the prerequisite upload tools and the workflow. It does hint at 'previously uploaded' but is insufficient for a complete understanding.
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?
Schema description coverage is 100%, and the description adds no extra meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate a world') and the resource ('from a previously uploaded media asset'), distinguishing it from sibling tools that generate from raw inputs like text or direct image/video.
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?
It implies the prerequisite of a prior upload, but does not explicitly state when to use this tool versus alternatives like generate_world_from_image or upload_and_generate. No explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly notes that the tool returns immediately with an operation_id, implying asynchronous processing. However, it lacks details about error handling, rate limits, or any destructive effects (none expected). Without annotations, more behavioral context would be beneficial.
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 exceptionally concise with two sentences. The first sentence states the core purpose, and the second adds a critical behavioral detail (synchronous return of operation_id). No superfluous words.
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?
Given the existence of an output schema (context), the description need not detail return values, but it does mention the operation_id. It covers the essential aspects for a generation tool, though additional info on error states or polling could improve completeness.
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?
Schema coverage is 100% and each parameter has a clear description in the schema. The tool description adds no extra insight beyond the schema, meeting the baseline for well-documented parameters.
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 tool generates a 3D world from a public image URL. It distinguishes from siblings like generate_world_from_text and generate_world_from_video, but does not explicitly differentiate from generate_world_from_media_asset, which likely handles uploaded media vs public URLs.
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?
No guidance on when to use this tool versus its siblings, especially generate_world_from_media_asset for uploaded files. No scenarios or prerequisites are mentioned, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only states what the tool does but omits implications: generation time, constraints on image consistency, world properties, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with key purpose. No unnecessary words, but could benefit from a brief additional sentence on constraints.
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?
With full schema coverage and an output schema, the description is minimally sufficient. However, it does not mention the matching length requirement between image_urls and azimuths_deg, nor other prerequisites.
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?
Schema description coverage is 100%, with all parameters documented. The description adds no new parameter meaning beyond repeating azimuth angles. Baseline 3 is appropriate.
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?
Description clearly states the tool generates a 3D world from multiple images with azimuth angles. Verb 'generate' and resource '3D world' are specific, and it distinguishes from siblings like generate_world_from_image or generate_world_from_video.
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?
Description implies usage when multiple images with azimuths are available but lacks explicit when-not or alternatives. No guidance on prerequisites or comparison to other generation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It says 'latest details', indicating a read operation, but does not confirm read-only behavior, permissions, or rate limits. It is adequate but not comprehensive.
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?
Single sentence, no redundant words, clear and front-loaded.
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 simple fetch operation with one parameter and an output schema existing, the description is complete enough. It covers the purpose and required identifier, though it could mention behavior on invalid ID.
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?
Schema coverage is 100% with a single parameter world_id described as 'The world UUID...' The description adds 'by its ID' which aligns but does not add significant meaning beyond the schema.
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 'Fetch' and the resource 'world details by its ID', distinguishing it from list_worlds which returns multiple worlds. However, it does not explicitly differentiate from other read tools like get_operation.
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 implies that you need a world ID, but it does not provide explicit guidance on when to use this tool versus alternatives like list_worlds or get_operation. No when-not or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that audio is spatialized via WebAudio PannerNode and accepts mp3/wav formats. However, it omits behavioral details such as whether audio replaces existing sounds, limits on concurrent playback, volume control, error handling, or response behavior.
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 two sentences long: the first states the purpose, the second details usage and technical context. There is no extraneous information; every sentence contributes meaningful guidance.
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 5 parameters and an existing output schema, the description covers the core usage (URL and coordinates) but lacks information on prerequisites, error scenarios, or what the tool returns beyond the schema. It is adequate but not fully complete.
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?
Schema coverage is 0%, so the description must compensate. It adds meaning for 'prompt_or_url' (URL to audio file, supported formats) and implies x,y,z specify 3D coordinates. It does not describe 'is_loop' or defaults. The additions are helpful but not comprehensive for all parameters.
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 tool broadcasts spatial audio (music/ambience) to the scene, specifying the verb 'broadcast' and the resource 'spatial audio'. It distinguishes from the sibling 'broadcast_spatial_notification' by focusing on audio playback and spatialization. However, it does not explicitly contrast with the notification tool, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is used to play audio files at 3D coordinates via a URL, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like 'broadcast_spatial_notification'. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It discloses the async pattern and polling timeout (≤90s) but omits credit costs, permissions, or failure handling. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and immediately address usage pattern. Efficient, but could be slightly more structured (e.g., bullet points for status options).
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?
For a tool with 5 parameters and an output schema, the description adequately covers the async workflow. However, it misses details like credit implications (mentioned only in model param description) and rate limits, leaving gaps for an agent.
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?
Schema coverage is 100%, so parameters are already documented. The description adds no extra semantics beyond the schema, sticking to post-call instructions. Baseline score of 3 is appropriate.
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 clearly states the tool generates a 3D world from a text description, which is distinct from sibling tools like generate_world_from_image. The verb 'Generate' and resource '3D world' are specific.
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 mentions the asynchronous nature and directs to get_operation or wait_for_world for status. However, it does not explicitly differentiate when to use this tool over other generation methods (e.g., from image or video).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the core behavior (sending to Ollama for expansion) but omits details like requirements (Ollama must be running), error handling, or whether the operation is idempotent. The description adds context about Marble-optimization but lacks deeper 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?
Two sentences with no waste: first states the purpose, second elaborates on the action and output. Front-loaded and efficient.
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 an output schema, so return values are covered. The description is sufficient for a simple refinement tool, but it could note prerequisites (e.g., Ollama running locally). Given sibling tools, its role is clear.
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?
Schema coverage is 100%, so the description need not add param info; baseline is 3. The description does not provide additional meaning beyond the schema—'short prompt' is already in the prompt parameter description.
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 clearly states the verb ('Refine'), the resource ('a world prompt'), and the method ('using a local Ollama model'). It also specifies the output is a 'Marble-optimised 3D world generation prompt', distinguishing it from sibling tools that generate worlds directly.
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 usage for refining a prompt before world generation, but it does not explicitly state when to use this tool versus alternatives (e.g., generate_world_from_text). No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions returning immediately with operation_id and the async flow, but lacks details on authentication, rate limits, file handling, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at three sentences, with the first stating purpose and the second enumerating sub-steps. Front-loaded but the enumeration adds slight verbosity. Still efficient overall.
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 6 parameters, no annotations, and an output schema, the description covers the basic flow but lacks details on error handling, supported file formats, or alternatives. Output schema helps, but more contextual guidance would improve completeness.
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?
Schema description coverage is 100%, so baseline 3. The description does not add significant meaning beyond the schema; it only reiterates the 'local file' concept already in the schema. No extra semantics.
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 clearly states the tool's purpose: upload a local file and generate a 3D world end-to-end. It distinguishes from sibling tools like generate_world_from_image by emphasizing the full upload flow.
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 implies use when you have a local file to upload and generate, but does not explicitly exclude alternatives like generate_world_from_media_asset for already uploaded files. Context is clear, but no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions three detail levels, providing some behavioral insight. However, with no annotations provided, it does not disclose traits such as read-only nature, permission requirements, or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences with no fluff. It front-loads the primary purpose and details effectively.
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?
Given the presence of an output schema, the description adequately covers the tool's purpose and parameters. It mentions what the tool returns (documentation, models, workflow, context), which is sufficient for a help tool of moderate complexity.
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?
Schema description coverage is 100%, so the schema already explains the parameters well. The description adds minimal extra meaning beyond mentioning 'three detail levels', which is already in the schema. Baseline 3 is appropriate.
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 clearly states that the tool returns structured documentation about every tool in the server, Marble API models, typical workflow, and World Labs context. It distinguishes itself from siblings which are operational tools (e.g., generate_world_from_image) by being a help/reference tool.
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 usage for retrieving documentation but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses the exact return format for all operations, explains the search matching logic (all tokens must match, case-insensitive), mentions pagination via next_page_token, and notes the 'polite bound' on upstream requests through max_pages. It does not discuss error scenarios or auth requirements, but for a read-only gallery exploration tool this coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (RATIONALE, Return Format, Examples). It is longer than strictly necessary – the RATIONALE could be trimmed – but it front-loads the core purpose and provides concrete operation examples that aid understanding. The structure makes it easy for an agent to parse the essential information without excessive verbosity.
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?
Given the tool's complexity (7 parameters, 4 operations), the description is thorough: it defines each operation, provides a precise return format template, and gives example calls for every operation. It explains pagination and search semantics. Even though an output schema exists, the description still covers the return structure in text, ensuring an agent knows what to expect without needing to infer from code. Nothing critical is missing for correct invocation.
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?
Schema coverage is 100% – every parameter has a detailed description in the input schema. The tool description adds illustrative example calls and hints at operation-specific usage, but does not introduce new semantic meaning beyond the schema. The examples are helpful for context but do not compensate for missing parameter details; the schema already does that work. A score of 3 is baseline for high schema coverage.
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 clearly states the tool 'explores the public Marble community gallery' and enumerates four distinct operations (browse, world, prompts, search). It includes specific resource and scope (community gallery at marble.worldlabs.ai) and distinguishes itself from siblings like generate_world_* and show_world_card by focusing on gallery exploration rather than generation or display.
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 usage through the operation-specific examples and the rationale that consolidates multiple gallery tasks into one tool. However, it does not explicitly state when to use this tool instead of siblings like list_worlds, get_world, show_worlds_card, or show_world_card. No alternative tools are mentioned, and there is no 'when not to use' guidance, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Indicates it's a read operation ('Lists worlds from your Marble account') and mentions output elements (badges, labels, dates, links). But lacks detail on auth, rate limits, or any side effects. Adequate but not rich.
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?
Two concise sentences, front-loaded with core purpose. Every word earns its place, no fluff.
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?
With no output schema, description helpfully lists card elements (badges, labels, dates, links). Does not cover pagination behavior or error handling, but for a simple list tool this is reasonably complete.
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?
Schema coverage is 100% with both parameters documented. Description does not add additional semantic information beyond what the schema provides. Baseline score of 3 applies.
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?
Clearly states verb ('Display'), resource ('generated worlds'), and output format ('rich scannable card with thumbnail previews'). Explicitly distinguishes from sibling list_worlds by contrasting card vs raw JSON rendering.
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?
Directly compares to list_worlds, telling the agent this is the visual alternative. Provides clear context for when to use this tool (when a card format is preferred), though no explicit 'when not to use' is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description takes full burden and clearly discloses permanent deletion of the world and all associated assets, with explicit 'cannot be undone' warning.
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?
Extremely concise with two sentences, front-loaded action, and zero wasted words.
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 one-parameter destructive tool with output schema, the description covers everything needed: what it deletes, permanent effect, and irreversibility.
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?
Schema already covers parameter meaning (world UUID) at 100% coverage. Description adds no extra semantics beyond the schema.
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?
Clearly states the tool deletes a world by ID and lists what assets are removed. Distinct from sibling tools like generate_world_from_image and get_world.
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?
Mentions that the action is permanent and cannot be undone, implying caution, but does not explicitly state when to use it vs alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the output content comprehensively (thumbnail, caption, assets, links), implying a read-only operation with no side effects. This is sufficient for a read tool.
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 concise, using bullet-like clarity in two sentences. Every sentence provides valuable information without redundancy or wordiness.
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?
Given the tool's simple function and single parameter, the description fully explains what the card includes, making it complete for an agent to understand and use the tool.
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?
The sole parameter world_id has a schema description that is already clear, and the tool description does not add any additional meaning. With 100% schema coverage, this meets the baseline but adds no extra value.
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 clearly states the tool displays a single world as a rich detail card with assets and viewer link, and distinguishes it from get_world by noting it's rendered as a Prefab card. This makes the purpose unambiguous relative to siblings.
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 a clear usage context by comparing to get_world and specifying the card format. However, it lacks explicit guidance on when not to use it or alternatives beyond that comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description covers polling behavior and the condition to stop (done=True). It doesn't detail error handling or rate limits, but the core polling semantics are clear.
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?
Two sentences with no unnecessary words. Front-loaded with main purpose and key usage advice.
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?
Given the simple tool (1 param, output schema exists), the description fully covers when to use, how to use, and what to expect. It is complete for an agent to invoke correctly.
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?
Schema coverage is 100% for the single parameter 'operation_id', described in schema. The description does not add extra meaning beyond the schema, so baseline 3 applies.
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 clearly states the tool polls a generation operation for status. It specifies it's for long-running jobs and distinguishes from the sibling 'wait_for_world'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends when to use (long-running jobs like marble-1.1-plus) and provides an alternative (use polling instead of wait_for_world).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses blocking/polling behavior, timeout limits, and client constraints. Does not mention error handling or side effects, but covers main behavioral traits well.
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?
Two sentences plus a warning block. Front-loaded with main purpose. Every sentence adds value, no fluff.
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?
Output schema exists, so return values need not be explained. Description covers usage, alternatives, and constraints. Complete for a blocking poll tool with good annotations (none) and schema.
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?
Schema coverage is 100%, baseline 3. Description only reiterates parameter defaults (timeout 90, poll 15) already documented in schema. No additional meaning beyond schema.
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?
Clear verb+resource: 'Block-poll an operation until it completes, fails, or times out.' Differentiates from sibling get_operation which is likely non-blocking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about default timeout (90s) and when to avoid (marble-1.1-plus jobs), recommending get_operation or increasing timeout. Gives clear when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses behavior: generates signed URL, requires subsequent PUT, and passes media_asset.id to another tool. No hidden 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences only: purpose, follow-up steps, alternative. No repetition, all text earns its place.
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?
Output schema exists, so return values are covered. Description mentions key outputs (upload_info, media_asset.id) and provides complete workflow for a preparation tool.
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?
Schema covers all parameters with descriptions (100% coverage). Description adds no additional parameter meaning beyond schema.
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?
States specific verb 'Prepare' and resource 'signed GCS upload URL for a local file', clearly distinguishing from sibling 'upload_and_generate' by mentioning simpler flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (preparatory step) and when not to (simpler flow via upload_and_generate), plus provides step-by-step instructions for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![worldlabs-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/worldlabs-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandraschi/worldlabs-mcp)

Score Badge

Copy to your README.md:

[![worldlabs-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/worldlabs-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/worldlabs-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandraschi/worldlabs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server