Archy

by hslee16

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.41.0
Disambiguation5/5
Each tool has a clearly distinct purpose: archy_check catches direct layer violations, archy_contracts handles transitive contract rules, archy_cycles finds import cycles, archy_graph dumps the full dependency graph, archy_high_risk_modules ranks high-risk modules, archy_impact computes blast radius, and archy_trend reads history. No two tools overlap in functionality.
Naming Consistency5/5
All tools follow the consistent pattern 'archy_' followed by a descriptive noun (check, contracts, cycles, graph, high_risk_modules, impact, trend). Conventions are uniform across the set.
Tool Count5/5
With 7 tools, the server is well-scoped for Python architecture analysis. Each tool addresses a specific need—violations, contracts, cycles, graph, risk, impact, and trends—without being too few or excessive.
Completeness4/5
The tool set covers core analysis tasks (direct/transitive violations, cycles, full graph, risk, impact, and trends). Minor gaps: tools like archy_graph_focus or archy_graph_summary are mentioned but not provided as separate tools, and there is no tool for listing architecture rules or configuration. Still, the main workflows are well-supported.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 140 commits in the last 12 weeks
- Last stable release on August 1, 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.
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?
With no annotations, the description carries the full burden. It explains the metric and output breakdown but does not explicitly state that the tool is read-only and has no side effects. The behavior is inferred but not fully 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 concise, structured logically: purpose, metric explanation, usage guidance, and output details. Each sentence adds value without redundancy.
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?
Despite an output schema and sibling context, the description fails to explain the two parameters, which is a critical gap. Without parameter descriptions, the tool cannot be correctly invoked. The output breakdown is good, but the overall completeness is low due to missing parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters 'path' or 'top_n'. 'path' is not defined (e.g., file path or module path), and 'top_n' lacks context on default behavior. The description provides no added meaning beyond the schema.
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 returns top-N internal modules ranked by edit-risk, explains the composite metric (geometric mean of three factors), and what a high score signifies. It distinguishes the tool from siblings by focusing on risk ranking.
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?
Explicitly advises calling before non-trivial edits to decide on scoping down, snapshots, or human review. Though it doesn't list when to avoid or name specific sibling alternatives, the guidance is clear and actionable.
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 provided, and description does not disclose read-only nature, side effects, or permissions beyond stating it reads a file. Minimal behavioral info.
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?
Single sentence, no wasted words, front-loaded purpose.
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?
Output schema exists but description lacks guidance on when to use vs siblings, and misses parameter explanation for path. Adequate but incomplete given missing annotations.
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 coverage 0%, so description must explain params. It explains 'last_n' but not 'path' fully; path is implied but not explicitly defined. Partial compensation.
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?
Description clearly states 'Read the recent score history' with specific verb and resource, mentions file name and ordering, and distinguishes from siblings like archy_score or archy_diff by focusing on history/trend.
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?
Description implies usage for comparing deltas via 'so an agent can compare deltas', but lacks explicit when-not-to-use or alternatives among siblings.
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 describes the algorithm and output but does not disclose whether the tool is read-only, or mention destructive actions rate limits, or other behavioral traits. Provides some transparency but not complete.
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?
Two efficient sentences front-loading purpose and adding algorithmic detail. Could include more parameter info without becoming verbose, so slightly below perfect.
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 three parameters and zero schema coverage, the description is incomplete. It fails to explain the required 'path' parameter and the 'internal_only' boolean. With an output schema present, return values are covered, but parameter gaps remain.
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 explains 'min_size' via the algorithm description, but does not explain 'path' or 'internal_only'. Significant gap in parameter documentation.
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 finds import cycles using Tarjan SCCs, specifies a minimum size filter, mentions self-loops, and indicates output ordering. This distinguishes it from sibling tools like archy_graph or archy_high_risk_modules.
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 on when to use (finding cycles in Python projects) but does not mention when not to use or alternatives. Given the sibling list, it's the only cycle-finding tool, so the context is sufficient.
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?
With no annotations, the description carries full burden. It explains that unresolved files are returned in 'unresolved' and defines 'propagation_cost'. It implies a read-only operation. It does not disclose side effects or permissions, but for a read-only tool this is adequate.
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 at 3 sentences, front-loading the main purpose. It efficiently adds detail about unresolved files and propagation_cost. Minor room for improvement in structuring parameter info.
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 has 2 required parameters and an output schema, the description partially covers usage and output. It explains the output fields but leaves the 'path' parameter unexplained. With sibling tools and no annotations, it is moderately complete but has a clear gap.
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%, so the description must explain parameters. It implicitly describes 'files' as 'changed file paths', but 'path' is not explained. The description fails to clarify what 'path' represents, leaving a gap in parameter understanding.
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 action: 'return the internal modules that transitively import any of them (the blast radius).' It specifies the verb 'return' and the resource 'blast radius', distinguishing it from sibling tools like archy_diff or archy_check.
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 'Use before refactoring or removing a module to see what would break.' This provides clear context for when to use the tool. However, it does not mention when not to use it or alternatives, so it's slightly less than perfect.
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?
Describes behavioral traits: runs multiple contract types, reads config from .importlinter or pyproject.toml, and is stricter than archy_check. Lacks some specifics about output format or exact conditions, but covers key aspects. No annotations provided, so description carries full burden.
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?
Concise with a bolded key sentence up front. Includes relevant details but could be slightly more streamlined. Every sentence adds value.
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 (2 params, output schema exists), the description covers usage context, behavior, and prerequisites. Missing parameter explanations, but overall sufficiently complete for a check tool.
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 does not explain the path or config_path parameters. It mentions 'import-linter contracts' but does not link to parameters, leaving agents to infer usage from context.
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?
Clearly states the tool is for checking import-linter contracts after Python edits that modify imports, and distinguishes itself from sibling archy_check by being stricter. Uses specific verb and resource.
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?
Explicitly specifies when to call (after import changes, especially across package boundaries) and provides actionable advice on failure (revert or restructure). Also contrasts with archy_check and mentions installation requirement.
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?
With no annotations, the description effectively discloses key behavioral traits: it refuses serialization beyond a limit and explains why (context protection). It could explicitly state it's a read operation, but the dump nature implies no destructive side effects.
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?
Two well-structured sentences: first states purpose and format, second adds behavioral caveat and alternatives. No wasted words.
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 output schema exists, return values need no explanation. The description covers the tool's main behavior, limits, and alternatives. Minor gap: no parameter descriptions beyond max_nodes, but path and internal_only are reasonably inferred.
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%, but the description only explains max_nodes, leaving path and internal_only unexplained. Users must infer their meaning from context or the command line analogy.
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 'Full dependency-graph dump' and explicitly distinguishes from siblings like archy_graph_focus and archy_graph_summary, making the tool's purpose and differentiation unambiguous.
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 gives explicit guidance: use for full graph dumps, but prefer alternatives for most reasoning. It also explains the max_nodes limit and how to override it.
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 burden. It discloses that the tool returns violations and sdp_violations, and explains that empty lists mean no boundary crossings. However, it does not cover auth, rate limits, or other side effects. The behavioral disclosure is good but not exhaustive.
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 paragraph, front-loaded with the key usage instruction, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description adequately explains what the tool returns and how to interpret results. It also distinguishes from sibling tools, making the context complete for an inspection tool.
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 input schema provides no descriptions for the two parameters. The tool description does not explain what 'path' or 'config_path' represent or how they relate to the config file. This omission leaves the agent with limited understanding of parameter semantics.
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 checks for forbidden direct edges and SDP violations after import changes. It explicitly distinguishes from sibling archy_contracts which handles transitive checks.
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 gives explicit guidance: 'Call after any Python edit that adds, removes, or changes an import statement.' It also suggests pairing with archy_contracts for transitive checks, providing clear usage context and alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/hslee16/archy'

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