A
licenseA
qualityD
maintenanceAn MCP server that gives coding agents instant insight into any Git repository — no guessing, no hallucination.
1
55
19
MIT
argot
by get-tmonier
Argot's server lets AI coding agents check code against a repo's own historical patterns and conventions, preventing AI-generated code that is syntactically valid but foreign to the codebase's style.
argot.check— Score a code hunk against the repo's "voice": determines if the code is out of voice, returns a score, identifies which rule fired (e.g.foreign-import,redundant,misplaced,layering,test-deleted), and provides evidence naming the surprising tokens.argot.explain— Get a detailed explanation of a hunk's voice score, including the full evidence trail with surprising tokens and their repo attestation counts (how many times each import/callee appears in the repo's history).argot.voice_context— Preemptively fetch the local voice context for a target file — typical callees per cluster and familiar imports — so an AI agent can bias its code generation toward the repo's idioms before writing the first token, rather than fixing violations after the fact.argot.fit_status— Check whether the repo is well-fitted for argot analysis, reporting corpus composition, calibration freshness, and an overall verdict (Ready / Ready-with-notes / Not-recommended).
Start with an audit
argot audit needs no prior Argot fit or configuration. It fits a historical
base in a temporary worktree, then evaluates the surviving base-to-HEAD net
diff. Your working tree is left untouched. It is a review prompt—not a census
of who wrote code, or proof that a finding is a defect.
# macOS / Linux
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.sh | sh
cd your-repository
argot auditWindows: powershell -c "irm https://github.com/get-tmonier/argot/releases/latest/download/argot-installer.ps1 | iex".
The npm package is also available as npm install -g @tmonier/argot.
Audit needs usable Git history and supported source. It has no fixed runtime promise. It runs fully offline — the code-embedding model behind the semantic findings ships inside the binary. See Getting started for install and fit details.
If the audit gives you a useful lead, fit the current repository and score the changes you intend to review:
argot init
argot checkReview and commit the generated argot.toml and .argot/ fit snapshot, then
merge it into the branch future PRs target before adding a CI workflow. Local
tools and CI then use the same learned baseline. CI only reads the base branch
snapshot; it never fits, so the initial snapshot PR must be separate from the
CI-workflow PR. argot status later recommends a local
fit-and-commit refresh only when accepted source, function, or layout surfaces
have materially changed. Commit count and age are not refresh triggers by
default; [fit] refresh-after is available only as an explicit team backstop.
The argot-refresh skill re-audits exclusions, structural paths, and mutes
before fitting, so a reorganized repository does not blindly relearn old scope.
flowchart LR
A["argot init<br/>learn locally"] --> B["review + commit<br/>argot.toml · .argot/"]
B --> C["local tools + CI<br/>read one baseline"]
C --> D{"material accepted drift?"}
D -- no --> C
D -- yes --> E["argot-refresh<br/>review scope · fit locally"]
E --> BThe embedding model itself ships inside the binary. Git stores only the repository-specific learned snapshot—typically a few MB to a few tens of MB—so every clone can reproduce the check without retraining or operating a service.
check reports patterns worth reviewing on the selected changeset; a clean result
does not prove the change correct or fully idiomatic. Read the
Audit,
Init and Fit, and
Check guides for the exact contracts.
Related MCP server: squire
What it surfaces
Type checkers ask if it compiles. argot asks if it’s yours. A clean, type-correct, well-reviewed pull request can still be foreign to the repository it lands in. These are the rules argot ships, every one of them learned from your own history rather than configured by hand:
Rule | Group | What it flags |
| voice | an import of a dependency the repo has never used |
| voice | a call to a receiver or callee the repo's code never calls |
| voice | a token sequence statistically foreign to the repo's voice |
| voice | a construction that breaks a convention learned from the repo |
| voice | a pattern this repo has been replacing, or declared migrated away |
| semantic | a new function that duplicates one the repo already has |
| semantic | a function that looks like it belongs in another module area |
| architecture | an internal import that reverses the repo's layer direction |
| integrity | a test removed while the code it exercised still exists |
| integrity | a skip marker added, or a test gutted, as production changes |
| integrity | assertions removed, tautologized, or loosened alongside a change |
| governance | a change that removes or weakens a locked rule |
Repositories add their own on top — a TOML manifest plus a sandboxed Rhai
script under .argot/rules/, with working ones to copy in
examples/rules/. No recompilation.
argot is a probabilistic review guardrail, not a correctness oracle. Each finding carries repository evidence. Treat it as a prompt to inspect and make the human decision explicit—never as proof that the code is wrong.
Choose how to run it
The CLI is the complete, explicit changeset check. Other routes have narrower triggers and coverage; none provides a universal acceptance-time check.
Route | Execution class | Prerequisites and coverage | Evidence status |
CLI | Invoked by a user or agent | Run | CLI/source inventory, 2026-07-22 |
Skills | Invoked | Seven on-demand workflows for a compatible skill host; installation does not schedule commands, configure MCP, or add a hook. | Manifest/source inventory, 2026-07-30 |
MCP | Passive | A configured client selects read-only context, hunk, or complete-changeset tools; a fitted repository is required for model-dependent tools. Fitting remains an explicit local CLI/skill workflow. | Focused test and source inspection, 2026-07-30 |
Claude Code plugin | Automatic when configured, plus invoked/passive surfaces | Its opt-in pre-write hook, in a fitted repository, asks only when a | Manifest/source inspection, 2026-07-22 |
pre-commit | Automatic when user-configured | Scores staged supported files in a fitted repository. The | Manifest inspection, 2026-07-22 |
GitHub Action | Automatic when user-configured | Scores the configured ref/range in a workflow; it needs checkout history and release-download access. | Action manifest inspection, 2026-07-22 |
Canonical setup and host details: Claude Code, other agents and MCP, and CI and pre-commit.
Evidence and limits
Current public measurements are detector-specific, not a product-wide accuracy or combined-brief claim. The approved claim manifest records:
visible foreign-symbol fixtures: 620/637 — 97.3% across 36 corpora and 12 languages;
reinvention fixtures: 545/584 — 93.3% across 31 corpora and 11 languages;
placement transplants: 12,899/13,456 — 95.9% across the 22 evaluable corpora and 11 languages (the other nine abstain because their layouts have no separable architecture);
layering fixtures: 264/272 — 97.1% across 25 corpora and 12 languages;
test-integrity fixtures: 154/164 — 93.9% across 23 corpora and 12 languages.
A catch rate means little without the noise it costs, so both are published. On the same 36 corpora, the voice detectors flag 0.25% of ordinary accepted edits — and 0.00% of the hunks in newly added files, where a repository has the least to say about what belongs.
Each number has a distinct corpus, denominator, and qualifier. The combined briefing/noise result and ordinary-repository timing are not yet measured public claims. See the benchmark methodology and sources.
Argot ships adapters for 12 languages. The five tested release targets are macOS arm64/x64, Linux x64/arm64, and Windows x64. The local analysis path uses statistical, graph, scripted, and embedding evidence; no generative or opinion-forming model decides a finding.
Fit health matters. A repository with shallow, generated, vendored, or otherwise unsuitable history may not produce a useful model. Argot is also least reliable for an incorrect choice made entirely with familiar vocabulary, masked prose, and code outside the selected range. Read Limitations before relying on a specific detector.
Reproducible authored proof
This is an authored fixture, not a wild-case corpus. Its pinned command, version, receipts, checksums, regeneration procedure, and the visual’s non-byte-stable GIF qualification are documented in the proof receipt. The image is a reproducible companion to the auditable Markdown receipt.
Privacy and open source
Argot analyzes source, history, and findings locally. The individual local core
is free, MIT-licensed open source, and requires no account or cloud service.
Argot has no default telemetry and does not upload source code. No analysis it
performs needs a network at all — the code-embedding model behind the semantic
findings is compiled into the binary. It can still use network paths for
update/version checks, release downloads, or an explicitly configured
review/update/CI integration. Set ARGOT_OFFLINE=1 to prevent network use;
nothing analytical is lost.
Read the complete privacy and security boundary, security policy, and MIT license.
Contribute
Contributions are welcome. Start with CONTRIBUTING.md, then see the product strategy for the maintained decision record and research log for evidence.
Acknowledgements
Every number argot publishes is measured against the real history of 36 open-source projects, across the twelve supported languages — fastapi, rich, faker, saleor, wagtail, scrapy, hono, ink, faker-js, excalidraw, outline, express, commander, eslint, gh-cli, hugo, ripgrep, bat, guava, junit5, powershell, jellyfin, redis, curl, rocksdb, fmt, homebrew, rubocop, laravel, composer, castle-engine, mORMot2, uos, ideU, MSEide/MSEgui, and dagster.
The benchmark would not exist without them, and we are grateful to their
maintainers and contributors. Argot vendors and redistributes none of their
code: the harness clones each repository at a pinned SHA, reads its history
locally, and ships nothing from it. Each project remains under its own license,
held by its own authors. Full list with links, and what argot does commit:
benchmarks/README.md.
argot does redistribute one thing. The model behind redundant and misplaced
is a 15.6M-parameter static table distilled from
jina-embeddings-v2-base-code
(Jina AI, Apache-2.0) using the
model2vec technique (MinishLab, MIT).
Its weights are compiled into the binary and redistributed under Apache-2.0;
full terms in NOTICE. argot is not affiliated with either project.
Available Tools
6 toolsargot.check_changesetARead-onlyIdempotent
Run Argot's complete configured detector pipeline over one selected changeset. Use this after editing when you need the same voice, semantic, architecture, integrity, and custom-rule findings as the CLI. Returns the stable check JSON, including findings, evidence, suppressions, and result counts. Read-only: it does not fit, mute, edit files, or update the last-check cache; requires a fitted repository.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| only | No | Optional repo-relative glob filters; inspect only matching paths. | |
| target | No | Changeset to inspect. worktree includes current tracked and untracked changes; staged and unstaged select one side of the index; range and commit require reference. | worktree |
| exclude | No | Optional repo-relative glob filters to omit from this invocation. | |
| reference | No | Git range such as main..HEAD when target=range, or commit SHA/ref when target=commit. | |
| min_confidence | No | Display filter only; rule severity still determines the check result. | unusual |
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details: 'it does not fit, mute, edit files, or update the last-check cache; requires a fitted repository.' This goes beyond annotations and clarifies side effects and prerequisites.
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 two sentences plus a brief note, all front-loaded with the most important information. Every sentence adds value: purpose, usage context, return type, and behavioral constraints. No wasted or redundant 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?
With 5 parameters all documented in schema and no output schema, the description covers the return value ('stable check JSON, including findings, evidence, suppressions, and result counts') and a critical prerequisite ('requires a fitted repository'). This is complete for an agent to understand input/output and constraints.
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 each parameter already has a description. The tool description adds no additional parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema does the work.
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 runs the complete detector pipeline over one changeset and returns check JSON. The verb 'check' is specific, and the phrase 'complete configured detector pipeline' and reference to CLI distinguish it from sibling tools like check_hunk.
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 this after editing when you need the same voice, semantic, architecture, integrity, and custom-rule findings as the CLI.' It also clarifies what it does not do (fit, mute, edit files, update cache), providing when-not-to-use guidance. It does not name alternatives directly but the context and tone imply it's for full pipeline checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
argot.check_hunkARead-onlyIdempotent
Score one supplied code hunk with Argot's fast fitted voice model. Use while drafting or for an isolated snippet when no Git changeset exists. Returns out_of_voice, score, threshold, rule, and concise evidence; it does not run semantic, architecture, integrity, or custom rules. For a real change, prefer check_changeset. Read-only; requires a fitted repository.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Repo-relative path of the file the hunk belongs to. Its extension selects the language and that language's model (e.g. `.py`→Python, `.ts`→TypeScript, `.rs`→Rust); an unsupported extension yields no score. | |
| file_source | No | Optional: the full current text of the file. Provide it so argot can resolve callees against the surrounding code (more accurate when the hunk references names defined elsewhere in the file); omit it and the hunk is scored in isolation. | |
| hunk_content | Yes | The changed code to score — the added/edited lines, not the whole file. A few lines is enough; argot scores the hunk, not the file. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: return fields, exclusions, prerequisite (fitted repository). No contradiction with 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?
Three sentences: purpose, usage, output/exclusions. No wasted words, front-loaded with key information.
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?
Describes returns adequately given no output schema. Mentions limitations and prerequisites. Slightly lacking in return type detail, but sufficient for a simple read-only tool.
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 is 100% with detailed descriptions. The tool description does not add new info about parameters beyond what schema provides, so baseline 3.
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 action (score), resource (code hunk), and model (fast fitted voice). Distinguishes from sibling check_changeset by noting preference for real changes.
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 says when to use: 'while drafting or for an isolated snippet when no Git changeset exists.' Also states exclusions (no semantic/integrity rules) and alternative (check_changeset).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
argot.explain_hunkARead-onlyIdempotent
Explain one hunk-level voice result with untruncated structured evidence, including surprising identifiers and attestation counts. Use as a follow-up when check_hunk flags or nearly flags a snippet; do not use it as a second independent check. It covers the fitted voice model only. Read-only; requires a fitted repository.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Repo-relative path of the file the hunk belongs to. Its extension selects the language and that language's model (e.g. `.py`→Python, `.ts`→TypeScript, `.rs`→Rust); an unsupported extension yields no score. | |
| file_source | No | Optional: the full current text of the file. Provide it so argot can resolve callees against the surrounding code (more accurate when the hunk references names defined elsewhere in the file); omit it and the hunk is scored in isolation. | |
| hunk_content | Yes | The changed code to score — the added/edited lines, not the whole file. A few lines is enough; argot scores the hunk, not the file. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'requires a fitted repository' and 'untruncated structured evidence', which provides useful context beyond annotations. No contradiction.
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 main sentences plus one supplementary. Front-loaded with key purpose and usage. Every sentence is essential and informative. No redundancy.
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?
Covers purpose, parameters, behavior (read-only, requires fitted repo), and usage context. Lacks explicit description of return values, but the description mentions 'untruncated structured evidence, including surprising identifiers and attestation counts' which gives adequate expectation for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable context: explains that file_path extension selects language model, file_source is optional to improve accuracy, and hunk_content should be only the changed lines. This adds meaning beyond what the schema descriptions provide.
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 explicitly states the verb 'explain', the resource 'hunk-level voice result', and what it produces ('untruncated structured evidence, including surprising identifiers and attestation counts'). It distinguishes from siblings by specifying it's a follow-up when check_hunk flags or nearly flags a snippet, and covers the fitted voice model only.
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?
Clear guidance: 'Use as a follow-up when check_hunk flags or nearly flags a snippet; do not use it as a second independent check.' Also states 'It covers the fitted voice model only' and 'Read-only; requires a fitted repository.' Provides when to use and when not to use, with prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
argot.get_fit_statusARead-onlyIdempotent
Get repository readiness before using learned tools: fit suitability, committed-snapshot completeness, configuration compatibility, and the adaptive refresh recommendation with structured reasons and next_action. This tool diagnoses setup and maintenance only; it never fits or writes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.3/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool only diagnoses and never fits or writes, which is consistent. It also mentions 'structured reasons and next_action' in output, but beyond that, no new behavioral traits are 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?
Two sentences, front-loaded with key purpose, no fluff. Efficiently covers tool scope, output, and boundaries.
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 0 parameters, comprehensive annotations, and no output schema, the description fully explains what the tool does and its diagnostic role. It mentions output format and exclusion of mutations, which is sufficient for this simple 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?
The tool has 0 parameters with 100% schema coverage (empty). The description adds value by describing what the tool returns (structured reasons, next_action), which is unnecessary but helpful. Baseline for 0 params is 4.
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 gets 'repository readiness' and lists specific aspects (fit suitability, completeness, configuration compatibility, adaptive refresh recommendation). It also explicitly says what it does not do ('diagnoses setup and maintenance only; it never fits or writes'), distinguishing it from sibling tools like check_changeset or check_hunk.
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 says to use 'before using learned tools,' which provides clear context. It also states it 'diagnoses setup and maintenance only,' implying when not to use for fitting/writing. However, no explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
argot.get_voice_contextARead-onlyIdempotent
Get the repository vocabulary relevant to a file before writing: typical callees, familiar imports, and active replacement guidance for the file's language. This is generation context, not a verdict about code and not a changeset check. Read-only; requires a fitted repository.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | How many typical callees to return per cluster (default 10). Raise for a fuller picture, lower to keep the injected context small. | |
| file_path | Yes | Repo-relative path of the file you're about to create or edit. Its extension selects the language; the returned voice is that language's typical callees and familiar imports. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description adds that it is read-only and requires a fitted repository, providing context beyond annotations without contradiction.
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 two concise sentences plus a note, front-loading the main purpose and efficiently conveying critical information without extraneous content.
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 simple parameter set (2 params, no output schema) and rich annotations, the description adequately explains the tool's behavior and return values. It could elaborate on 'active replacement guidance,' but is largely complete.
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 is 100% and both parameters have descriptions. The tool description mentions that file_path's extension selects the language, adding slight context, but overall doesn't significantly extend beyond the schema's parameter descriptions.
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 retrieves repository vocabulary relevant to a file (typical callees, imports, replacement guidance) and distinguishes it from being a code verdict or changeset check, differentiating it from sibling tools like argot.check_changeset.
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 indicates use 'before writing' and clarifies it is 'generation context, not a verdict about code and not a changeset check,' implying appropriate usage scenarios. It also notes it requires a fitted repository, though explicit when-not-to-use and alternatives are not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
argot.list_conventionsARead-onlyIdempotent
List conventions learned from the repository: internal API vocabulary, placement concentrations, and migrations still in progress. Use this to discover candidate team conventions or understand where code belongs; it does not evaluate a change. Read-only; requires a fitted repository.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it requires a fitted repository, which is valuable behavioral context beyond 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?
Two concise sentences with no wasted words. The key information is 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?
Given zero parameters and no output schema, the description adequately covers the tool's purpose, usage, and requirements. It could mention what the output looks like, but is complete enough.
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 description cannot add meaning beyond the input schema. Baseline 4 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 verb 'List' and the resource 'conventions learned from the repository', specifying the types of conventions (vocabulary, concentrations, migrations). It differentiates from siblings which focus on checking changes.
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?
It tells the agent when to use the tool: 'discover candidate team conventions or understand where code belongs'. It also explicitly states what it does not do: 'does not evaluate a change'. This provides clear guidance without naming alternatives, but 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.
TDQS
A4.5/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: changeset analysis, hunk analysis, explanation, context retrieval, status check, and convention listing. No overlap exists.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, such as check_changeset, explain_hunk, and list_conventions.
Tool Count5/5
With 6 tools, the server is well-scoped for code analysis and generation context, covering the main workflows without unnecessary duplication.
Completeness4/5
The tools cover the core analysis and context needs, but lack write operations like fitting or muting findings, which may require external tools.
Maintenance
ActivityActive
ResponsivenessResponsive
Related MCP Connectors
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
An MCP server that gives your AI access to the source code and docs of all public github repos
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceRuntime safety guardrails for AI coding agents. Checks file access, validates shell commands, and scores your repo's AI safety — all via MCP.58MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first MCP server that provides project context, verification gates, and structured tools for coding agents to discover knowledge, run diagnostics, and execute allowlisted commands within a repository.35MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/get-tmonier/argot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server