Zhiyong AI Technology Decision Radar

Get public KG entity

get_knowledge_entity

Read-only

Read one public entity by stable id or slug. Returns known metadata, decisionProfile dimensions, notes, and typed graph relations. This read never requires a post. If you identify a concrete missing, incorrect, or stale entity fact, optionally report it against this entity using the returned feedbackAction; otherwise do not post.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	The KG entity id, when known.
`slug`	No	The public entity slug, when known.
`language`	No	Optional output language override. If omitted, the public default is Simplified Chinese; use en explicitly for English.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`name`	Yes
`slug`	Yes
`relations`	No
`canonicalUrl`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026
- removedOutput schema / properties / interactionContract
```
Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}
```
Changed1 schema field changedSep 9, 2026
- addedOutput schema / properties / interactionContract
```
Added value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
```

Changed1 schema field changedSep 7, 2026

changedInput schema / properties / language / description

Previous value: -"Optional output language override. If omitted, the server uses Accept-Language and then Cloudflare IP country; the final fallback is English."New value: +"Optional output language override. If omitted, the public default is Simplified Chinese; use en explicitly for English."

First observedSep 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already establish the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description nonetheless adds real context: the operation never requires a post, the feedback path is optional and conditional, and the returned payload includes graph relations. It does not mention pagination or error behavior, but that is minor here.

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?

Three sentences, front-loaded with the core action and return contents before the optional-feedback caveat. The 'otherwise do not post' clause is slightly redundant with the preceding sentence, a small amount of waste.

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 annotations covering safety and an output schema covering return values, the description carries only what structured data cannot: the read-never-requires-a-post contract and the conditional feedback pathway. Complete enough for an agent to invoke correctly, with only minor gaps around identifier precedence when both id and slug are supplied.

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 description coverage is 100%, so the baseline is 3. The description adds a genuinely useful semantic beyond the schema: id and slug are alternative stable identifiers ('by stable id or slug'), which is not stated in the schema where neither is required.

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?

States a specific verb and resource ('Read one public entity by stable id or slug') and enumerates what comes back (metadata, decisionProfile dimensions, notes, typed graph relations). It implicitly distinguishes itself from search_knowledge_graph (search) and compare_knowledge_entities (compare), though it never names those siblings.

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 clarifies the posting/feedback relationship ('This read never requires a post', report only concrete issues via feedbackAction, 'otherwise do not post'), which is useful. However it gives no guidance on when to call this versus search_knowledge_graph or compare_knowledge_entities, which is the main alternative-selection question for this tool.

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

All Zhiyong AI Technology Decision Radar 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?