Zhiyong AI Knowledge Graph

Search Zhiyong AI knowledge graph

search_knowledge_graph

Read-only

Use Zhiyong AI as a read-only AI transformation selection engine. Pass a natural-language business need or an existing offering; it detects bounded constraints, semantically retrieves model/tool candidates, expands local KG relations, and returns decisionIntent, selectionFit, and decisionProfile states. Unknown is not unsupported; source evidence and raw URLs are intentionally omitted.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	Optional entity type filter, for example tool, model, application, or all. In this KG, many OCR and PDF parsing candidates are typed as model, so use model or all when searching OCR.	all
`query`	Yes	A natural-language business need, constraints, existing offering, tool, model, or concept. Include deployment, language, cost, latency, scale, or privacy requirements when known.
`language`	No	Optional output language override. If omitted, the server uses Accept-Language and then Cloudflare IP country; the final fallback is English.
`max_results`	No	Maximum number of public KG results to return.

Output Schema

TableJSON Schema

Name	Required	Description
`query`	Yes
`policy`	No
`results`	Yes
`retrieval`	No	Semantic retrieval diagnostics and the parsed decisionIntent; no private evidence is included.
`synthesis`	No	Optional second-stage shortlist summary grounded only in the returned KG candidates; absent when the model is unavailable or not needed.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover read-only and non-destructive; the description adds meaningful behavior: it detects constraints, semantically retrieves, expands KG relations, and returns three decision states. It also discloses useful caveats—unknown is not unsupported and source evidence/URLs are intentionally omitted.

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 tight sentences front-load the essential purpose and then add the input/process and caveats without fluff. Every sentence contributes information an agent can act on.

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 full schema, read-only annotations, and an output schema, the description supplies the remaining context: the candidate-selection workflow, return-state names, and the important caveat about omitted sources. Nothing essential for selecting and invoking this tool is missing.

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 documents all four parameters. The description's mention of natural-language needs and constraints only restates query semantics; it adds no extra parameter meaning.

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 names a specific operation—searching the Zhiyong AI knowledge graph as a read-only selection engine—and explains the flow: input natural-language need, semantic retrieval, KG expansion, and decision states. However, it does not mention the sibling tools compare_knowledge_entities or get_knowledge_entity, so an agent must infer how it differs from them.

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 clear when-to-use guidance: pass a business need or existing offering to select AI model/tool candidates. It stops short of explicit exclusions or alternative-tool routing, so it lacks the explicit comparison that would earn a 5.

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

All Zhiyong AI Knowledge Graph tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Search, get, and compare serve clearly distinct workflows: discovering candidates, fetching a single entity, and comparing a short-list. Overlapping output fields do not create meaningful ambiguity because the operational intent is different.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case and domain-specific objects. Singular/plural and graph-versus-entity variations are grammatically appropriate for each operation.

Tool Count5/5

Three tools form a tight, well-scoped read-only knowledge graph server. Each tool earns its place and together they cover the core search, inspect, and compare workflow without redundancy.

Completeness5/5

For a read-only AI transformation selection engine, the surface covers discovery via search, detail via get, and comparative analysis via compare. Write operations and raw source evidence are explicitly and intentionally excluded, so there are no consequential gaps.

Resources

Need Help?