mason

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: analyze_project focuses on git history stats, full_analysis provides a comprehensive overview, get_code_samples offers file previews, get_impact assesses change dependencies, get_snapshot retrieves concept maps, and save_snapshot persists them. The descriptions explicitly differentiate their functions, eliminating any ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., analyze_project, get_code_samples, save_snapshot), using snake_case throughout. The verbs are descriptive and aligned with the actions (analyze, get, save), making the naming predictable and easy to understand.
Tool Count5/5
With 6 tools, the server is well-scoped for codebase analysis and navigation. Each tool serves a unique and necessary function, from initial exploration (full_analysis) to specific tasks like impact assessment and snapshot management, avoiding bloat while covering the domain comprehensively.
Completeness5/5
The toolset provides complete coverage for codebase analysis and navigation: it includes initial exploration (full_analysis), detailed stats (analyze_project), file previews (get_code_samples), dependency analysis (get_impact), and persistent concept mapping (get_snapshot, save_snapshot). There are no obvious gaps, supporting end-to-end workflows.
Average 3.9/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- 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.
This repository includes a glama.json configuration file.
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.
View related servers

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

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 of behavioral disclosure. It describes the tool as analyzing 'git history' and returning 'aggregate stats', which implies it's a read-only operation that processes data without modification. However, it lacks details on performance (e.g., time complexity, resource usage), error handling, or prerequisites like git repository availability. The mention of 'expensive to compute manually' hints at computational cost but isn't specific.
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 concise and well-structured in two sentences. The first sentence clearly states the action and outputs, while the second adds context about the analysis being 'aggregate stats' and 'expensive to compute manually'. There's no unnecessary repetition or fluff, making it efficient. However, it could be slightly more front-loaded by integrating the cost hint earlier for better clarity.
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 the tool's complexity (analyzing git history with multiple outputs) and lack of annotations and output schema, the description is moderately complete. It specifies the analysis type and outputs but doesn't detail return formats, error cases, or dependencies. For a tool with no output schema, it should ideally describe the structure of returned stats (e.g., JSON format, keys), leaving gaps in 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?
The input schema has 100% description coverage, with the single parameter 'dir' documented as 'Absolute path to the project root directory'. The description adds no additional parameter semantics beyond this, as it doesn't elaborate on path requirements, format, or constraints. With high schema coverage, the baseline score is 3, reflecting that the description doesn't compensate but also doesn't detract from the schema's information.
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's purpose: 'Run git history analysis on a codebase' specifies the verb and resource. It distinguishes from siblings by mentioning 'aggregate stats across hundreds of commits' and specific outputs like 'commit convention patterns, stale directories, and frequently changed files', which suggests a different focus than tools like 'get_code_samples' or 'save_snapshot'. However, it doesn't explicitly differentiate from 'full_analysis' or 'get_impact', which might have overlapping scopes.
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. It mentions that the analysis is 'expensive to compute manually', implying it's for automated processing, but doesn't specify scenarios where this tool is preferred over siblings like 'full_analysis' or 'get_impact'. There are no explicit when-to-use or when-not-to-use instructions, leaving the agent to infer usage from context alone.
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 describes key behavioral traits: it reads files (implied read-only operation), provides previews limited to ~60 lines, samples multiple file types, and has a sampling approach. However, it doesn't disclose potential limitations like file size constraints, error handling, performance characteristics, or what happens with inaccessible files.
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 appropriately sized at two sentences. The first sentence efficiently conveys the core purpose and scope, while the second adds important behavioral context about file reading. There's minimal redundancy, though the phrase 'Read files natively for full content' could be slightly more precise about the relationship between previews and full content access.
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 tool with 2 parameters, 100% schema coverage, no annotations, and no output schema, the description provides adequate but incomplete context. It explains what the tool does and its sampling approach well, but doesn't describe the return format (what the previews look like structurally), error conditions, or how the sampling algorithm works in practice. The lack of output schema means the description should ideally cover return values more explicitly.
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%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the sampling approach and file types, but this doesn't directly enhance understanding of the 'dir' or 'count' parameters beyond their schema definitions.
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 specific action ('Get previews'), resource ('representative source files from the codebase'), and scope ('first ~60 lines'). It distinguishes from potential siblings by specifying it provides previews rather than full analysis or snapshots, with explicit mention of what types of files are included (entry points, config files, hot files, test examples, directory breadth).
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 provides clear context for when to use this tool: to get previews of representative files for an overview of the codebase. It mentions reading files natively for full content, implying this is for quick sampling rather than deep analysis. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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. It discloses that the data may become stale and provides a refresh command, which is useful behavioral context. However, it doesn't mention error conditions, performance characteristics, or what happens if the directory doesn't exist.
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 efficiently structured with three sentences: purpose statement, usage example, and maintenance instruction. Every sentence adds value without redundancy, making it appropriately sized and front-loaded.
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?
For a single-parameter tool with no annotations and no output schema, the description provides good context about what the tool returns (a concept map with specific mapping examples) and maintenance considerations. However, it doesn't describe the return format structure or error handling.
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%, so the schema already documents the 'dir' parameter as an absolute path to the project root. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score.
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 specific verb ('Get') and resource ('project's concept map'), explaining it's a lookup table mapping features/flows to implementation files. It distinguishes from siblings by focusing on direct file access rather than analysis or saving operations.
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 provides clear context about when to use this tool ('to jump straight to relevant files instead of exploring') and includes an example. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
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 well by stating the persistence nature ('Persists across conversations') and authentication context ('No API key needed'), but doesn't address important behavioral aspects like whether this overwrites existing snapshots, what happens on invalid input, error conditions, or storage limitations. The description adds meaningful context but leaves significant behavioral gaps.
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 perfectly front-loaded with the core purpose in the first sentence, followed by clarifying details in subsequent sentences. Every sentence earns its place: the second explains what gets mapped, the third explains persistence benefits, and the fourth clarifies authentication context. Zero wasted words or redundant 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?
Given the tool's complexity (3 parameters with nested objects, no output schema, and no annotations), the description provides good purpose and usage context but lacks important behavioral details. For a tool that creates persistent data with complex nested structures, the description should address more about error handling, data validation, overwrite behavior, and what constitutes a successful operation. The absence of an output schema means the description should ideally hint at what gets returned.
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?
With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds minimal semantic context beyond the schema - it mentions 'concept-to-files map' which relates to the 'features' and 'flows' parameters, and 'project root directory' which relates to 'dir', but doesn't provide additional usage guidance, format examples, or constraints beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
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 specific action ('Save a concept-to-files map as a persistent project snapshot') and resource ('project snapshot'), and distinguishes it from sibling get_snapshot by explaining this is the creation/writing operation while get_snapshot is the retrieval/reading operation. The phrase 'Persists across conversations — future sessions can call get_snapshot' explicitly differentiates it from the sibling tool.
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 provides explicit guidance on when to use this tool ('Save a concept-to-files map as a persistent project snapshot') and when to use the alternative ('future sessions can call get_snapshot'). It also clarifies the prerequisite context: 'you are the LLM generating the map' indicates this should be used when the AI has analyzed and mapped the project structure.
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 of behavioral disclosure. It describes the tool's output format (curated code sample previews ~60 lines each) and its role as a starting point, but lacks details on performance characteristics, error handling, or resource requirements. The description adds some context but doesn't fully compensate for the absence of annotations.
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 efficiently structured in two sentences: the first details the tool's function and outputs, and the second provides clear usage guidance. Every element serves a purpose with no redundant information, making it easy to parse and understand.
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?
Given the tool's complexity (comprehensive analysis with multiple outputs) and lack of annotations or output schema, the description does well by specifying the return components and usage context. However, it could be more complete by detailing output structure or error cases, though it compensates somewhat with clear workflow guidance.
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 input schema has 100% description coverage, with the single parameter 'dir' clearly documented as 'Absolute path to the project root directory.' The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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 with specific verbs ('Run a complete project analysis') and enumerates the exact outputs (git history stats, project structure, code samples, test mapping). It distinguishes itself from siblings by offering a comprehensive analysis in one call, unlike more focused tools like get_code_samples or analyze_project.
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 provides usage guidance: 'This is the recommended starting point — call this first, then read specific files natively for full content.' It positions this tool as the initial step in a workflow and distinguishes it from alternatives by suggesting follow-up actions with other tools.
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 describes what the tool returns (three signals) and its purpose (impact analysis before editing), but lacks details on permissions, rate limits, error handling, or whether it's read-only/destructive. It provides some context but doesn't fully cover behavioral traits for a tool with no annotations.
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 appropriately sized and front-loaded: the first sentence states the core purpose and return values, and the second provides usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
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?
Given the tool's complexity (impact analysis with multiple signals), no annotations, and no output schema, the description does well by explaining the three return signals and usage context. However, it could be more complete by detailing the output format or any prerequisites. It's largely adequate but has minor gaps for a tool with no structured output documentation.
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%, so the schema already documents both parameters ('dir' and 'files') adequately. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., no examples of valid file formats beyond the schema's examples). Baseline 3 is appropriate when the schema does the heavy lifting.
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 with specific verbs ('analyze the impact of changing specific files') and resources ('files'), and distinguishes it from siblings by specifying it returns three specific signals (git co-change, references, related tests). It goes beyond just restating the name/title to explain what the analysis entails.
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 use this tool ('Use this before editing a file to understand what else might need updating'), providing clear context and a practical guideline. While it doesn't name specific alternatives among siblings, it gives a strong directional cue that sets it apart from tools like 'analyze_project' or 'get_code_samples'.
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:

[![mason MCP server](https://glama.ai/mcp/servers/adrianczuczka/mason/badges/card.svg)](https://glama.ai/mcp/servers/adrianczuczka/mason)

Score Badge

Copy to your README.md:

[![mason MCP server](https://glama.ai/mcp/servers/adrianczuczka/mason/badges/score.svg)](https://glama.ai/mcp/servers/adrianczuczka/mason)

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/adrianczuczka/mason'

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