AnJian Agent

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation4/5
Tools are generally well-distinguished by action (assess, list, run, import, generate, scan, validate) and resource. However, anjian_doctor, anjian_capability_plan, and anjian_list_assessments all touch capability/status inspection and could occasionally confuse an agent about which to use for checking system state.
Naming Consistency3/5
All tools share the anjian_ prefix with snake_case, showing consistency. However, the naming is inconsistent in granularity and verb style: some use domain-specific verbs (consolidate, validate_observation, import_pcap) while others are action-focused (run, list, create, get). The nouns range from concrete (assessment, target) to abstract (doctor, consolidate), lacking a uniform verb_noun pattern.
Tool Count4/5
At 15 tools, this is near the high end of the ideal range but reasonable for a security assessment platform covering assessment lifecycle, evidence import, analysis, and reporting. Each tool serves a distinct stage of the workflow. Slightly heavy but justifiable given the breadth of the domain.
Completeness4/5
The surface covers the full assessment lifecycle: create/get/list/run assessments, import evidence (Burp/HAR/PCAP/source), consolidate, validate, and generate reports. Minor gaps include no explicit tool for deleting/deprecating assessments or managing report history/cleanup, and no dedicated tool for listing imported evidence, but agents can work around these.
Average 2.8/5 across 15 of 15 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on July 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add one meaningful behavioral detail about the 'active' level requiring separate terminal unlock. However, it doesn't disclose whether this is a read or mutating operation, what side effects occur, whether use_external_tools has security implications (especially given many sibling tools relate to security testing/pcap), or what happens to the assessment after running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), which technically scores well on conciseness, but the brevity is a function of under-specification rather than deliberate economy. It does front-load the primary purpose in the first clause. One could argue a 4 given the minimal waste, but the lack of substance makes the conciseness a weakness, not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, this description is inadequate. It doesn't explain what the assessment run returns, how the 'level' interacts with 'use_external_tools', whether this assessment modifies state, or what prerequisites exist (besides the 'active' unlock note). The security-testing context implied by sibling tools (pcap, web evidence, controlled active tools) makes the missing behavioral and permission context especially concerning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate but does not. The description only mentions the 'active' level behavior, leaving 'passive' and 'baseline' levels unexplained. The critical parameters assessment_id and use_external_tools receive zero explanation about their meaning, valid inputs, or consequences. The mutually-exclusive nature of the levels is not clarified beyond the one note about 'active'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states "运行授权评估" (run authorization assessment), which identifies a verb+resource combination, but the description is very brief and doesn't distinguish this tool from siblings like anjian_create_assessment, anjian_get_assessment, or anjian_quick_assess. The meaning of "授权评估" leaves ambiguity about whether this executes, creates, or validates an assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage condition: 'active' level only executes when user has separately unlocked it via terminal. However, it provides no guidance on when to use this versus anjian_create_assessment or anjian_run_controlled_active_tool, and no explanation of the relationship between assessment_id, level, and use_external_tools. No exclusions or alternatives are named explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it does disclose an important limitation (MCP cannot authorize or broaden scope), it doesn't state what side effects occur (does it launch external processes? are these destructive scans?), whether it modifies anything, or what safety guarantees exist. For a security scanning tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—one sentence. It is 'concise' but arguably under-specified rather than efficiently structured. The caveat sentence about MCP authorization is somewhat useful but placed in the same sentence as the purpose, muddying clarity. There is no front-loading of the most important operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool: 5 parameters, 2 security scanning tools, and no output schema or annotations. Given the complexity and the danger profile of running sqlmap/ffuf, the description is severely incomplete. It doesn't document what the output looks like, what prerequisites exist (e.g., authorized target list, which it likely relates to given anjian_list_authorized_targets), or how constraints are enforced. The blanket 'controlled' claim is unexplained.
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 0%, but there are 5 parameters. The description names the two tools (sqlmap, ffuf) which maps to the enum, but provides no semantics for assessment_id, endpoint_url, request_file, or wordlist_path. An agent would not know endpoint_url vs request_file distinction (both default to empty strings) or how wordlist_path relates to ffuf usage. The description adds essentially nothing beyond what the parameter names and enum convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it runs controlled SQLMap/FFUF on the terminal, with a caveat that MCP lacks authorization. The verb+resource is identifiable but the description is terse—it doesn't clarify what 'controlled' operation entails, what the tool actually does with inputs (injects a request file? probes an endpoint?), or how it differs from sibling anjian_run_assessment. It also fails to distinguish from anjian_scan_source and anjian_run_assessment, which likely overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. With siblings like anjian_run_assessment, anjian_scan_source, and anjian_capability_plan, there is no indication which should be used for active scanning versus qualitative assessment. The authorization caveat implies usage is restricted but gives no concrete basis for deciding invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions '根据本机真实工具状态' (based on real local tool state) which suggests introspection, but doesn't disclose side effects, whether it mutates state, reads system tool configurations, or what happens during execution. The behavioral profile is under-specified.
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 a single sentence that is concise and front-loads the main purpose. Every clause contributes meaning, though as noted the meaning is somewhat generic. It is appropriately brief for a single-sentence description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there's no output schema, no annotations, and a 0% schema description coverage, the description is the only information source, but it's thin. It doesn't clarify what the layered execution plan contains, what 'safe routing' means concretely, how it relates to the assessment workflow, or what the output format looks like. For a tool that generates plans for a security assessment workflow with 14 siblings, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the only parameter, assessment_id, has a default of empty string but zero documentation. The description doesn't explain what assessment_id does or whether it's needed. With a single optional parameter and no schema description, the description adds no meaning beyond the raw parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it generates a layered execution plan based on local tool state and explains safe routing for other Claude MCP tools. The verb '生成' (generate) with resource '分层执行计划' (layered execution plan) is reasonably specific, but it doesn't clearly distinguish how this differs from sibling tools like anjian_consolidate or anjian_quick_assess, making the unique function somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '说明其他 Claude MCP 的安全路由' (explains safe routing for other Claude MCP tools) which hints at when it might be useful, but there's no explicit guidance on when to call this versus siblings like anjian_quick_assess or anjian_doctor, nor conditions or prerequisites for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It mentions generating reports and SHA-256 manifests but doesn't disclose what happens to existing files (overwritten?), whether report outputs are persisted or returned, storage locations, or side effects. The description is vague about the actual behavior beyond generating output formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is economical, but it's under-specified rather than appropriately concise. It front-loads the core purpose but omits critical operational details. There is no wasted text, but the brevity comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% parameter description coverage, this description leaves a lot unexplained. The tool takes 4 parameters (one required) and produces multiple report formats plus a manifest, which suggests non-trivial complexity. The description is inadequate for a tool at this complexity level—an agent would need to guess about output structure, file handling, and the meaning of evaluation_id in relation to 'recent runs'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions the output formats it produces. It doesn't explain what assessment_id refers to, what include_html/include_obsidian control (though these are fairly self-explanatory), or what obsidian_vault path should be. The description adds minimal value for understanding parameters beyond their names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool generates Chinese Markdown/HTML/Obsidian reports and SHA-256 manifests from recent runs. This is a specific verb+resource combo with clear output formats. However, it doesn't distinguish from sibling tools like anjian_consolidate or anjian_capability_plan, and the phrase 'recent run' is ambiguous—does it mean the most recent assessment or a specified one?
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives is provided. The description doesn't explain when a report should be generated vs. when to run other sibling tools. It also doesn't clarify what 'assessment_id' refers to or how it relates to recent runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the three things read (authorization scope, recent observations, manual confirmation results) which gives some behavioral context, but it doesn't disclose whether this is a read-only operation, any authentication requirements, or whether it can be called independently or requires an existing assessment. The fields read are enumerated, which is useful, but safety/behavioral traits are under-specified.
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 a single, compact sentence that front-loads the purpose. It's appropriately concise with no wasted words, though it could be slightly more informative without violating conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is thin. There's no output schema, so the description carries the burden of explaining what's returned, but it only names three data categories (scope, observations, confirmations) without elaboration on format or depth. Given the read-only nature and single param, it's minimally adequate but leaves the agent guessing about return shape and dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the single parameter `assessment_id` has no description beyond its name. The tool description doesn't elaborate on what format the assessment_id should take (UUID, numeric, slug?) or where to obtain it (perhaps from anjian_create_assessment or anjian_list_assessments). With 0% schema coverage, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool does: reads an assessment's authorization scope, recent observations, and manual confirmation results. It has a specific verb ('读取'/read) and resource ('评估'/assessment). However, it doesn't distinguish this from siblings like anjian_quick_assess or anjian_get... (no other get-sibling exists, but anjian_list_assessments could overlap without clarification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. It doesn't say when one would want to read an assessment's scope/observations versus using anjian_list_assessments, or whether this should be called before/after other operations like anjian_run_assessment or anjian_validate_observation. Context is purely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. '脱敏' (desensitized/redacted) discloses that results are sanitized, and '并入统一报告' indicates integration into a unified report, but it doesn't disclose the actual scanning behavior, potential for external tool calls, whether the scan is synchronous, what happens to files, or any side effects. The description is too terse for a tool with no annotation support.
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 a single efficient sentence with no wasted words. All three clauses ('扫描', '结果脱敏', '并入统一报告') serve a purpose. It's under-specified rather than verbose; no padding or redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter scan tool with no annotations, no output schema, and 0% schema description coverage, the description is severely under-specified. It lacks parameter semantics, return behavior, prerequisite conditions, error handling, and behavioral context around the external tools flag and report integration. The tool is clearly more complex than this one-line description can convey.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate by explaining the parameters. It provides zero parameter-level guidance: source_path format, assessment_id purpose/where to get it, and use_external_tools (a boolean with a default) are all undocumented. The agent has no way to know how to construct or validate the source_path or how the external tools flag affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb '扫描' (scan) and resource '本地源码目录' (local source directory), so the purpose is clear. However, it doesn't differentiate from siblings like anjian_run_assessment, anjian_import_web_evidence, or anjian_import_pcap, which all feed into the unified assessment pipeline. The phrase '结果脱敏并并入统一报告' hints at output processing but doesn't clarify what distinguishes this from other scanning/import tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word '用户明确提供' (explicitly provided by user) implies a precondition for when to use this tool versus other import mechanisms, but this is implied rather than explicit. No exclusions or alternative tool recommendations are given, despite there being 13 sibling tools with overlapping assessment/import functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions deduplication ('去重') and cross-validation marking ('标记交叉印证'), which adds some behavioral context, but it doesn't disclose whether this is a mutating operation, whether it writes to persistent state, whether it can be re-run safely, or whether source data gets consumed/destroyed during consolidation.
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 a single, compact sentence that efficiently conveys the core action (merge), inputs (multiple result types), and outcome (dedup + cross-validation). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a 0% schema description coverage. The description names the inputs but doesn't explain the expected output, whether the agent must run imports first, what 'marking cross-validation' means in practice, or any side effects. For a tool that consolidates multiple data sources, an agent would benefit from clarity on prerequisites and output format.
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 0% for the single parameter (assessment_id). The description doesn't explain what the assessment_id refers to or where it comes from (though this is somewhat inferable from sibling tools like anjian_create_assessment and anjian_list_assessments). Baseline 3 applies given the parameter is simple and self-describing by name, but the description adds no value for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('合并' = merge) and resource (running, Burp/HAR, PCAP, source results), and mentions deduplication by asset/problem fingerprint with cross-validation marking. However, it doesn't distinguish this from sibling tools like anjian_validate_observation or anjian_run_assessment, and the verb '合并' (merge/consolidate) is somewhat generic without clarifying the tool's unique output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., anjian_run_assessment, anjian_scan_source, anjian_import_web_evidence). It's implied that this tool is a post-processing aggregation step after running assessments and importing evidence, but the description doesn't state prerequisites like 'call after anjian_run_assessment' or ordering requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does disclose that human final review is still required before delivery, which is useful behavioral context for a validation/mutation-type tool. However, it doesn't disclose what happens to the observation after validation, whether the decision is reversible, or what side effects recording a decision has on the assessment.
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 a single efficient sentence that conveys key constraints (must explain rationale, human review still needed). It's short and front-loaded with the core purpose. It could add sibling differentiation, but the length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a validation tool with 8 parameters, no output schema, no annotations, and 0% schema coverage. The description is far too thin for the complexity of the operation. It doesn't clarify the decision enum semantics, what validation_rationale should contain for each decision type, how severity/recommendation enrich the record, or what happens after recording. A 4-param required tool with an enum deserves substantially more guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate for the 8 parameters, but it only mentions the rationale content requirement. The description doesn't explain what decision values mean (confirmed vs false_positive vs accepted) or the semantics of assessment_id/observation_id beyond the obvious, or how severity/recommendation relate to the decision. With low schema coverage, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool records manual assisted review decisions, but it's generic and doesn't clearly differentiate from siblings like anjian_consolidate or anjian_run_assessment. The verb '记录' (record) plus the resource '人工辅助复核决定' (manual review decision) gives a reasonable purpose, but the scope/relationship to other anjian tools like anjian_quick_assess or anjian_consolidate isn't clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says validation must explain reproduction, applicable conditions, or false-positive reasons, and that human final review is still needed before delivery. This provides some context but no explicit when-to-use or when-not-to-use guidance, nor does it distinguish when to use this versus sibling tools such as anjian_run_assessment or anjian_consolidate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It's a listing/read operation, but this is never explicitly stated as safe/non-destructive. It doesn't disclose what '最近运行编号' refers to in detail, whether output is sorted, or what constitutes 'recent'. Zero annotation coverage and minimal behavioral context makes this under-specified.
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 a single concise sentence that is front-loaded with the core purpose. There's no wasted text. However, given the low informational content, it could profitably use additional space to clarify usage context and output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple listing tool with no parameters, no annotations, and no output schema, so one might argue the description is sufficient. However, the description doesn't explain what the returned data looks like (assessment names, run IDs, timestamps), what '最近运行编号' metadata means, or how it relates to anjian_get_assessment for follow-up retrieval. A list tool's value depends on what one does with the results, which is unstated.
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?
The tool has zero parameters and 100% schema coverage, so the schema carries no parameter burden. With 0 parameters, the baseline is 4 per the rubric. The description adequately conveys that no input is needed to retrieve the list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool lists local assessments and recent run numbers ('列出本机安鉴台评估及最近运行编号'). The verb is clear (list) and the resource is specified (assessments, recent runs). However, it doesn't distinguish from the sibling 'anjian_get_assessment' which retrieves a single assessment, so the differentiation burden is only partially met.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Among siblings there are several related tools (anjian_get_assessment, anjian_create_assessment, anjian_run_assessment), but the description doesn't clarify when listing is the right choice. The context 'local' implies it's about local-only data, which is a mild usage clue but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the critical safety behavior—that it only reads and inspects, never executing checks against network targets—which is valuable transparency for a 'doctor' tool that might otherwise sound like it runs diagnostics against live systems. However, it doesn't disclose what it does with findings, whether it writes to any state, or what the output looks like. The read-only nature is partially implied but the boundaries of 'external security tools' inspection are unclear.
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 a single sentence that efficiently conveys the tool's scope (read-only), its targets (安鉴台, external security tools, reports), and a critical exclusion (no network target checks). No wasted words, and the negative statement front-loads the safety-critical boundary. It's appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is the only source of information, and it conveys the essential purpose and safety boundary. However, for a tool named 'doctor' (suggesting diagnostics), the description is somewhat thin—it doesn't clarify what a check entails, what constitutes a 'pass/fail' scenario, or how the output would be used. For a simple zero-parameter tool, this is adequate but not rich; more context about what the diagnostic produces would strengthen completeness.
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?
The tool has zero parameters, which means there's nothing for the description to elaborate on parameter semantics. Per the baseline rule for zero-parameter tools, a score of 4 would be baseline, but the description adds no meaningful value about what state or context the tool reads from. Since schema coverage is 100% and there are no parameters to document, the description doesn't need to compensate, but it also doesn't provide any additional semantic context beyond the schema, placing it at the baseline-adjacent level of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs read-only checks on the 安鉴台 (Anjian platform), external security tools, and reporting capabilities, and explicitly clarifies it does not execute checks against network targets. However, the verb '检查' (check/inspect) is somewhat vague about what specific inspection or diagnosis this 'doctor' tool performs, and while it distinguishes itself as non-targeting, it doesn't clarify how it differs from sibling tools like anjian_capability_plan which may also assess platform capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a partial exclusion (does not check network targets) which helps distinguish a core boundary, but it gives no guidance on WHEN to use this tool versus siblings like anjian_quick_assess, anjian_get_assessment, or anjian_capability_plan. There's no stated context for when a doctor/diagnostic check is appropriate, making it unclear which scenarios should trigger this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does state one key behavioral fact: '不会运行网络检查' (will not run network checks), which signals this is a lightweight creation-only operation. However, it doesn't disclose what happens after creation, whether existing assessments are affected, or whether this requires prior authorization validation.
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 a single efficient sentence that front-loads the action and scope, followed by the critical caveat about not running network checks. No wasted words, though it could arguably include a bit more param guidance without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter creation tool with no output schema, no annotations, and 0% param coverage. For such a complex tool, the description should explain return values, what constitutes a successful creation, how the authorization_reference parameter is used, and the format expectations for dates/ports. The description is significantly under-specified for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. It mentions '目标、端口和有效期' (target, ports, valid period) which maps to 'target', 'allowed_ports', and 'valid_until' params, but ignores 'authorization_reference', 'allow_subdomains', 'allow_private_network', and 'valid_from'. Several parameters are undocumented in both schema and description, leaving the agent to guess their format/semantics (e.g., date formats, port syntax).
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 uses specific verbs and resources: '创建严格限定目标、端口和有效期的授权评估' (create an authorized assessment strictly limited by target, ports, and validity period). It clearly distinguishes this creation tool from siblings like anjian_run_assessment or anjian_quick_assess by emphasizing '创建' (create) and the restricted scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via '创建...授权评估' but does not explicitly state when to use this versus anjian_quick_assess or anjian_run_assessment. The mention that it '不会运行网络检查' (will not run network checks) is a distinguishing factor but there's no explicit when-to-use versus when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the read-only nature (使用 TShark 只读分析) and what it does NOT do (不启动全机抓包, 不导出载荷), which is genuinely useful behavioral disclosure distinguishing this from active-capture tools. However, it doesn't disclose anything about required file access permissions, file size limits, output format, or what happens on parsing failure — gaps given zero annotation coverage.
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?
The description is a single sentence that packs purpose, operation mode, exclusions, and safety characteristics into minimal words. Every element earns its place — no filler, no redundancy. This is an exemplary model of concise front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema and no annotations, the description covers the core behavioral contract (read-only, no capture, no export) well. However, given the tool imports/analyzes files into an assessment context, the complete absence of parameter semantics (what assessment_id links to) and no mention of the analysis process or return value leaves meaningful gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the 2 parameters (assessment_id, file_path) are completely undocumented in the schema beyond their names and types. The description does not explain what assessment_id refers to or what file_path format is expected. With 0% coverage and no parameter explanations, the description should compensate but does not, leaving the agent to guess parameter semantics.
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 clearly states the tool uses TShark to read-only analyze a specified PCAP/PCAPNG file, giving a specific verb (import/analyze) plus resource (PCAP). It distinguishes from sibling tools by contrasting against full machine packet capture ('不启动全机抓包'). The purpose is clear, though 'import' in the name suggests ingestion while the description emphasizes analysis, creating slight ambiguity.
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 it performs read-only analysis and does NOT start full-machine packet capture or export payloads, giving clear exclusionary guidance. The sibling tools (anjian_run_controlled_active_tool, anjian_scan_source) suggest when an alternative active-capture tool might be used, though no explicit alternative names are given. The 'when to use' context is implied by the read-only emphasis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description usefully discloses that only sanitized metadata within authorized scope is saved and explicitly states what is NOT saved (cookies, tokens, bodies), which is valuable privacy/security context for an agent deciding to use this tool on sensitive data.
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?
The description is a tight two-clause sentence that packs purpose, scope constraint, and data-handling disclosure without redundancy. Every word earns its place and it is clearly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter import tool with no annotations and no output schema, the description covers the main behavioral contract (what's imported, what's stripped) well. However, given 0% param coverage and no mention of return values, file format details, or error scenarios, it's adequate but has meaningful gaps for a tool handling import.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. The description mentions file formats (Burp XML/HAR) but does not explain either parameter: assessment_id's format/role or file_path's expected path type/location. Both required parameters are undocumented beyond their titles, leaving the agent guessing about acceptable values.
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 states a specific verb+resource ('导入 Burp XML 或 HAR') and clarifies the scope by noting it only saves sanitized metadata within authorized scope. However, it doesn't explicitly distinguish this from the sibling anjian_import_pcap, though the file-format mention (Burp XML/HAR) implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is silent on when to use this vs anjian_import_pcap or other tools. The input formats (Burp XML/HAR) imply web-traffic import use, and the authorization-scope constraint implies prerequisites (authorized targets), but no explicit when/when-not guidance or alternative naming is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does state this is a read-only operation ('只读列出') and that it doesn't access websites, which provides useful safety-relevant behavioral disclosure. However, it doesn't describe what the returned data looks like, pagination, or error behavior. The read-only nature is the key behavioral trait and it is disclosed.
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?
The description is a single, compact Chinese sentence that packs in the purpose (read-only listing), the scope (authorized targets), the prerequisite (one-time local confirmation), and the safety property (no website access). Zero waste, every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), and the description covers the essential purpose and safety profile. However, with no output schema and no annotations, some description of what the return value looks like (a list of targets, their format) would improve completeness. The safety-critical 'no website access' detail is a strong disclosure, but the overall picture is lean for a security-oriented tool.
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?
There are zero parameters, so the schema provides no semantic burden to document. The description adds value by explaining what is being listed (targets confirmed through one-time local terminal confirmation). With 0 params, a baseline of 4 is appropriate as the description compensates for the absence of any parameter-driven semantics.
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 states a specific action: read-only listing of authorized assessment targets that have been confirmed via one-time local terminal confirmation. It explicitly notes no website access. However, it doesn't clearly distinguish from sibling tools like anjian_list_assessments, though the 'targets' vs 'assessments' distinction is somewhat implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the tool lists authorized targets, implying it should be used before running assessments to see pre-approved targets. However, it doesn't explicitly state when to use this vs alternatives (e.g., anjian_list_assessments for completed assessments). The 'single confirmation' and 'no website access' give some context but not explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that only non-destructive tools are used (a meaningful safety trait) and that it produces a Markdown report. However, it doesn't disclose what happens to existing assessments, potential rate limits, or whether results are persisted/overwritten for the target.
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?
The description is a single efficient sentence that packs purpose, scope, safety constraint, and output format. Zero wasted words, front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter automated tool with no annotations and no output schema, the description covers the core workflow (run tools, merge evidence, generate report) but omits details like whether the report is stored, how to retrieve it, or what happens on failure. The safety disclosure (non-destructive) partially compensates for missing annotations.
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?
The schema has one parameter (target) with 0% description coverage, so the description must compensate. It states '只需网址' (only needs a URL), which clarifies the expected format/value of target. This is sufficient for a single-parameter tool, though it doesn't specify whether the target must exactly match a registered name or a hostname format.
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 clearly states the verb+resource: '一键深度评估已登记目标' (one-click deep assessment of registered targets). It explains what it does: runs available non-destructive tools, merges evidence, and generates a Markdown report. However, it doesn't explicitly distinguish from siblings like anjian_run_assessment, anjian_consolidate, or anjian_generate_report, which could each overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool runs '非破坏性工具' (non-destructive tools) and works on '已登记目标' (registered targets), implying it requires prior registration. It mentions '只需网址' (only needs a URL), which signals minimal input. However, no explicit when/when-not guidance or alternative tool references (like anjian_run_assessment or anjian_consolidate) are given, leaving the agent to infer overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![anjian-agent MCP server](https://glama.ai/mcp/servers/ck3938700-ship-it/anjian-agent/badges/card.svg)](https://glama.ai/mcp/servers/ck3938700-ship-it/anjian-agent)

Score Badge

Copy to your README.md:

[![anjian-agent MCP server](https://glama.ai/mcp/servers/ck3938700-ship-it/anjian-agent/badges/score.svg)](https://glama.ai/mcp/servers/ck3938700-ship-it/anjian-agent)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ck3938700-ship-it/anjian-agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server