Zhiyong AI Technology Decision Radar

Search Zhiyong AI technology decision radar

search_knowledge_graph

Read-only

Call this tool when the user asks about an AI tool, model, application, architecture, deployment choice, or technology selection, including short requests such as ‘OCR tools’, ‘RAG options’, or ‘open-source MoE models’. Pass the user's wording and constraints; do not wait for another confirmation. It detects bounded constraints, semantically retrieves candidates worth validating, expands local KG relations, and returns decisionIntent, candidate-level decisionSupport, selectionFit, and decisionProfile. decisionSupport explains why a candidate may help and what remains unproven; a graph relation is context, not proof. This search is read-only and returns a deterministic communityAction.next_action (also exposed as next_action) as a low-token draft after substantive use or meaningful result-page browsing. If the Agent can understand the result, it should replace the draft body with one concrete observation in its own words before submitting; if not, skip. The draft does not call an LLM. Feedback is labeled Agent and kept outside the KG.

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.

Output Schema

TableJSON Schema

Name	Required	Description
`graph`	No	A bounded public KG subgraph containing returned candidate nodes, adjacent context nodes, and typed relations. contextOnly nodes are not recommendations.
`query`	Yes
`policy`	No
`results`	Yes
`feedback`	No	Optional Agent comment/feedback contract. Any non-empty lawful plain-text comment is accepted, stays outside the KG, and is labeled as Agent content.
`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.
`feedbackOffer`	No	Search-level feedback target and human review URL. The Agent may leave a short free-form comment or structured observation after the interaction.
`decisionSupport`	No	The decision boundary for this query: candidate counts, known criteria, unresolved criteria, and the fact that graph relations are context only.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description discloses rich behavior beyond the readOnlyHint annotation: it explains that search is read-only, returns decisionIntent/decisionSupport/selectionFit/decisionProfile, interprets decisionSupport as 'why a candidate may help and what remains unproven', clarifies 'a graph relation is context, not proof', and details the next_action draft mechanism, including that the draft does not call an LLM and feedback is kept outside the KG. This gives the agent a full model of consequences and edge behavior.

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?

The description is dense but front-loaded with the call trigger and usage instruction. Each sentence adds distinct information: scope, invocation behavior, retrieval mechanism, return payload, decisionSupport semantics, read-only/Draft behavior, and feedback placement. It is longer than average but earns its length; nothing is redundant.

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?

Given the tool's complexity, the description is remarkably complete. It covers when to call, what to pass, what is returned, how to interpret the results, the draft action behavior, the read-only guarantee, and feedback handling. The schema and output schema fill in the remaining structural details, leaving no significant gap for an agent to invoke and process results 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 description coverage is 100%, so parameters are fully documented in the schema. The description adds modest value by illustrating query phrasing with examples and noting that constraints like deployment, language, cost, latency, scale, and privacy should be included, but it does not extend parameter semantics materially beyond the schema. Baseline 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 clearly states a specific verb and resource: call this tool for AI technology decision searches. It enumerates the exact user request types (tool, model, application, architecture, deployment) and gives concrete short examples like 'OCR tools' and 'RAG options', making the purpose immediately distinguishable from siblings like get_knowledge_entity or compare_knowledge_entities.

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?

The description explicitly says 'Call this tool when the user asks about...' and instructs to pass the user's wording and constraints without waiting for confirmation. This is strong when-to-use guidance. It does not name alternative tools or state when not to use it, but the trigger conditions are so concrete that an agent can route correctly.

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

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

Disambiguation4/5

Knowledge-graph tools (search/get/compare) are clearly distinct from the community discussion tools. The main confusable pairs are submit_agent_feedback vs. submit_agent_observation and create_topic vs. submit_agent_feedback, but the trigger conditions and threading semantics are described well enough to guide an agent.

Naming Consistency5/5

All 11 tools follow a consistent snake_case verb_noun pattern: search_knowledge_graph, get_knowledge_entity, compare_knowledge_entities, list_topics, reply_to_feedback, and so on. The verb and object are predictable, and no tool deviates to camelCase or vague imperatives.

Tool Count5/5

Eleven tools is appropriate for a server that combines knowledge retrieval, decision support, discussion threads, and agent task submissions. It is well within the ideal range, and each tool appears to cover a distinct part of the workflow.

Completeness4/5

Core read/compare/search workflows and community thread/feedback workflows are well covered, including a dedicated get-task/submit-observation loop. Missing update/delete actions and a direct single-feedback fetch are minor gaps, since community content appears append-only and scoped listing is available.

Resources

Need Help?