Skip to main content
Glama

nittim

by com.nittim
OverviewDiscussionsAdmin

Free Scan of Posted Source (no GitHub repo required)

scan_source
Read-onlyIdempotent

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesA display label for this project, e.g. 'my-abacus-app'. Sanitized before use.
filesYesSource files as { path, content }[] — not build output. At most 1000; over the internal per-audit cap, the highest-priority ones win.
uploadGrantNoOptional: 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / files / description
      Previous value: -"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."New value: +"Source files as { path, content }[] — not build output. At most 1000; over the internal per-audit cap, the highest-priority ones win."
    • changedInput schema / properties / files / items / properties / content / description
      Previous value: -"The file's full text content."New value: +"The file's full text."
    • changedInput schema / properties / name / description
      Previous value: -"A display label for this project, e.g. 'my-abacus-app'. Sanitized before use — no path/URL characters needed."New value: +"A display label for this project, e.g. 'my-abacus-app'. Sanitized before use."
    • changedInput schema / properties / uploadGrant / description
      Previous value: -"The id of an upload approval the account owner has already confirmed. Optional: a post larger than the small-upload threshold that carries none is answered with one confirmation covering the file list and the price together. A smaller post goes straight through."New value: +"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."
  2. Changed1 schema field changed
    • changedInput schema / properties / uploadGrant / description
      Previous value: -"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."New value: +"The id of an upload approval the account owner has already confirmed. Optional: a post larger than the small-upload threshold that carries none is answered with one confirmation covering the file list and the price together. A smaller post goes straight through."
  3. First observed

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.

All nittim toolsInspect
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.

Resources