nittim

by com.nittim

Overview Discussions Admin

Server Details

Production-safety audits for AI-generated code, with a fix for every finding.

Ownership verified

Status: Healthy
Uptime: 100.0% over 21 days
Last Tested: 2026-09-25 14:50
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: ilanwolberger/nittim-mcp
GitHub Stars: 0
Server Listing: nittim

TDQS

A4.2/5.0

Scored 2026-09-07 15:05 across 15 tools

Disambiguation5/5

Each tool targets a distinct resource and action: repo audits vs source uploads vs single modules vs free scanners vs pre-flight pricing vs post-audit verification are clearly separated. The overlapping payment protocol is spelled out identically, but the tool purposes themselves do not collide.

Naming Consistency5/5

Every tool uses a consistent snake_case verb_noun pattern (audit_repo, estimate_audit, get_audit, run_module, verify_fix, etc.). No camelCase or mixed verb styles; the naming makes the action and object predictable.

Tool Count5/5

15 tools is at the upper end of the typical range but each one maps to a distinct stage of the service: pricing, approval, auditing, retrieval, dispute, module listing, key minting, loop reporting, and free scanning. The count reflects the real complexity of a paid, async audit workflow rather than bloat.

Completeness4/5

The core audit lifecycle is well covered: estimate, preview/approve, run full or single-module audits, retrieve results, verify fixes, and dispute findings. Minor gaps exist such as no list_audits endpoint to enumerate past audits and no explicit credit-balance tool, but agents can work around these via get_audit and the signed-in estimate_audit response.

Available Tools

15 tools

audit_repoAudit a GitHub RepositoryAInspect

Paid nittim AI audit of a GitHub repository: one structured pass over the highest-signal source; the only tool here that returns scores and a verdict. Answers with the audit's id, not the report. fullScan: true buys the wider Full Audit tier. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY in three calls: the first quotes a price and charges nothing; a second with confirmedCost set to that exact price returns a one-time link for the ACCOUNT OWNER to confirm — their yes, not the assistant's; a plain third call with the same arguments runs once at that price. A moved price is re-quoted, never charged.DELIVERED AS A BATCH: the report lands Usually within 15 minutes*. * Most reports land within 15 minutes. Worst case, 24 hours.

ParametersJSON Schema

Name	Required	Description
`repoUrl`	Yes	GitHub repository URL or owner/repo. A private repo needs a githubToken.
`fullScan`	No	True buys the wider Full Audit tier: every eligible source file, priced by pass count.
`payInstead`	No	True pays credits now instead of queuing for the daily free-audit budget to reopen, skipping the covered (Audit) entitlement even when it would otherwise be free.
`deployedUrl`	No	Optional URL of this repository's live deployment, for an origin the account owner actually operates. When set, the audit adds one bounded, READ-ONLY fetch pass against it and reports drift between the deployed artifact and the audited commit. Redirects are never followed; private addresses are refused.
`githubToken`	No	Optional read-only GitHub token. Without one, only public repos are reachable.
`authorization`	No	HUMAN CONFIRMATION. The `authorization` id from the confirm-link answer, once the account owner has pressed Confirm. Single-use, short TTL.
`confirmedCost`	No	COST CONFIRMATION. Omit on the first call; then send back the exact quoted `cost`.

TDQS

A4.4/5.0

Behavior5/5

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

The description fully discloses the tool's side effects: it costs money, requires a key, involves a three-call confirmation flow, returns an id rather than a report, and may take up to 24 hours. It also details the optional read-only deployment fetch behavior and single-use authorization, going well beyond the minimal annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly verbose and repetitive, with multiple sections re-explaining the cost, key, and delivery times in different words (e.g., 'COSTS MONEY' and 'DELIVERED AS A BATCH'). It contains marketing-like phrases and redundant details, making it longer than necessary and less scannable.

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 complexity of the tool (payment, confirmation, tokens, optional deployment fetch), the description covers the essential flow, required inputs, and expected outcomes (returns an audit id). It lacks an output schema, but the description provides enough context for an agent to call it and interpret the immediate response.

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?

All seven parameters are described in the schema (100% coverage) and the description adds extra context, such as the need for a githubToken for private repos and the exact meaning of confirmedCost. The description also clarifies the cost-flow and provides usage nuances for payInstead and deployedUrl.

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 that this tool performs a paid AI audit of a GitHub repository, returns scores and a verdict, and is the only tool here that does so. It also specifies that the response is an audit id, not the full report, which sets it apart from sibling tools.

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 explains when to use this tool (for a paid audit with scoring/verdict) and differentiates it from siblings by noting it is the only one that returns scores. It also outlines the multi-call cost-confirmation flow and optional parameters like fullScan, but does not explicitly say 'use this instead of X' beyond the 'only tool' statement.

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

audit_sourceAudit Posted Source (no GitHub repo required)AInspect

Paid nittim AI audit of source files you post, for a project with no GitHub remote. Send SOURCE files, not build output — no node_modules or dist. On nittim's own key this answers with the audit's id; the report lands Usually within 15 minutes*. * Most reports land within 15 minutes. Worst case, 24 hours. On your own key (BYOK Pro) the report comes back in this call instead. Costs 5.14 credits (a paid+subscribed org's included allowance, an unspent Audit, then prepaid credits), always saved as a PRIVATE report. fullScan: true buys the wider Full Audit tier. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY in three calls: the first quotes a price and charges nothing; a second with confirmedCost set to that exact price returns a one-time link for the ACCOUNT OWNER to confirm — their yes, not the assistant's; a plain third call with the same arguments runs once at that price. A moved price is re-quoted, never charged.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	A display label for this project, e.g. 'my-abacus-app'. Sanitized before use.
`files`	Yes	Source files as { path, content }[] — not build output. At most 1000; over the internal per-audit cap, the highest-priority ones win.
`fullScan`	No	True buys the wider Full Audit tier over the files you post, priced by pass count.
`uploadGrant`	No	Optional: the id of an upload approval the account owner already confirmed. A large post without one is answered with a confirmation covering the files and the price.
`authorization`	No	HUMAN CONFIRMATION. The `authorization` id from the confirm-link answer, once the account owner has pressed Confirm. Single-use, short TTL.
`confirmedCost`	No	COST CONFIRMATION. Omit on the first call; then send back the exact quoted `cost`.

TDQS

A4.9/5.0

Behavior5/5

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

The description fully discloses that the tool costs money, requires human confirmation, saves reports as private, and has a multi-call confirmation workflow. It also clearly explains that prices are re-quoted if changed and never charged without owner confirmation, matching the non-read-only, non-idempotent annotation.

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 dense and well-structured but somewhat repetitive, especially around cost and the three-call flow, which are explained twice. The key operational details are front-loaded and important, but trimming redundant payment explanations would improve conciseness.

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 the complexity of the payment and confirmation workflow and the absence of an output schema, the description provides sufficient context: it explains the three-call sequence, key requirement, price confirmation, fullScan option, privacy of reports, and what the caller receives. No critical operational detail seems missing.

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?

The schema already covers all parameters, and the description adds valuable semantics beyond the schema, including sanitization of the name, path restrictions, rejection of encodings other than utf8, the cap on files, and the exact role of confirmedCost and authorization in the payment flow.

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 title and description clearly state the tool performs a paid AI audit of posted source files, specifically for projects without a GitHub remote. It distinguishes itself from repo-based or scanning siblings by emphasizing 'no GitHub repo' and 'source files, not build output.'

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 concrete guidance on when to use the tool, what file types are acceptable, the need for an API key, the three-call payment flow, and the optional fullScan tier. It also explicitly instructs users to omit confirmedCost on the first call and echo back the exact quoted cost afterward.

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

describe_protocolHow This Server's Protocol WorksA

Read-onlyIdempotent

Inspect

How this server works, in full: how a paid call quotes and charges, the two audit tiers, the Nittim Loop and its reward rules and caps, and dispute guidance. Free, no key, no charge, no side effects — it reads static text and calls no model. section picks one page; omitted, it returns all of them.

ParametersJSON Schema

Name	Required	Description	Default
`section`	No	Which page: money, tiers, loop, disputes, or all (the default).

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description explicitly states that the tool is free, requires no key, has no charge, has no side effects, reads static text, and calls no model. This gives the agent strong confidence about safety and cost before invoking it.

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 compact and front-loaded, with no filler or redundant content. Each sentence carries useful information: the purpose, the safety/cost profile, and the parameter behavior.

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?

For a simple, read-only documentation tool with one optional enum parameter and no output schema, the description provides complete context. The agent knows what the tool covers, how to select content, what happens by default, and that invocation has no side effects or cost.

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?

The schema already provides 100% coverage with an enum and per-value description, and the description adds the key behavioral detail that section picks one page while omitting it returns all pages. The single parameter is fully explained.

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 that the tool explains how this server's protocol works, covering billing, audit tiers, the Nittim Loop, and disputes. It is immediately distinguishable from the sibling tools by being a documentation/reference tool rather than an operational or audit action.

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 explains what the tool does and explicitly notes that it is free, requires no key, has no charge, and has no side effects because it reads static text and calls no model. It also tells the user how to choose a section and what happens when section is omitted.

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

dispute_findingDispute or Confirm a FindingAInspect

NEEDS A KEY: mint one at https://nittim.com/keys. Records that a finding from a prior audit is wrong (stance:'dispute') or genuinely real (stance:'confirm'), backed by evidence from the repo. Free. A SIGNAL for owner triage — it never changes the audit's scores, verdict or stored report on its own. The finding is identified by its findingKey (from the digest), or by its exact dimension and title.

ParametersJSON Schema

Name	Required	Description
`title`	No	The finding's exact title — required if findingKey is omitted.
`stance`	Yes	'dispute' = this finding is wrong. 'confirm' = this finding is genuinely real.
`auditId`	Yes	The audit UUID, from its report link.
`evidence`	Yes	What you can see in the repo that supports your stance.
`dimension`	No	The finding's dimension, e.g. 'security' — required if findingKey is omitted.
`findingKey`	No	The finding's stable key from the digest, if you have it (preferred over dimension+title).

TDQS

A4.1/5.0

Behavior3/5

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

The description states the primary effect (recording a signal) and explicitly says it never changes the audit's scores, verdict, or stored report, which aligns with the non-destructive annotation. It does not address idempotency, duplicate handling, or side effects like notifications, and the key requirement is mentioned without detail on validation or failure behavior.

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 compact, with three sentences each covering distinct aspects: key requirement, core purpose, and non-modifying nature. The all-caps and URL add mild noise, but overall it is efficiently structured.

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 (required key, finding identification methods, nested evidence), the description covers prerequisites, identification, and effect. It does not specify the response or output, but since no output schema exists, this is acceptable. It is sufficiently complete for an agent to decide when and how 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?

Schema descriptions already cover parameters well, and the description adds meaningful context: findingKey is preferred over dimension+title, 'from the digest' clarifies provenance, and evidence is tied to the repo. This goes beyond a mere restatement of 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 states precisely what the tool does: it records a dispute or confirmation of a prior audit finding, backed by repo evidence. It clearly identifies the two stances and the object (finding), distinguishing it from sibling tools like verify_fix or report_loop.

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 user they need a key and where to mint one, and explains that the tool is a signal for owner triage, not a modifier of the audit. It also clarifies how to identify the finding (findingKey or dimension+title). However, it does not explicitly contrast with alternatives, though the use case is inherently distinct.

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

estimate_auditEstimate an Audit's Price — No Upload RequiredA

Read-onlyIdempotent

Inspect

Price an audit before buying one: give a GitHub repository URL, or a manifest of paths and byte sizes — no file content, nothing uploaded — and get the tier (Audit or Full Audit), the pass count and the exact price. No account or key is needed: it never charges, runs no audit, calls no model and stores nothing. Signed in it also returns your credit balance and whether an unspent Audit covers the run; a guest quote omits both. fullScan: true prices Full Audit.

ParametersJSON Schema

Name	Required	Description
`files`	No	A manifest of paths and sizes only, in place of `repoUrl` — the same set you would post. Over the cap the answer names it and how to trim. Send one or the other.
`repoUrl`	No	GitHub repository URL or owner/repo. Mutually exclusive with `files` — send one.
`fullScan`	No	Price Full Audit (every eligible file, or a refusal with the reason when the selection is too large) instead of the default Audit.
`githubToken`	No	Optional GitHub personal access token (read-only) for a private repo.

TDQS

A4.9/5.0

Behavior5/5

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

The description explicitly discloses that no charge occurs, no audit runs, no model is called, and nothing is stored. It also explains the difference for signed-in users (credit balance and coverage) and what happens over the cap, going well beyond the readOnlyHint annotation.

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 front-loaded with the main purpose and uses compact sentences. There is some repetition of the 'no upload' theme across the title and description, but it is not excessive and reinforces a key differentiator.

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 there is no output schema, the description sufficiently describes what the caller will receive: tier, pass count, exact price, credit balance, coverage, and refusal reason when applicable. It also covers input constraints and error-trimming guidance, making the tool well-rounded for an agent.

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?

The input schema is fully described: files are a manifest of paths and sizes only, repoUrl is mutually exclusive with files, fullScan switches to Full Audit pricing, and githubToken is optional and read-only. The description adds practical details such as 'Over the cap the answer names it and how to trim.'

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: 'Price an audit before buying one.' It also distinguishes itself from audit/upload tools by emphasizing 'no file content, nothing uploaded' and 'never charges, runs no audit, calls no model and stores nothing.'

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?

It explains exactly when to use the tool: when you need a price estimate before purchasing an audit, and it clarifies the two input modes (repo URL or manifest), the optional token, and the fullScan flag. The 'before buying one' framing and 'no upload' emphasis naturally guide against using audit or upload siblings.

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

get_auditFetch a Saved AuditA

Read-onlyIdempotent

Inspect

Retrieve a nittim audit by its UUID, at any stage: the finished markdown digest (verdict, scores, top findings) plus its report link, or — no error, nothing charged — that it is still running, or why it failed and what happened to the charge. Free. Reading needs the key of the account that owns the audit.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The UUID of the saved audit, from the /report/{id} URL.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only and idempotent. Description adds: free (no charge), three possible outcomes (finished, running, failed) with no error, and auth requirement (key of owning account). This goes beyond annotations to clarify behavior.

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 sentences, each adding value: first explains the action and possible outcomes, second covers cost and auth. Front-loaded with the primary purpose.

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?

For a single-parameter read tool with annotations covering safety, the description covers outcome variations, cost, and auth. No output schema, so return details are inferred from the description. Complete for correct invocation.

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 schema describes id as UUID from /report/{id} URL. Description only says 'by its UUID' which adds no extra meaning beyond 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?

States a specific verb 'Retrieve' and resource 'a nittim audit' by UUID, and distinguishes from siblings by specifying it retrieves an audit (not a loop or report). Mentions stages (finished, running, failed) making it clear.

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?

Provides clear context: use to retrieve an audit at any stage, free, requires owner key. Does not explicitly name alternatives or when-not to use, 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.

get_loopRead the Nittim Loop ChecklistA

Read-onlyIdempotent

Inspect

Returns the current text of nittim's free, tool-agnostic self-review checklist — the same content served at https://nittim.com/selfcheck.md. Reviews a codebase against the public shape of nittim's 13-category Priority Framework, plus a 14th on what the code gives away, and states the procedure for running it as a loop. No arguments. No key, no account and no charge — nothing here is sent anywhere.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond those: the content is identical to a public URL, the tool is free, requires no account, and 'nothing here is sent anywhere' — a concrete privacy guarantee not captured by the 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, each carrying distinct information: what is returned, what the checklist contains, and operational guarantees. The most important fact is front-loaded, and there is no filler or repetition of schema/annotation data.

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?

For a zero-argument read-only tool with no output schema, the description covers the return value, content, procedure, cost, authentication, and data privacy. 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameters and 100% schema coverage, the baseline is already 4. The description reinforces this with 'No arguments' and additionally clarifies that no key or account is needed, leaving zero ambiguity about invocation requirements.

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 states a specific verb and resource: 'Returns the current text of nittim's free, tool-agnostic self-review checklist.' It also details the checklist's content (13-category Priority Framework plus a 14th category) and its loop procedure, making it unmistakable among siblings like get_audit or report_loop.

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 'No arguments. No key, no account and no charge — nothing here is sent anywhere,' which establishes clear usage context and no prerequisites. It does not explicitly name alternative tools or when-not-to-use conditions, so it falls just short of a 5.

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

judge_outputJudge Arbitrary Output (independent cross-vendor model)AInspect

Run a cross-vendor judge model over any text you post: code, a document, another model's output, anything. Returns findings + rationale ONLY — never a score, never a pass/fail verdict. Costs 5.03 credits. The judge always comes from a different vendor family than whatever produced the content, and the answer says which one ran. modelUnderTest names that family. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY in three calls: the first quotes a price and charges nothing; a second with confirmedCost set to that exact price returns a one-time link for the ACCOUNT OWNER to confirm — their yes, not the assistant's; a plain third call with the same arguments runs once at that price. A moved price is re-quoted, never charged.

ParametersJSON Schema

Name	Required	Description
`content`	Yes	The text to judge — code, a document, another model's output. Up to ~100KB.
`context`	No	Optional — background the judge should know, e.g. what this content is for.
`criteria`	No	Optional — what to judge it against, e.g. 'correctness and security'.
`authorization`	No	HUMAN CONFIRMATION. The `authorization` id from the confirm-link answer, once the account owner has pressed Confirm. Single-use, short TTL.
`confirmedCost`	No	COST CONFIRMATION. Omit on the first call; then send back the exact quoted `cost`.
`modelUnderTest`	No	Optional — which vendor family produced `content`, if it is itself a model's output. The judge that runs is always a different family than this names. Use 'unspecified' for anything that is not model output, or when the family is unknown.

TDQS

A4.9/5.0

Behavior5/5

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

The description fully discloses the multi-call, cost-confirming, human-authorization behavior, including that the first call charges nothing, the third runs once at the quoted price, and the authorization is single-use with a short TTL. This goes well beyond the annotations and accurately reflects the side-effecting nature.

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 well-structured and front-loaded with the core purpose, but it is somewhat repetitive (e.g., 'never a score, never a pass/fail verdict' repeated, and the cost flow spelled out twice in different words). Still, the multi-step cost flow justifies the extra detail.

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 the tool has no output schema, the description usefully states the return shape (findings + rationale only). It also covers prerequisites, cost confirmation, authorization, and vendor-family selection, making the tool usable without external documentation.

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 description coverage is 100%, and each parameter carries meaningful guidance: content limits, optional context/criteria roles, confirmedCost usage, authorization human-confirmation semantics, and modelUnderTest vendor-family behavior. The descriptions add practical usage context beyond the JSON 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 runs a cross-vendor judge model over arbitrary text and returns findings and rationale, never a score or pass/fail verdict. This distinguishes it from sibling audit/scan/verify tools, which evaluate with verdicts or structured findings.

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 usage guidance: first call quotes a price, second call confirms cost with the authorization id, third call runs the judge. It also explains the prerequisite of minting a key at the provided URL and clarifies that the judge always comes from a different vendor family than the content producer.

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

list_modulesList nittim Audit ModulesA

Read-onlyIdempotent

Inspect

List every audit module nittim can run: the two deterministic scanners (secret scan + OSV dependency CVE check) and the LLM-reasoned checks. Returns each module's key, tier, and a plain-English description of what it checks. Each module's key identifies it for running individually.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying exactly what the tool returns, including the plain-English description of each module, which goes beyond the bare annotation metadata.

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 convey the full scope, the returned fields, and the follow-up usage of the keys without any filler. The most important information is front-loaded.

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?

For a parameterless listing tool with read-only annotations, the description fully equips an agent to select and call it correctly. It explains what modules are included, what the response contains, and how the returned keys relate to running a module individually.

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 zero parameters, so there is no parameter semantics to document. The description appropriately focuses on the output and the purpose of the returned keys, which is all that is needed here.

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 uses a specific verb ('List') and resource ('audit modules nittim can run'), then enumerates the module categories and the exact returned fields (key, tier, plain-English description). This clearly distinguishes it from run_module and other siblings that execute or manage audits.

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 statement 'Each module's key identifies it for running individually' implies this tool is the discovery step before run_module, giving clear context for when to use it. It does not explicitly name alternatives or say when not to use it, but the intended use is clear for a zero-parameter listing tool.

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

mint_keyGet a One-Time Link to Mint a nittim KeyAInspect

For a client that cannot sign in over OAuth: a short, one-time link to https://nittim.com/keys/claim/. Opening it, signed in, mints a real nittim API key and shows it once — the key itself is NEVER returned by this tool or by any other MCP result. The link expires in a few minutes and works exactly once. Free.

ParametersJSON Schema

Name	Required	Description	Default
`keyName`	No	Optional display name for the key that will be minted, e.g. 'my-cursor-key'. Defaults to 'API key'.

TDQS

A4.3/5.0

Behavior5/5

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

Describes the full side-effect chain: opening the link mints a real key, displays it once, expires in minutes, and works only once. Clearly states the key is never returned by any MCP result, preventing misuse.

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?

Three compact sentences convey purpose, usage condition, and behavior. The word 'Free' is mildly extraneous but does not bloat the description. Information is front-loaded with the primary use case.

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 simple link-generating tool with no output schema, it explains the workflow, security characteristics, and the notable fact that the key is not returned. Enough context for an agent to decide when to invoke it and what to expect.

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 single optional parameter keyName is fully documented in the schema with a clear description and default value. The tool description adds no additional meaning beyond the schema, so baseline score applies.

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?

Clear statement that the tool provides a one-time link for clients unable to use OAuth, with the specific purpose of minting a nittim API key. Unambiguously differentiates from sibling tools which handle audits, modules, and reports.

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 scopes usage to clients that cannot sign in over OAuth, implying the alternative path. Clarifies that the key itself is never returned and the link expires quickly, guiding agent expectations about when and how to use the tool.

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

preview_uploadPreview an Upload Before Any Source Leaves the MachineBInspect

NEEDS A KEY: mint one at https://nittim.com/keys. Send the paths and sizes of the files you would post — no content leaves your machine to ask this — and get back the list, the byte count, and a link for the account owner to approve it. Free. The approval covers that file list and no other, and a paid audit's own confirmation already covers the file list beside the price, so approving ahead of time is optional.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	A display label for this project, e.g. 'my-abacus-app'. Sanitized before use.
`files`	Yes	Paths and sizes only — the same set you would post. Never file content.

TDQS

B3.2/5.0

Behavior3/5

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

The description discloses that only paths and sizes are sent, that no content leaves the machine, and that a link is returned for owner approval. However, it does not clarify whether this creates server-side state despite readOnlyHint=false, and the repeated approval/audit wording is confusing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose and repetitive, especially the trailing sentences about approval coverage and paid audits. Key information is buried in promotional phrasing, making it harder to parse quickly.

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?

There is no output schema and the description only vaguely lists 'the list, byte count, and link.' It also omits how the required key is transmitted, which is essential for actually invoking the 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?

Both parameters are described with meaningful constraints: name is a sanitized display label and files is explicitly limited to paths and byte counts, never content. This goes beyond the bare schema and clarifies the no-content promise.

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?

Clearly names the operation as previewing an upload before source/content leaves the machine and specifies the resource (the file set). It is distinguishable from sibling audit/scan tools by focusing on upload preview and approval.

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?

The description explains that it requires a key and should be used before posting files, but it does not explicitly contrast it with alternatives or explain when not to use it. It also fails to say how the key is supplied.

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

report_loopReport a Completed Nittim Loop (opt-in, counts only)AInspect

NEEDS A KEY: mint one at https://nittim.com/keys. Records anonymised counts from a Nittim Loop the developer has finished and agreed to send: pass numbers, a findings-by-category tally, a fixed count, and whether each pass was clean. Counts only — never a title, file path or snippet. Nothing is charged, and an eligible report can earn a credit reward (rules and caps: see describe_protocol). Reporting the same repo again updates the existing record; the reply says which happened. Results appear at https://nittim.com/loop.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Optional: 'one_shot' (every lens sweeps the whole tree first, then one fix wave, then a short convergence loop) or 'serial' (one lens or area per pass, fixing between passes).
`swept`	No	Optional: was the CLASS swept — a guard, lint rule or exhaustiveness check that makes a new instance loud — rather than only the instances a pass named? Never derived, never changes the reward. On a repeat report, omitting it keeps the last answer; `false` withdraws it.
`passes`	Yes	One entry per pass you actually ran, in order.
`repo_hash`	Yes	sha256 of the repository's canonical identity (the lowercased 'owner/repo', or a stable local fingerprint) — never the repo name itself. nittim never sees the name.
`client_name`	No	Your own name — omit to read it from the MCP connection instead.
`convergence`	No	Optional: 'converged' (two consecutive clean passes) or 'cap_reached' (stopped for any other reason). Omit if unsure — the read from `passes` is derived either way.
`client_version`	No	Your own version string, if you have one.
`repo_size_bucket`	Yes	A rough size bucket for the repo you looped over.
`first_wave_lenses`	No	Optional, with mode 'one_shot' only: how many lenses ran in parallel on pass 1.

TDQS

A4.5/5.0

Behavior5/5

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

The description discloses key side effects beyond the annotations: recording counts, never storing titles/paths/snippets, no charges, potential credit rewards, and that repeated reports update the existing record. It also mentions where results appear. The annotations (readOnlyHint false, destructiveHint false) are consistent with this write-but-non-destructive behavior.

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 well-structured with a clear flow: key requirement, what is recorded, what is excluded, charging and rewards, update behavior, and result URL. It is front-loaded with the most critical information (key need) and remains concise without unnecessary elaboration.

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?

For a complex tool with 9 parameters and nested objects, the description provides essential context: the opt-in nature, counts-only policy, update semantics, and the external URL for results. It explains the overall purpose and constraints sufficiently for an agent to decide when and how to invoke it, even without an output schema.

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 provides 100% coverage with detailed descriptions for all parameters, including enums, constraints, and defaults. The description itself does not add significant parameter-specific meaning beyond stating the overall purpose (counts only). Thus, it meets but does not exceed the baseline for fully documented schemas.

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 title and description clearly state the verb 'report', the resource 'completed Nittim Loop', and the scope (counts only, opt-in). It distinguishes the action from reading or auditing by focusing on reporting anonymised counts. The purpose is unambiguous.

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 states when to use the tool: after finishing a Nittim Loop and agreeing to send counts. It also explains the update behavior for repeated reports. However, it does not explicitly contrast with alternative tools (e.g., get_loop, describe_protocol) or state when not to use it, leaving some inference to the agent.

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

run_moduleRun a Single Audit ModuleAInspect

Run ONE nittim audit module against a GitHub repository, never producing scores or a verdict. The two deterministic modules (secret-scan, dependency-cve) return scanner evidence directly, free, with nothing to confirm. Deep-tier modules make one focused model call, cost 5.03 credits each and follow the protocol below. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY in three calls: the first quotes a price and charges nothing; a second with confirmedCost set to that exact price returns a one-time link for the ACCOUNT OWNER to confirm — their yes, not the assistant's; a plain third call with the same arguments runs once at that price. A moved price is re-quoted, never charged.

ParametersJSON Schema

Name	Required	Description
`repoUrl`	Yes	GitHub repository URL or owner/repo. A private repo needs a githubToken.
`moduleKey`	Yes	The module's key, e.g. 'secret-scan', 'dependency-cve', 'security', 'privacy', 'gdpr'.
`githubToken`	No	Optional read-only GitHub token. Without one, only public repos are reachable.
`authorization`	No	HUMAN CONFIRMATION. The `authorization` id from the confirm-link answer, once the account owner has pressed Confirm. Single-use, short TTL.
`confirmedCost`	No	COST CONFIRMATION. Omit on the first call; then send back the exact quoted `cost`.

TDQS

A4.4/5.0

Behavior5/5

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

Thoroughly discloses side effects and prerequisites: requires an API key, can charge credits, first call quotes a price, second call confirms with a human-owned link, third call actually runs. This goes well beyond the annotations and gives an agent a realistic picture of multi-call, cost-bearing behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but repetitive, especially the COSTS MONEY section which restates the three-call flow after already explaining deep-tier costs. The ALL-CAPS emphasis and repeated clauses make it longer than necessary, though the content is relevant.

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 prerequisites, cost behavior, human confirmation, and private-repo token needs. There is no output schema and the description does not describe the final successful response shape beyond 'scanner evidence', but the essential operational context for calling the tool correctly is present.

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?

Schema already covers all parameters at 100%, and the description adds important meaning to confirmedCost and authorization by explaining the exact quote/confirm/run flow. It also clarifies githubToken's role for private repos. Slightly less direct parameter-by-parameter mapping, but the added cost-confirmation semantics are genuinely useful.

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?

States a specific action: run ONE audit module against a GitHub repository, and clearly distinguishes from whole-repo or scoring tools by saying it never produces scores or verdicts. It also names concrete module keys, so an agent knows exactly what this tool does.

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?

Provides clear operational guidance: deterministic modules return directly, deep-tier modules require a key and a three-step cost confirmation flow. It does not explicitly contrast with sibling tools like audit_repo or scan_source, but the 'ONE module' wording and protocol details make appropriate usage reasonably clear.

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

scan_sourceFree Scan of Posted Source (no GitHub repo required)B

Read-onlyIdempotent

Inspect

Free nittim look: committed secrets and known CVEs over posted source files. No account, no key, no nittim credits. Hard evidence only: never scores, never a production verdict. Send SOURCE files, not build output (no node_modules, no dist, no binaries).

ParametersJSON Schema

Name	Required	Description
`name`	Yes	A display label for this project, e.g. 'my-abacus-app'. Sanitized before use.
`files`	Yes	Source files as { path, content }[] — not build output. At most 1000; over the internal per-audit cap, the highest-priority ones win.
`uploadGrant`	No	Optional: the id of an upload approval the account owner already confirmed. A large post without one is answered with a confirmation covering the files and the price.

TDQS

B3.4/5.0

Behavior3/5

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

The description adds behavioral details beyond annotations, such as being free, requiring no account, and never scoring or giving a production verdict. It does not mention rate limits, side effects, or confirmation flows, but it does not contradict the readOnly/idempotent hints.

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 brief and logically structured: a statement of function, a statement of capabilities/limitations, and an instruction on what to send. The unusual phrasing 'nittim look' and 'nittim credits' is slightly cryptic but does not harm overall conciseness.

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 no output schema, the description gives a reasonable overview but omits details about response format, error handling, and the internal cap on files (which appears in the parameter description but not in the main description). It is adequate but not fully 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?

The schema already provides full descriptions for all parameters, including the 'files' and 'uploadGrant' fields. The main description only repeats that source files (not build output) should be sent, adding little new semantic information beyond the schema.

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 scans posted source files for committed secrets and known CVEs, and explicitly notes it never scores or gives a production verdict. This communicates the core function, though the odd phrase 'nittim look' slightly obscures it.

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?

The title 'no GitHub repo required' and instructions to send source files rather than build output provide some usage guidance. However, it does not explicitly contrast with sibling tools like 'audit_repo' or 'audit_source', leaving the exact condition for choosing this tool implicit.

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

verify_fixRe-check One Finding Against Current CodeAInspect

NEEDS A KEY: mint one at https://nittim.com/keys. Re-checks ONE finding from a finished audit against the repository's current code, or a commit named in the call, and answers fixed, still present, or undetermined — with the reason. It reads only the file that finding cites. Free, capped per day, and it moves no score or verdict: the report keeps recording what was true of the commit it ran on.

ParametersJSON Schema

Name	Required	Description
`ref`	No	A commit SHA or branch to check instead of the repository's current HEAD. Must be the audited commit or newer.
`auditId`	Yes	The audit UUID, from its report link.
`findingKey`	Yes	The finding's stable key, as printed beside it in the report's findings list.

TDQS

A3.5/5.0

Behavior1/5

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

The description claims the tool reads only the cited file and moves no score or verdict, which contradicts the readOnlyHint: false annotation. This is a direct conflict.

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 mostly concise and front-loads the key requirement, but includes redundant phrases like 'the report keeps recording what was true of the commit it ran on' which could be trimmed.

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 (3 parameters, no output schema), the description explains the purpose, the key requirement, the read scope, and the output format ('fixed, still present, or undetermined'). It does not describe error handling, but that is not essential here.

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 schema covers all three parameters with descriptions, and the description adds context by saying 'or a commit named in the call' for ref and 'from a finished audit' for auditId, but findingKey is left to 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 re-checks one finding against current code or a specified commit, with a specific verb and scope. It also specifies the output categories and the limitation to one file. This distinguishes it from the related audit/dispute tools.

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?

It mentions a key requirement and that it is free and capped per day, and that it moves no score or verdict. However, it does not explicitly compare with sibling tools like get_audit or dispute_finding, so the when-to-use guidance is only implied.

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.

1 tool updateSep 7, 2026

Changedreport_loop7 fields changed

removedInput schema / properties / passes / items / properties / findings / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / passes / items / properties / findings / description

Previous value: -"Findings this pass named, by category — omit a category that found nothing."New value: +"Findings this pass named — one entry per category with something to report; omit a category that found nothing. Each count defaults to 0 when omitted."

addedInput schema / properties / passes / items / properties / findings / items

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "category": {
+      "enum": [
+        "security",
+        "privacy",
+        "reliability",
+        "code_quality",
+        "ai_risk",
+        "performance",
+        "devops",
+        "data",
+        "business",
+        "devex",
+        "accessibility",
+        "observability",
+        "maintainability"
+      ],
+      "type": "string"
+    },
+    "critical": {
+      "default": 0,
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "high": {
+      "default": 0,
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "low": {
+      "default": 0,
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    "medium": {
+      "default": 0,
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "category"
+  ],
+  "type": "object"
+}

addedInput schema / properties / passes / items / properties / findings / maxItems
```
Added value: +13
```

removedInput schema / properties / passes / items / properties / findings / properties

Removed value: -{
-  "accessibility": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "ai_risk": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "business": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "code_quality": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "data": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "devex": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "devops": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "maintainability": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "observability": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "performance": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "privacy": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "reliability": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  },
-  "security": {
-    "additionalProperties": false,
-    "properties": {
-      "critical": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "high": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "low": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      },
-      "medium": {
-        "maximum": 9007199254740991,
-        "minimum": 0,
-        "type": "integer"
-      }
-    },
-    "required": [
-      "critical",
-      "high",
-      "medium",
-      "low"
-    ],
-    "type": "object"
-  }
-}

changedInput schema / properties / passes / items / properties / findings / type
```
Previous value: -"object"New value: +"array"
```

changedInput schema / properties / passes / items / required

Previous value: -[
-  "n",
-  "findings",
-  "fixed",
-  "clean"
-]New value: +[
+  "n",
+  "fixed",
+  "clean"
+]

Related MCP Connectors

Python Code Validator A
ai.statemind
Proves AI-generated Python does what you asked: lint, types, security, sandbox run, exact fixes.
Code Analysis Code Execution Developer Tools
31
ShipSafe Security Scanner
co.ship-safe
Independent security review for AI-built apps: exposed secrets, broken auth, unsafe data access.
Security Penetration Testing Code Analysis
1
VulX WatchOAuth
ai.vulx
Independent security review for AI-built apps. Watch a GitHub repo. Never a patch.
Security Version Control Code Analysis
1
Norma by Quality CloudsOAuth
ai.qualityclouds
Deterministic AI code review, with an audit record. Governance inside the agent loop.
Code Analysis Developer Tools
15

Related MCP Servers

Norma MCP Server
Code Analysis Coding Agents Developer Tools
qualityclouds
A
license
Not graded
quality
B
maintenance
Deterministic AI code review with audit records, providing stack-specific rulesets and governance for coding agents.
Updated 25 days ago (2026-08-31 11:14 UTC)
5
MIT
Python Code Validator
Code Analysis Developer Tools
jkanselaar
A
license
A
quality
A
maintenance
Validates AI-generated Python: syntax, lint, security scan and deterministic repair.
Updated a month ago (2026-08-17 19:06 UTC)
3
MIT
Security Scanner MCP
Code Analysis Security Testing & QA Tools
ongjin
A
license
Not graded
quality
D
maintenance
Automatically detects security vulnerabilities in AI-generated code, scanning for hardcoded secrets, injection flaws, XSS, weak cryptography, authentication issues, path traversal, and vulnerable dependencies across JavaScript, Python, Java, and Go.
Updated 4 months ago (2026-05-20 13:27 UTC)
19 npm
2
MIT
CodeGuardian MCP
Code Analysis Developer Tools Testing & QA Tools
codegoddy
A
license
A
quality
D
maintenance
Validates AI-generated code against actual codebases to catch hallucinations, dead code, and API mismatches before runtime.
Updated 7 months ago (2026-02-27 14:29 UTC)
12
3 npm
1
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources