Txa_MCP

Overview Schema Source Related Servers Discussions Admin

code_metrics

Analyze code metrics for any file, including line count and basic complexity. Provide a file path to get these metrics; set allow_external_access to analyze files outside the project root.

Instructions

Phân tích chỉ số code (Số dòng, độ phức tạp cơ bản).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filePath": "<filePath>"
    },
    "name": "code_metrics"
  }
}

Input Schema

Name	Required	Description	Default
`filePath`	Yes	File to analyze
`allow_external_access`	No	Set to true to allow analyzing files outside the project root. User must explicitly approve this action.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.0.3Aug 11, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the tool is read-only, whether it might access external files (despite the schema's allow_external_access parameter), or what the output format looks like. This lack of detail is a significant gap.

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, concise sentence in Vietnamese, front-loaded with the purpose and followed by specific examples in parentheses. It contains no redundant information and is easily parsed.

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 tool with no annotations and no output schema, the description is too minimal. It does not clarify that the tool analyzes a specific file, what metrics are returned beyond the examples, or any safety implications such as external file access. This leaves the agent without full contextual understanding.

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%, with both parameters (filePath and allow_external_access) already documented. The tool description adds no additional parameter-specific meaning, so the baseline score of 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 the tool's function: 'Phân tích chỉ số code' (Analyze code metrics), with explicit examples of metrics (lines of code, basic complexity). This specific verb+resource combination distinguishes it from sibling tools like analyze_network or get_project_summary.

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 no guidance on when to use this tool versus alternatives, nor any exclusions, prerequisites, or situational context. It simply states what the tool does, leaving the agent to infer usage.

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