globalize.now

Create project

create_project

Create a localisation project from catalog languages. Resolve language ids first with list_languages. The source language is what your content is authored in; target languages are what it will be translated into. When referring to a project or language in your reply to the user, use its name and locale (e.g. "French (fr-FR)") — ids (UUIDs) are for tool calls only, never show them to the user.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Human-readable project name
`sourceLanguage`	Yes	Catalog language id of the source language
`targetLanguages`	Yes	Catalog language ids of the target languages (at least one)

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`name`	Yes
`slug`	Yes
`orgId`	Yes
`context`	No	Project-wide translation context; null when unset
`repository`	No	The connected repository, null when the project has none
`sourceLanguage`	Yes
`targetLanguages`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 29, 2026

changedOutput schema / properties / repository / anyOf

Previous value: -[
-  {
-    "additionalProperties": {},
-    "properties": {
-      "detectedFramework": {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "gitUrl": {
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "provider": {
-        "type": "string"
-      },
-      "repoPatterns": {
-        "items": {
-          "additionalProperties": {},
-          "properties": {
-            "fileFormat": {
-              "type": "string"
-            },
-            "id": {
-              "type": "string"
-            },
-            "pattern": {
-              "type": "string"
-            },
-            "position": {
-              "type": "number"
-            }
-          },
-          "required": [
-            "id",
-            "pattern",
-            "fileFormat",
-            "position"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    },
-    "required": [
-      "id",
-      "gitUrl",
-      "provider",
-      "repoPatterns"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {
+      "branches": {
+        "description": "Watched branches, in order. The first entry is the primary branch.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "detectedFramework": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "gitUrl": {
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "provider": {
+        "type": "string"
+      },
+      "repoPatterns": {
+        "items": {
+          "additionalProperties": {},
+          "properties": {
+            "fileFormat": {
+              "type": "string"
+            },
+            "id": {
+              "type": "string"
+            },
+            "pattern": {
+              "type": "string"
+            },
+            "position": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "id",
+            "pattern",
+            "fileFormat",
+            "position"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "id",
+      "gitUrl",
+      "provider",
+      "branches",
+      "repoPatterns"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the write/creation safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real behavioral value beyond them: an output-presentation policy (show name and locale, never expose UUIDs) and the language-role semantics. It does not cover failure modes for invalid or duplicate language ids.

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?

Purpose is front-loaded in the first clause, followed by prerequisite, parameter semantics, and the user-facing naming rule. Every sentence carries information, though the final display-formatting sentence is slightly tangential to the invocation task itself.

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?

An output schema exists so return values need no explanation, schema coverage is full, and annotations carry the safety profile. The description covers prerequisite, language semantics, and display policy; only edge-case behavior (invalid ids, duplicates) is left unstated, which is a minor gap for a 3-parameter creation tool.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description goes further by explaining the meaning of sourceLanguage versus targetLanguages ('what your content is authored in' vs 'what it will be translated into'), which is semantic context the schema does not carry. It does not clarify whether ordering or duplicates in targetLanguages matter.

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 a specific verb and resource ('Create a localisation project from catalog languages') and goes on to define the source/target language roles, which an agent cannot infer from the name alone. It is clearly differentiated from siblings like add_project_language, get_project, and list_projects.

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?

Gives an explicit prerequisite and names the sibling that satisfies it ('Resolve language ids first with list_languages'), which is genuinely actionable routing. It stops short of stating when not to use this tool or contrasting it with add_project_language for existing projects.

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

All globalize.now tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.