TokenBel Financial Data

company_get_by_uuid

Read-onlyIdempotent

Get a company catalogue row, including name, UNP, industry and activity flag; includes inactive companies. Find company IDs with search_by_name. Example: {"uuid":"730f9a9e"}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uuid`	Yes	TokenBel id (usually 8 hex chars, no hyphens; not an RFC UUID). From search_by_name entity_type='company'.

Output Schema

TableJSON Schema

Name	Required	Description
`unp`	Yes
`name`	Yes
`uuid`	Yes	TokenBel internal identifier: opaque hexadecimal string, usually 8 characters such as "78c7e502"; despite uuid field names, it is not an RFC UUID and normally has no hyphens.
`address`	Yes
`industry`	Yes
`full_name`	Yes
`is_active`	Yes
`logo_path`	Yes
`created_at`	Yes
`updated_at`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / uuid / description

Previous value: -"TokenBel internal identifier: opaque hexadecimal string, usually 8 characters such as \"78c7e502\"; despite uuid field/tool names, it is not an RFC UUID and normally has no hyphens. Company id, usually from search_by_name entity_type=\"company\"."New value: +"TokenBel id (usually 8 hex chars, no hyphens; not an RFC UUID). From search_by_name entity_type='company'."

Changed10 schema fields changedSep 11, 2026

removedOutput schema / properties / address / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / address / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / full_name / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / full_name / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / industry / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / industry / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / logo_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / logo_path / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / unp / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / unp / type

Added value: +[
+  "string",
+  "null"
+]

Changed2 schema fields changedJun 26, 2026

changedInput schema / properties / uuid / description

Previous value: -"Company UUID (8-36 hex characters), usually from search_by_name entity_type=\"company\""New value: +"TokenBel internal identifier: opaque hexadecimal string, usually 8 characters such as \"78c7e502\"; despite uuid field/tool names, it is not an RFC UUID and normally has no hyphens. Company id, usually from search_by_name entity_type=\"company\"."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "address": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "created_at": {
+      "type": "string"
+    },
+    "full_name": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "industry": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "is_active": {
+      "type": "boolean"
+    },
+    "logo_path": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "name": {
+      "type": "string"
+    },
+    "unp": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "updated_at": {
+      "type": "string"
+    },
+    "uuid": {
+      "description": "TokenBel internal identifier: opaque hexadecimal string, usually 8 characters such as \"78c7e502\"; despite uuid field names, it is not an RFC UUID and normally has no hyphens.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "uuid",
+    "name",
+    "full_name",
+    "unp",
+    "industry",
+    "logo_path",
+    "address",
+    "is_active",
+    "created_at",
+    "updated_at"
+  ],
+  "type": "object"
+}

Changed1 schema field changedJun 25, 2026

changedInput schema / properties / uuid / description

Previous value: -"Company UUID (8-36 hex characters)"New value: +"Company UUID (8-36 hex characters), usually from search_by_name entity_type=\"company\""

First observedJun 9, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint and idempotentHint, covering the safety profile. The description adds useful behavioral context by noting that inactive companies are included and listing the catalogue fields returned, but it does not go deeply beyond that; the output schema covers return-value details.

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 short sentences plus a concrete example; every part earns its place. The main scope is front-loaded, and the workflow pointer to search_by_name follows naturally without unnecessary detail.

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?

With a single required parameter, a fully described schema, a present output schema, and read-only/idempotent annotations, the tool is easy to invoke correctly. The description supplies the only missing context: how to obtain the uuid and that inactive companies are intentionally included.

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 schema already documents uuid as a TokenBel id, its usual format (8 hex chars, no hyphens), and its source from search_by_name. The added example '{"uuid":"730f9a9e"}' reinforces the format but does not add substantially new semantics, so the schema-heavy baseline 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 states a specific verb and resource ('Get a company catalogue row') and enumerates the returned fields (name, UNP, industry, activity flag), plus the key scope detail that inactive companies are included. This clearly distinguishes it from sibling tools like company_list and the other get_by_uuid tools.

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?

It gives a clear usage context by directing the agent to find company IDs via search_by_name, which is the necessary prerequisite for the uuid parameter. It does not explicitly say when to use company_list instead, but the by-uuid lookup intent is unambiguous.

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

All TokenBel Financial Data 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.

Resources

Need Help?