Query structured audit logs for AI code changes. Filter by file path, recent count, or export format; view only rejected or unauthorized modifications.
查看审计日志（按文件/recent/格式过滤）
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | 按文件路径过滤 | |
| root | Yes | . | |
| format | No | ||
| output | No | 导出文件路径 | |
| recent | No | 最近 N 条 | |
| rejected | No | 只看被拒绝的变更 | |
| unauthorized | No | 只看未授权的变更 |
Changes observed during successful MCP inspections.
v0.7.14Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it filters by file/recent/format, which is behavioral but not beyond the parameters. It does not disclose any additional traits such as return format, pagination, or potential performance implications, but given the annotations, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core purpose and the main filtering options. Every word earns its place, making it an ideal example of conciseness for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description is incomplete. It fails to mention the 'rejected', 'unauthorized', and 'output' parameters, which are significant for the tool's functionality. An agent might not know these capabilities exist, and there is no information about the output format or how filters combine. The description is too sparse for full contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, with descriptions for most parameters. The description mentions three filter options (file, recent, format) but does not add new meaning beyond what the schema already provides. It omits the 'rejected' and 'unauthorized' filters and the 'output' parameter, so it does not fully summarize all capabilities. Since coverage is high, the baseline of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'view' and the resource 'audit logs', and mentions filtering by file/recent/format. It distinguishes itself from sibling tools because none of the siblings are related to logs, so the purpose is unambiguous. It could be more specific about what the logs contain, but it is not tautological or vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, conditions, or any context where another tool would be preferred. The only implicit usage is that it is the log viewer, but there is no explicit comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.