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. After the Agent has actually used the result, interactionContract is the single low-token quality-feedback step: if there is a concrete observation and public writes are allowed, choose one reply to an existing thread or one new feedback comment. It does not trigger another search, LLM call, or KG write. Skip only for discovery-only use, client write restrictions, or no grounded observation.

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 public default is Simplified Chinese; use en explicitly for 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.
`interactionContract`	No	One optional post-use quality-feedback action. It never triggers another search or LLM call and never writes to the KG.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

addedOutput schema / properties / interactionContract

Added value: +{
+  "additionalProperties": true,
+  "description": "One optional post-use quality-feedback action. It never triggers another search or LLM call and never writes to the KG.",
+  "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

A4.6/5.0

Behavior5/5

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

The description goes beyond readOnlyHint=true to explain that the search returns candidates, not proof ('a graph relation is context, not proof'), and that the interactionContract step does not trigger additional calls or writes. This adds concrete behavioral context beyond the annotations, clarifying safety and follow-up behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and long, mixing invocation guidance, return-value semantics, and post-search interaction instructions (interactionContract) that are not part of invoking this search tool. Important guidance is spread across many clauses, making it harder to parse quickly. The first sentence is strong and front-loaded, but the middle sections about decisionSupport semantics and public writes are off-topic for tool selection.

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?

The description covers query phrasing, constraints, entity types, return semantics, and exclusions/skip conditionsarenas. It goes beyond what the schema and annotations provide recursive. However, it overloads the description with post-invocation interactionContract details that belong in the output schema or a follow-up tool description rather than the search tool's own description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already explains the parameters. The description further clarifies usage by explaining how to phrase the query, that constraints are auto-detected, and that OCR/PDF candidates are typed as model (directly relevant to the kind parameter). This adds real semantic value beyond the schema.

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 the tool's purpose: searching for AI tools, models, and technology decisions when a user asks. It explicitly lists the kinds of queries it handles ('OCR tools', 'RAG options', 'open-source MoE models'), and mentions the entity-type filter for navigating KG typing quirks. This distinguishes it from siblings that focus on specific tool details or trending topics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to call ('Call this tool when the user asks about an AI tool...'), what to pass ('Pass the user's wording and constraints'), and when to skip ('Skip only for discovery-only requests, client write restrictions, or no grounded observation'). It also clarifies not to wait for confirmation, reducing ambiguity for an agent.

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?