Production-safety audits for AI-generated code, with a fix for every finding. Scan for committed secrets and known vulnerable dependencies free with no key; a full audit returns a verdict with security, privacy, reliability and architecture findings, priced per audit and quoted before it runs.
Paid nittim AI audit (credits, human confirm). One structured pass over the repository's highest-signal source; the report states what it read. The only tool that produces scores and a verdict. This call returns the audit's id — no report, no scores, no verdict in this answer. THE ONE EXCEPTION: a commit already audited under this account is returned directly, as the finished report, with no id and no charge. TIERS: defaults to Audit; fullScan: true buys the wider Full Audit tier, priced by pass count. BYOK: this tool always runs on nittim's key and is charged in credits — the report is finalized after your call ends, so a key sent in the x-nittim-anthropic-key header cannot be honoured here, and a call carrying one is refused rather than charged. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY: the first call only returns a price quote and runs nothing. A second call, with confirmedCost set to that exact price, runs it — a key that is not marked autonomous also needs the account owner's own approval before that second call runs.DELIVERED AS A BATCH: this call returns the audit's id immediately — nothing runs inside the call. The report lands Usually within 15 minutes*. * Most reports land within 15 minutes. Worst case, 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| repoUrl | Yes | GitHub repository URL or owner/repo string, e.g. https://github.com/owner/repo or owner/repo. Private repos require a githubToken. | |
| fullScan | No | True buys the wider Full Audit tier instead of the default Audit: every eligible source file, priced by pass count. | |
| payInstead | No | True runs for credits immediately instead of queuing, skipping the covered (Audit) entitlement even when it would otherwise be free — for when the account owner has chosen to pay rather than wait for the daily free-audit budget to reopen. | |
| deployedUrl | No | Optional URL of this repository's live deployment, intended for a URL the account owner actually operates. When set, the audit also runs one bounded, READ-ONLY fetch pass against that origin — the page itself plus a handful of GET requests for static files the repo also contains (e.g. /robots.txt) — and reports observed drift between the deployed artifact and the audited commit on the report. Nothing else is ever fetched, redirects are never followed, and private/internal addresses are refused. | |
| githubToken | No | Optional GitHub personal access token (read-only) for private repos. If omitted, only public repos are accessible. | |
| authorization | No | HUMAN CONFIRMATION. Omit until the account owner has pressed Confirm on the link a paid tool answered with; then set to that answer's `authorization` id (single-use, short TTL). Protocol: server instructions. | |
| confirmedCost | No | COST CONFIRMATION. Omit on the first call (it only quotes); then set to the exact `cost` object quoted. A moved price is re-quoted, never charged. Protocol: server instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Exceptionally transparent. The description discloses the async delivery model (returns id immediately, nothing runs inside the call), the two-step billing protocol (first call quotes and runs nothing; second call charges), the no-BYOK refusal behavior, the already-audited exception with no charge, human-approval requirements, and worst-case delivery time. All of this goes far beyond the annotations, and none of it contradicts them — readOnlyHint=false, openWorldHint=true, and idempotentHint=false are all consistent with a paid, externally-fetching, non-idempotent audit tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most important facts and uses ALL-CAPS section headers as useful signposts. But it is notably verbose and repetitive: the 'returns the audit's id, nothing runs inside the call' fact appears twice (main body and DELIVERED AS A BATCH), and the delivery-time claim is stated three times ('usually within 15 minutes', 'Most reports land within 15 minutes', 'Worst case, 24 hours'). The asterisk footnote adds no information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a very complex tool — 7 parameters, nested confirmedCost object, two-call billing protocol, async delivery, exception path, and no output schema — the description covers an exceptional amount: cost, timing, key policy, human confirmation, tier selection, and the audit's scope. The main gap is that no output schema exists and the description never specifies the exact shape of the quote response the agent needs to copy into confirmedCost, nor does it point to get_audit as the retrieval path for the finished report.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 — every parameter already carries a solid schema description (deployedUrl's security constraints, payInstead's free-budget logic, githubToken's private-repo purpose). The description adds genuine value on top by supplying the temporal protocol that gives confirmedCost, authorization, and fullScan their meaning: quote first, confirm with the exact quoted cost, and the call is refused if a key header is sent. This elevates parameter semantics above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('one structured pass over the repository's highest-signal source') and delivers the defining trait: this is the only tool that produces scores and a verdict, which cleanly separates it from siblings like estimate_audit, get_audit, and scan_source. It also manages expectations about what this call returns (an id, not a report), which sharpens the purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context: when to expect a finished report (already-audited commits), when to buy the Full tier (fullScan=true), and the mandatory two-call quote-then-confirm protocol. However, it never explicitly names sibling alternatives and the conditions that route to them — e.g., 'use get_audit to retrieve the report' or 'use estimate_audit for a quote without running.' 'The only tool that produces scores and a verdict' is an implicit differentiator, not an explicit routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your project isn't on GitHub? Post the files directly and get an AI audit — verdict, scores, and top findings — plus a shareable report link. On nittim's own key, this call submits the audit and returns its id — no report, no scores, no verdict in this answer; the report lands Usually within 15 minutes*. * Most reports land within 15 minutes. Worst case, 24 hours. BYOK Pro (below) is the one exception: on your own key this call still answers in this call, with the report. For builders on Abacus/Replit/Lovable or a local folder with no git remote at all. Send SOURCE files (not build output — no node_modules, no dist/build, no binaries); the caller pre-filters. Costs 5.14 credits (the same entitlement ladder as every AI audit here: owner free, a paid+subscribed org's included allowance, an unspent Audit, then prepaid credits). Always saved as a PRIVATE report — posted source is unpublished IP by definition. TIERS: defaults to Audit; fullScan: true buys the wider Full Audit tier over the files you posted, priced by pass count. BYOK Pro: the x-nittim-anthropic-key header runs this on your own key against your monthly allowance. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY: the first call only returns a price quote and runs nothing. A second call, with confirmedCost set to that exact price, runs it — a key that is not marked autonomous also needs the account owner's own approval before that second call runs.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A display label for this project, e.g. 'my-abacus-app'. Sanitized before use — no path/URL characters needed. | |
| files | Yes | The source files to audit, as { path, content }[]. Send SOURCE files, not build output (no node_modules, no dist/build, no binaries) — pre-filter before posting. At most 1000 files; the highest-priority ones (manifests, lockfiles, CI config, .env-shaped files, server-execution routes) win if you're over the internal per-audit cap. | |
| fullScan | No | True buys the wider Full Audit tier instead of the default Audit, over the files you post: every eligible file, priced by pass count. | |
| uploadGrant | No | The grant id `preview_upload` returned, once the account owner has confirmed it. Required only for a post larger than the small-upload threshold; a smaller one goes straight through. | |
| authorization | No | HUMAN CONFIRMATION. Omit until the account owner has pressed Confirm on the link a paid tool answered with; then set to that answer's `authorization` id (single-use, short TTL). Protocol: server instructions. | |
| confirmedCost | No | COST CONFIRMATION. Omit on the first call (it only quotes); then set to the exact `cost` object quoted. A moved price is re-quoted, never charged. Protocol: server instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations false, the description carries the full disclosure burden and meets it: first call 'only returns a price quote and runs nothing,' the report is async ('Usually within 15 minutes... worst case, 24 hours'), and on nittim's key only an id is returned. It further discloses the 5.14-credit cost, the entitlement ladder, the always-private report policy, and the BYOK in-call exception. Nothing contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries genuine information, but the structure is one dense wall-of-text paragraph with mid-sentence embedded labels (TIERS:, BYOK Pro:, NEEDS A KEY:, COSTS MONEY:). There is also redundancy in the timing note: 'the report lands Usually within 15 minutes*. * Most reports land within 15 minutes. Worst case, 24 hours.' High value density undermined by poor readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter, nested-object tool with no output schema and sparse annotations, this is unusually complete: eligibility, cost, two-call confirmation, authorization/approval, tiers, privacy, async timing, and file-filtering rules are all covered. The notable gap is that it never says how the returned audit id is consumed (e.g., retrieving the report via a sibling like get_audit), and it defers to external 'Protocol: server instructions' knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions are already detailed, so the baseline is 3. The description adds meaning on top by pricing the operation ('Costs 5.14 credits'), explaining the confirmedCost two-call protocol in prose ('A second call, with confirmedCost set to that exact price, runs it'), and clarifying that fullScan 'buys the wider Full Audit tier... priced by pass count.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line states a specific action with a clear resource: 'Post the files directly and get an AI audit — verdict, scores, and top findings — plus a shareable report link.' The title ('no GitHub repo required') and the framing question 'Your project isn't on GitHub?' explicitly distinguish this from the sibling audit_repo without needing to open either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'For builders on Abacus/Replit/Lovable or a local folder with no git remote at all,' with the clear exclusion that this is the non-GitHub path. It also documents the full operational workflow — mint a key, expect a price quote on the first call, confirm cost on the second, and obtain owner approval for non-autonomous keys — which is far more than minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NEEDS A KEY: mint one at https://nittim.com/keys. Records that a specific finding from a prior audit is wrong (stance:'dispute') or genuinely real (stance:'confirm'), backed by evidence from the repo. 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 when the key is not available.
| Name | Required | Description | Default |
|---|---|---|---|
| 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond the sparse annotations: it records a signal, requires a key, and explicitly never changes audit scores, verdict, or stored report. This credibly explains why readOnlyHint is false (it writes a signal) while also clarifying that it is not destructive to the audit itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the critical prerequisite (NEEDS A KEY), then states the action, the non-effect on the audit, and the identification options. Every sentence carries necessary information and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested evidence objects, no output schema, and minimal annotations, the description covers the key prerequisite, the side-effect scope, and how to identify the target finding. It does not explain how the key is supplied to the API or what the response indicates, which is a minor gap for invocation confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameter meanings are already documented. The description adds the useful rule that findingKey is preferred, with exact dimension+title as the fallback, but this largely restates schema descriptions. No substantial new parameter-level semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Records') with a clear resource ('a specific finding from a prior audit') and explicitly distinguishes the two stances: 'dispute' and 'confirm'. It also separates this tool from audit-scoring tools by stating it is only a SIGNAL for owner triage and never changes the audit's scores, verdict, or stored report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you want to dispute or confirm a prior finding, and it explicitly says the tool does not alter audit results. It does not name a specific sibling alternative or provide when-not-to-use conditions, but the 'SIGNAL for owner triage' framing makes the intended use reasonably explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NEEDS A KEY: mint one at https://nittim.com/keys. Give a GitHub repository URL, or a manifest of just the paths and byte sizes you would post — no file content, nothing is uploaded to answer this — and get back the tier this selection would run at (Audit or Full Audit), how many passes, the exact price, your account's current credit balance, and whether this run would be covered by an unspent Audit. By default this prices Audit — the tier a call with no fullScan charges, so the quote is the exact price a real call makes at that moment. fullScan: true prices Full Audit instead — the same wider tier a real call charges when sent with fullScan: true. A manifest with no content posted yet gets an honest upper-bound pass count either way, clearly marked as an estimate. Never charges, never runs an audit, never stores anything.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | A manifest of paths and sizes only, in place of repoUrl — the same set you would post for a source-based audit. Sending more than 1000 entries is not a schema error — the answer names the cap and how to trim to it. Mutually exclusive with `repoUrl` — send exactly one. | |
| repoUrl | No | GitHub repository URL or owner/repo string, e.g. https://github.com/owner/repo or owner/repo. Mutually exclusive with `files` — send exactly one. | |
| fullScan | No | Price a Full Audit run (reads every eligible file, or refuses with the reason if the selection is too large to sell that way) instead of the default Audit (a fast, sampled pass). | |
| githubToken | No | Optional GitHub personal access token (read-only) for a private repo. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the auth requirement, the no-upload guarantee for both input modes, and the safety profile ('Never charges, never runs an audit, never stores anything'). It also adds nuanced behavior: the default quote is 'the exact price a real call makes at that moment', and content-free manifests return an 'honest upper-bound pass count... clearly marked as an estimate'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the most critical facts: the key requirement and the no-upload promise. Each sentence adds a distinct fact (inputs, outputs, default tier, fullScan behavior, estimate honesty, guarantees). There is some redundancy — no-upload is restated three times and the never-charges/never-stores guarantee twice — but the emphasis is reasonable for a tool whose core value is trust.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by fully listing the return values (tier, passes, price, balance, coverage), and it documents the estimate upper-bound behavior for manifest-only calls. With 100% parameter coverage, 4 params, and no nested objects, the main gap is the absence of failure-mode descriptions (missing/invalid key, unreachable repo URL, what an error response looks like) — minor for a read-only estimation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3, but the description adds meaning beyond the schema: it explains that fullScan changes which tier is quoted and ties it to what 'a real call charges', and it frames the files manifest as 'paths and byte sizes you would post' with no content. This enriches the agent's understanding of how the parameters affect the quote.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description name a specific verb-resource pair — estimate an audit's price — and enumerate the exact outputs: tier (Audit or Full Audit), passes, exact price, credit balance, and coverage status. It distinguishes itself from the audit execution siblings by repeating the no-upload differentiator ('nothing is uploaded to answer this', 'Never charges, never runs an audit').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: the key prerequisite is front-loaded ('NEEDS A KEY: mint one at https://nittim.com/keys'), and it explains when to price Audit vs Full Audit ('By default this prices Audit... `fullScan: true` prices Full Audit instead'). However, it never explicitly names sibling tools or states 'use this instead of audit_repo when you only need a price', leaving the when-not-to-use boundary implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a nittim audit by its UUID, at any stage. A finished audit returns the compact markdown digest — verdict, scores and top findings — plus its report link. An audit that is STILL RUNNING says so — not an error, and not a missing id. A second audit of the same commit is charged again and produces two verdicts for one commit. A FAILED audit says why it failed and, if you own it, what happened to the charge. Reading needs the key of the account that owns the audit; minting a new key does not grant access to somebody else's report.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The UUID of the saved audit, from the /report/{id} URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses substantial behavioral detail: running audits return a status rather than an error, repeated audits of the same commit create separate verdicts and charges, and failed audits explain failure and refund status. It also states the ownership requirement clearly. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds only high-value behavioral facts. Every sentence conveys information an agent needs: result format, in-progress behavior, duplicate-charge consequence, failure handling, and access control. It is detailed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still covers the main return contents (markdown digest, verdict, scores, findings, report link) and edge cases (running, failed, unauthorized). For a one-parameter read tool, this is complete enough for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single id parameter is well described in the schema as a UUID from the /report/{id} URL. The description does not need to add parameter semantics, and it does not, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Retrieve a nittim audit by its UUID, at any stage.' It clearly identifies the operation as fetching a saved audit, distinguishing it from sibling tools that create, scan, or run audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: it works at any audit stage, handles running audits gracefully, and requires ownership of the audit's key. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is strong enough that an agent can select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 numeric score, never a pass/fail verdict. Costs 5.03 credits. The one paid tool a publishable (nittim_pk_…) key may call, subject to its own spend cap. The judge is always a model from a different vendor family than whatever produced the content — grading a model with a model from its own vendor family shares training data and blind spots, the exact thing an independent judge exists to avoid. modelUnderTest names which vendor family produced content, and is most useful whenever that content did not come from the client itself asking. Every answer states which judge vendor ran. NEEDS A KEY: mint one at https://nittim.com/keys. COSTS MONEY: the first call only returns a price quote and runs nothing. A second call, with confirmedCost set to that exact price, runs it — a key that is not marked autonomous also needs the account owner's own approval before that second call runs.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. Omit until the account owner has pressed Confirm on the link a paid tool answered with; then set to that answer's `authorization` id (single-use, short TTL). Protocol: server instructions. | |
| confirmedCost | No | COST CONFIRMATION. Omit on the first call (it only quotes); then set to the exact `cost` object quoted. A moved price is re-quoted, never charged. Protocol: server instructions. | |
| modelUnderTest | No | Optional — which vendor family produced `content`, if it's itself a model's output. The judge that runs is always a different vendor family than this names, so the grader is never the same vendor family as what it's grading. Set 'unspecified' for anything that isn't model output (code, a document) or when the family is genuinely unknown. Passing it explicitly is most useful whenever the content did not come from you asking about your own output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are uniformly false, so the description carries the full burden — and it over-delivers: cost (5.03 credits), key requirement with minting URL, two-phase execution (first call quotes and runs nothing, second runs on confirmedCost), owner-approval requirement for non-autonomous keys, the always-cross-vendor guarantee, and the output-shape restriction. No contradiction with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long (~170 words) but dense and front-loaded: the core function and return contract lead, followed by cost and key facts before the protocol detail. Minor redundancy exists — the confirmedCost two-call flow is restated in the schema descriptions — and the vendor-family rationale sentence runs slightly long, so not a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, two-call, key-gated tool with no output schema and no informative annotations, the description covers every operational essential: purpose, return format, cost, key requirements, approval step, cross-vendor behavior, and judge-vendor disclosure. Nothing an agent needs to drive the protocol correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds genuine value on top: it explains the behavioral effect of modelUnderTest (the judge is always a different vendor family than the one named) and why that matters, plus the overall two-call protocol that gives operational meaning to confirmedCost and authorization.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Run a cross-vendor judge model over any text you post: code, a document, another model's output, anything.' It also pins down the return contract ('findings + rationale ONLY — never a numeric score, never a pass/fail verdict') and the cross-vendor constraint, distinguishing it clearly from the repo/source audit siblings (audit_repo, scan_source, run_module, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: applicable to any text, the two-call cost-confirmation flow, and when modelUnderTest is most useful ('whenever that content did not come from the client itself asking'). It does not explicitly name sibling alternatives or state when not to use it, but the siblings are functionally distant (repo/source audits, module runs), so routing risk is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
NEEDS A KEY: mint one at https://nittim.com/keys. Send the PATHS AND SIZES of the files you would post — no content, nothing is uploaded to ask this — and get back the list, the byte count, and a link for the account owner to approve it. Posting more than a small selection of files needs this approval first; the approval's id (uploadGrant) and the identical file set are then accepted by the real call. Nothing is charged, here or by approving.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A display label for this project, e.g. 'my-abacus-app'. Sanitized before use — no path/URL characters needed. | |
| files | Yes | Paths and sizes only — the same set you would post. Never file content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral specifics beyond the sparse annotations: no content is uploaded, nothing is charged, a key is required, and the approval id plus identical file set are consumed by the real call. These are crucial non-obvious side-effect and workflow facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each carrying essential operational information: key requirement, input shape, return value, approval necessity, and cost. Attention is front-loaded with 'NEEDS A KEY' followed by what is sent and received.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description covers prerequisites, workflow, returned artifacts, and cost implications. It leaves some ambiguity about the exact 'real call' tool name and error handling, but the core invocation context is adequately explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents name sanitization and file path/bytes semantics. The description reinforces 'no content' and 'identical file set' but adds little parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear preview/approval workflow: send only paths and sizes, get back a byte count and an approval link for the account owner. It is distinct from the sibling audit/scan tools and from the 'real call' it defers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when this step is required: 'Posting more than a small selection of files needs this approval first.' It also ties the returned uploadGrant to the later real call. However, it never names the sibling or alternative upload tool, and 'small selection' is left undefined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NEEDS A KEY: mint one at https://nittim.com/keys. Records anonymised counts from a completed self-review pass: pass numbers, a findings-by-category tally, a fixed count, and whether each pass was clean. The schema carries counts only — no title, file path, snippet, or other description of a specific finding. Nothing is charged. Reporting the same repo again from this account updates the existing record with the new numbers instead of being rejected. The reply states which happened (outcome: "inserted" or "updated"). Results appear at https://nittim.com/loop.
| Name | Required | Description | Default |
|---|---|---|---|
| swept | No | Optional, only meaningful when the loop looked systemic: did you actually sweep the CLASS (a guard, lint rule, or exhaustiveness check that makes a new instance loud by default), not just fix the instances a pass happened to name? Omit if you didn't do a systemic pass or aren't sure — this is never derived from `passes`, only your own claim, and it never changes the reward. On a REPEAT report of the same repo, omitting this KEEPS whatever you last said, rather than clearing it — send `false` explicitly to withdraw an earlier sweep claim. | |
| passes | Yes | One entry per pass you actually ran, in order — the same loop public/selfcheck.md walked you through. | |
| repo_hash | Yes | sha256 of the repository's canonical identity (e.g. the lowercased 'owner/repo', or a stable local-project fingerprint) — NEVER the repo name itself. Compute this yourself; nittim never sees the name. | |
| client_name | No | Your own name, e.g. 'Claude Code' — omit to let nittim read it from the MCP connection if available. | |
| convergence | No | Optional: how the loop stopped, if you know — 'converged' (two consecutive clean passes) or 'cap_reached' (stopped for some other reason — a pass budget, a time box, a human call — before converging). Omit if you're not sure; nittim derives its own systemic-pattern read from `passes` regardless of what you say here. | |
| 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: xs, s, m, l, or xl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are sparse (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries the behavioral burden—and it does so thoroughly. It discloses the key requirement, the no-charge policy, the upsert behavior on repeat reports, the 'inserted'/'updated' outcome in the reply, and the results URL. This goes well beyond what the structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: four sentences, each earning its place. It front-loads the critical key requirement, then covers payload shape, privacy, charging, repeat-report behavior, and response outcome. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema, the description covers the essential operational context: authentication, cost, privacy, upsert behavior, and the reply outcome. It relies on the schema for parameter details, which is acceptable given 100% coverage. A slight gap is the lack of error-condition guidance, but it is not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters with detailed descriptions. The description adds a useful high-level summary of what counts get recorded, but it does not add per-parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Records') and a specific object ('anonymised counts from a completed self-review pass'), and explicitly limits the payload to counts only. This clearly distinguishes it from sibling audit/scan tools, which focus on running or inspecting audits rather than reporting completion numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is for post-loop reporting after a self-review pass, and calls out that it is opt-in and requires a key. It does not explicitly name alternatives like audit_repo or scan_source or state when not to use it, but the 'completed self-review pass' framing provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NEEDS A KEY: mint one at https://nittim.com/keys. Run ONE nittim audit module against a GitHub repository. Deterministic modules (secret-scan, dependency-cve) return their scanner evidence directly and are always free. Deep-tier modules make one focused model call and cost 5.03 credits each. A single-module run never produces scores or a verdict. BYOK Pro: the x-nittim-anthropic-key header runs a deep-tier module on your own key at no credit cost. Deep-tier modules follow the standard two-step quote-then-confirmedCost protocol; the two free deterministic modules run straight away — nothing is charged, so there is nothing to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| repoUrl | Yes | GitHub repository URL or owner/repo string, e.g. https://github.com/owner/repo or owner/repo. Private repos require a githubToken. | |
| moduleKey | Yes | The module's key, e.g. 'secret-scan', 'dependency-cve', 'security', 'privacy', 'gdpr'. | |
| githubToken | No | Optional GitHub personal access token (read-only) for private repos. If omitted, only public repos are accessible. | |
| authorization | No | HUMAN CONFIRMATION. Omit until the account owner has pressed Confirm on the link a paid tool answered with; then set to that answer's `authorization` id (single-use, short TTL). Protocol: server instructions. | |
| confirmedCost | No | COST CONFIRMATION. Omit on the first call (it only quotes); then set to the exact `cost` object quoted. A moved price is re-quoted, never charged. Protocol: server instructions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden and does so thoroughly. It discloses the key requirement, cost, free/deterministic vs paid/deep-tier behavior, the quote-then-confirm protocol, and the BYOK header option. There is no contradiction with annotations, and significant context is added beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the critical 'NEEDS A KEY' requirement and then proceeding from action to module categories to protocol. Each sentence carries useful information, though there is minor redundancy around charging ('always free' and 'nothing is charged') and a slight marketing tone in 'BYOK Pro.' Overall, it is appropriately sized for a tool with a multi-step payment protocol.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must handle return expectations. It clearly states that deterministic modules return scanner evidence directly and that no scores or verdict are produced, which covers the main output expectations. It does not specify what a deep-tier module returns after confirmation, but the cost and protocol flow are sufficiently detailed for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter. The description adds value by explaining the cost protocol that governs confirmedCost and authorization, tying those parameters to a real-world flow, and noting that deterministic modules require no confirmation. This goes beyond the schema descriptions by clarifying when parameters are needed and how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run ONE nittim audit module against a GitHub repository.' It further distinguishes the tool by clarifying that it handles one module only, never produces scores or a verdict, and names concrete module examples. This separates it clearly from sibling tools like audit_repo or audit_source that likely operate over the whole repo or produce broader results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage rules: deterministic modules run immediately and free, while deep-tier modules require a two-step quote-then-confirmedCost protocol. It also explains when the confirmation step is unnecessary and how BYOK Pro alters the flow. It does not explicitly name sibling alternatives or say 'use audit_repo when you need a full verdict,' but the phrase 'never produces scores or a verdict' provides strong implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A display label for this project, e.g. 'my-abacus-app'. Sanitized before use — no path/URL characters needed. | |
| files | Yes | The source files to audit, as { path, content }[]. Send SOURCE files, not build output (no node_modules, no dist/build, no binaries) — pre-filter before posting. At most 1000 files; the highest-priority ones (manifests, lockfiles, CI config, .env-shaped files, server-execution routes) win if you're over the internal per-audit cap. | |
| uploadGrant | No | The grant id `preview_upload` returned, once the account owner has confirmed it. Required only for a post larger than the small-upload threshold; a smaller one goes straight through. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful non-obvious behavior beyond the annotations: it only reports hard evidence, never scores, and never gives a production verdict. However, the claim 'No account, no key' is misleading because the uploadGrant parameter implies account-owner confirmation is needed for larger posts, making the auth-related disclosure incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the key selection criteria and exclusions front-loaded. Every clause carries information, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an input-focused scan tool, the description covers eligibility, file constraints, and behavioral limits well. It does not describe the exact response format, and with no output schema that is a minor gap, but the 'hard evidence only' framing conveys enough about what the tool will return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds useful file-filtering guidance (no build output, no binaries) but does not add meaning for the name or uploadGrant parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('scan'), a specific resource ('posted source files'), and a concrete scope ('committed secrets and known CVEs'). The title's 'no GitHub repo required' and the 'never scores, never a production verdict' line distinguish it from repo-based or deeper audit siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical guidance: send SOURCE files, not build output, and lists exclusions like node_modules, dist, and binaries. It does not explicitly route between scan_source and the sibling audit_source/audit_repo tools, but the 'no repo required' and 'free' framing implies the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools map to distinct workflow stages: estimate, preview, submit audit, retrieve audit, run module, dispute finding, and judge output. The closest pairs are audit_repo vs audit_source and scan_source vs run_module, but the descriptions provide enough boundary detail for an agent to choose correctly.
Every tool follows the same snake_case verb_noun pattern: audit_repo, audit_source, estimate_audit, get_audit, list_modules, run_module, scan_source, and so on. There is no mixing of naming conventions or vague standalone verbs.
11 tools is well-scoped for a paid AI audit service with async delivery, approval flows, and both repo-based and source-based inputs. Each tool covers a distinct step in the audit pipeline without feeling redundant or bloated.
The core lifecycle is covered: estimate cost, submit audits, run single modules, check status, retrieve results, and dispute findings. Minor gaps include no way to list past audits, cancel a pending audit, or manage credits directly, though estimate_audit does show the balance.