globalize.now

List glossary entries

list_glossary

Read-only

List the glossary entries for a project — each a source→target term pair with its languages and id. Optionally filter by source and/or target project_language id. Results are paginated; pass the returned cursor to fetch the next page. A project's glossary may be shared by other projects and Workflows in the organisation: a change to it applies to every one of them, and only the terms of the languages of the addressed project are listed or changed. The result's glossary.sharedWith names the others — tell the user which ones a change affects. While glossary.repositoryManaged is set, the glossary is synced from that project's asset repository and every write is refused. 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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>"
    },
    "name": "list_glossary"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size (default 50)
`cursor`	No	Pagination cursor from a previous call
`project`	Yes	Project id (UUID) or slug
`sourceProjectLanguageId`	No	Filter to entries whose source is this project_language id
`targetProjectLanguageId`	No	Filter to entries whose target is this project_language id

Output Schema

Name	Required	Description
`data`	Yes
`glossary`	Yes	The project's attached glossary and what else uses it
`pagination`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

addedOutput schema / properties / glossary

Added value: +{
+  "additionalProperties": {},
+  "description": "The project's attached glossary and what else uses it",
+  "properties": {
+    "id": {
+      "type": "string"
+    },
+    "name": {
+      "type": "string"
+    },
+    "repositoryManaged": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "properties": {
+            "branch": {
+              "type": "string"
+            },
+            "gitUrl": {
+              "type": "string"
+            },
+            "projectId": {
+              "type": "string"
+            },
+            "repositoryId": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "projectId",
+            "repositoryId",
+            "gitUrl",
+            "branch"
+          ],
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The project whose asset repository the glossary is synced from (writes are refused), or null"
+    },
+    "sharedWith": {
+      "additionalProperties": {},
+      "properties": {
+        "projects": {
+          "description": "Other projects attached to the glossary",
+          "items": {
+            "additionalProperties": {},
+            "properties": {
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "name"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "workflows": {
+          "description": "Active Workflows using the glossary",
+          "items": {
+            "additionalProperties": {},
+            "properties": {
+              "id": {
+                "type": "string"
+              },
+              "name": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "id",
+              "name"
+            ],
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "projects",
+        "workflows"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "id",
+    "name",
+    "sharedWith",
+    "repositoryManaged"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "data",
-  "pagination"
-]New value: +[
+  "data",
+  "pagination",
+  "glossary"
+]

First observedSep 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With readOnlyHint/destructiveHint already declaring the safety profile, the description adds real context beyond annotations: pagination mechanics, that a shared glossary's changes affect other projects and Workflows, and that repositoryManaged glossaries refuse writes. It does not cover rate limits or empty-result behavior, but the added sharing semantics are substantive.

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?

Front-loads purpose and return shape, then layers filtering, pagination, and sharing caveats in order of likely need. It runs long and the repositoryManaged write-refusal sentence is only indirectly relevant to a list operation, but nearly every sentence carries actionable content.

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

Completeness4/5

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

An output schema exists, so return values needn't be explained, and the description still covers filtering, pagination, and the shared/repository-managed edge cases plus the id-vs-locale display convention. An agent has enough to call and interpret it 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%, so all five parameters including cursor, limit, and the language-id filters are already documented in the schema. The description's filtering sentence largely restates the schema, so the 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?

States a specific verb (List) and resource (glossary entries for a project) and immediately characterizes the returned shape — a source→target term pair with languages and id. An agent can distinguish this read tool from add_glossary_entries and delete_glossary_entry without opening any schema.

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?

Explains that source/target filtering is optional and covers pagination flow (pass the returned cursor for the next page). It does not explicitly name an alternative sibling or state when-not-to-use, but the read-vs-write distinction is clear from the opening sentence.

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.