A
licenseNot graded
qualityD
maintenanceProvides a stdio MCP bridge for coding agents to query and record engineering knowledge locally, preserving debugging history, failed attempts, and verified solutions.
1 npm
MIT
arale-code
Officialby scalacore
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@arale-codelist the procedures and read the one for writing tests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
arale-code
Local engineering guidance for coding agents, served through MCP. arale-code gives an agent four reusable instructions, a control Guide and 20 software engineering procedures. The server provides documents; the agent decides what to do with them under its own tools and permissions.
Read the Guide, choose one procedure, then read its full document.
Find the right procedure
Connect an MCP client to the local STDIO server.
Read
arale://procedure/guidefor the selection rules, or calllist_proceduresto discover IDs and resource URIs.Read the selected procedure in full, then apply it to the user’s task within the agent’s existing permissions.
For example, call the list_procedures MCP tool with an empty argument object:
{}It returns a JSON string whose first entry is the Guide (excerpt; the full documents array has 21 entries):
{"schema_version":1,"documents":[{"id":"guide","code":"GUIDE","title":"Control Guide","kind":"guide","uri":"arale://procedure/guide"}]}Read that URI as an MCP resource to get the YAML Guide. Its meta.id is GUIDE and its meta.version is '1.6'. The example shows catalog discovery; it does not cause the server to edit a project.
Related MCP server: CodeContext MCP
Get started
You need Python 3.12 and uv, with the locked dependencies available locally. From the repository root, prepare the environment without a network request:
uv sync --locked --offline --no-python-downloadsThen follow INSTALL.md to register one client and check its live MCP connection. It documents Codex CLI, Claude Code, Cursor, OpenCode and Antigravity CLI, including the local launch command. An offline sync can fail if Python or a locked dependency is missing from the local cache; the installation guide explains what to check before downloading anything.
What is included
Interface | Contents |
Tools |
|
Catalog resources |
|
Resource templates |
|
Prompt |
|
The bundled documents are four Markdown instructions, one YAML Guide and 20 YAML procedures. See the MCP contract for exact IDs, response shapes and errors.
Boundaries and verification
The server is read-only and stateless. It serves bundled guidance over local STDIO; it does not execute procedures, grant permissions or make outbound network requests. The consuming agent remains responsible for any project changes.
Repository tests and an isolated local STDIO package check have verified the bundled interface and Guide 1.6 assets. The five client paths in INSTALL.md are documented installation paths; live discovery in each client has not been verified here. See the verification contract for the checks required after client registration.
Develop and contribute
Prepare the locked environment as above, then run the repository’s quality gates:
uv run ruff check .
uv run ruff format --check .
uv run mypy src tests
uv run pytestFor changes to the MCP interface or bundled documents, read the server contract and quality gates, and include the relevant verification with your proposed change. For installation questions, start with INSTALL.md.
License and maintainer
Maintained by Scala Core. Licensed under Apache 2.0; see NOTICE for attribution.
Available Tools
2 toolslist_instructionsList InstructionsARead-onlyIdempotent
List valid engineering-instruction IDs and their resource URIs. Call this before requesting an instruction when the ID is not already known.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds what is returned (valid IDs and URIs) and its role as a prerequisite lookup, but says nothing about pagination, scale, or whether the list is filtered by permissions.
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 short sentences with zero waste; the resource scope is front-loaded and the usage condition follows. Nothing is repeated from the title or schema.
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?
An output schema exists, so return shape need not be spelled out, and the description still characterizes the return as IDs plus URIs. For a parameterless read-only list tool with full annotation coverage, nothing an agent needs to invoke it correctly is missing.
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 takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty object is unambiguous.
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?
States a specific verb (list) and resource (engineering-instruction IDs and their resource URIs), which is more precise than the title alone. It does not distinguish itself from the sibling list_procedures, so the agent must infer the domain split from the descriptions themselves.
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?
"Call this before requesting an instruction when the ID is not already known" gives a clear trigger condition plus a when-not condition (ID already known). It does not explicitly name an alternative tool, but for a zero-param discovery endpoint the routing guidance is essentially complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_proceduresList ProceduresARead-onlyIdempotent
List the Arale control guide and procedures with their IDs and resource URIs. Call this before reading a procedure when the ID is not already known.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new behavioral context: the tool is a discovery prerequisite for reading procedures, which the annotations do not convey.
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 short sentences, zero filler. What is returned is stated first, then the call-timing rule, which is the right front-loading for a discovery tool.
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?
An output schema exists, so return values need not be enumerated, and annotations carry the safety profile. For a zero-parameter list tool, the description supplies everything an agent needs: what it enumerates, what identifiers it yields, and when to call it.
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 takes no parameters, so the schema baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter guidance.
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?
States a specific verb (List) and resource (Arale control guide and procedures) and notes the payload contains IDs and resource URIs. It does not explicitly distinguish itself from the sibling list_instructions beyond the resource noun, so an agent must infer the split from the names alone.
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?
Gives an explicit call condition: 'Call this before reading a procedure when the ID is not already known.' That establishes the sequencing dependency clearly. It stops short of naming list_instructions as the alternative for the other resource, so the when-not case is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
list_instructions - First observed
list_procedures
TDQS
A3.9/5.0
Scored across 2 tools
Disambiguation4/5
The two tools are mostly distinct: one lists procedures/control-guide entries and the other lists engineering-instruction IDs. They share a very similar list-by-ID/URI pattern, but the descriptions make the resource type clear enough to avoid most confusion.
Naming Consistency5/5
Both tools follow the same predictable list_noun convention. There are no naming inconsistencies across the set.
Tool Count3/5
Two tools is thin for a server surface, and both only list identifiers rather than offering broader procedure/instruction interaction. The count is borderline rather than clearly wrong, but it feels under-scoped.
Completeness2/5
The surface only lists procedure and instruction IDs/URIs; there are no tools to actually read, fetch, or operate on a procedure or instruction. Descriptions imply later reading/requesting, but the tool set does not provide those operations, creating a significant dead end.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Serves your design system and coding standards to coding agents, so they stop guessing.
Create guides as MCP servers to instruct coding agents to use your software (library, API, etc).
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Read-only MCP server that answers questions about turva.dev from its published data. Five tools return JSON: the service catalog with prices, contact and operator details, engagement principles and dated agent-readiness and security evidence with verification links. Connect over Streamable HTTP. You need no API key. The server does not scan other websites or run audits.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables coding agents to search local repositories and retrieve bounded, cited source chunks, look up full indexed chunks, and inspect index statistics through read-only MCP tools over stdio.MIT
- AlicenseNot gradedqualityAmaintenanceEnables agents to read, navigate, and query long-term memory stored as readable, reviewable source files, exposing paged catalogs, indexed searches that explain their misses, bounded relation traces, link diagnostics, raw file access, and preflight checks of drafts against MUST constraints. It serves this read-only by default over stdio so any MCP client can start from a memory catalog and keep reading toward the answer instead of relying on a single similarity guess.1MIT
- AlicenseAqualityBmaintenanceEnables AI coding agents to consult a project's Git-versioned Markdown knowledge base over local stdio — checking knowledge health, listing the catalog, searching topics, and reading guides before acting. Access stays read-only, so project guidance, decisions, and lessons learned remain shared with human teammates and traceable beside the code.41MIT