Skip to main content
Glama
savantcat

savantcat-ai-compliance-mcp

Official

search_articles

Read-onlyIdempotent

Search within one Chinese AI compliance regulation by keywords to locate which articles cover a topic, returning cited article numbers and excerpts.

Instructions

在某一部法规内部按关键词检索条文,返回命中条号 + 条文摘录。

用途:已经知道是哪部法规,要定位「哪一条讲了这件事」。

Args:
    law: 法规名或集群标识(同 get_article 的 law 参数)
    keywords: 检索词,如「训练数据 合法来源」「标识 元数据」「备案 十日」
    top_k: 返回条数,默认 5

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lawYes
top_kNo
keywordsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.1

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered structurally. The description adds the top_k default and the hit shape, but no rate limits, ranking behavior, or empty-result semantics beyond what annotations/schema give.

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?

Front-loaded one-line purpose, then a usage line, then a compact Args block. Every sentence adds information; nothing is padding.

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?

An output schema exists, so return-value explanation is unnecessary, and all three parameters are addressed. The main residual gap is the format/syntax of the law identifier and how multi-term keywords are combined, which matters for correct invocation.

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 0%, so the description must carry the load, and it does reasonably: law is defined as 法规名或集群标识 and linked to get_article's law param, keywords gets three concrete example queries, and top_k's default of 5 is restated. It still does not specify law identifier syntax or keyword tokenization (space-separated AND/OR?), leaving some ambiguity.

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?

States a specific verb (检索), resource (条文), and scope (某一部法规内部), plus what is returned (条号 + 条文摘录). The scope phrase distinguishes it from the broader search_compliance sibling, so an agent can tell which search tool to reach for.

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 用途 line gives an explicit triggering condition: you already know which regulation, and you want to locate which article addresses a topic. It does not name the contrasting sibling (e.g. search_compliance for when the law is unknown), so the exclusion is only implied.

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