Skip to main content
Glama

nittim

by com.nittim
OverviewDiscussionsAdmin

Estimate an Audit's Price — No Upload Required

estimate_audit
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoA 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.
repoUrlNoGitHub repository URL or owner/repo. Mutually exclusive with `files` — send one.
fullScanNoPrice Full Audit (every eligible file, or a refusal with the reason when the selection is too large) instead of the default Audit.
githubTokenNoOptional GitHub personal access token (read-only) for a private repo. Without one, a signed-in account with nittim's GitHub App installed at nittim.com for this repo still prices it — no token needed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / githubToken / description
      Previous value: -"Optional GitHub personal access token (read-only) for a private repo."New value: +"Optional GitHub personal access token (read-only) for a private repo. Without one, a signed-in account with nittim's GitHub App installed at nittim.com for this repo still prices it — no token needed."
  2. Changed4 schema fields changed
    • changedInput schema / properties / files / description
      Previous value: -"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."New value: +"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."
    • changedInput schema / properties / files / items / properties / bytes / description
      Previous value: -"The file's byte size. No `content` field exists on this shape — nothing is uploaded to ask a price."New value: +"The file's byte size. This shape has no `content` — nothing is uploaded."
    • changedInput schema / properties / fullScan / description
      Previous value: -"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)."New value: +"Price Full Audit (every eligible file, or a refusal with the reason when the selection is too large) instead of the default Audit."
    • changedInput schema / properties / repoUrl / description
      Previous value: -"GitHub repository URL or owner/repo string, e.g. https://github.com/owner/repo or owner/repo. Mutually exclusive with `files` — send exactly one."New value: +"GitHub repository URL or owner/repo. Mutually exclusive with `files` — send one."
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, open-world and non-destructive. The description adds genuine context beyond those flags: no file content/upload, never charges, calls no model, stores nothing, and the auth-dependent divergence (signed-in returns credit balance and Audit coverage, guest omits both). No contradiction with annotations.

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

Conciseness4/5

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

A dense single paragraph that front-loads the core purpose and keeps the optional fullScan flag until last. Every clause carries weight — safety guarantees, guest/signed-in divergence, no-storage claim — though it could be lightly broken up; nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With four parameters and no output schema, the description itself carries the output contract (tier, pass count, exact price, conditional credit balance). It covers both input modes, auth-state differences, and over-cap refusal behavior, so an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100% with every parameter richly documented (files' mutual exclusivity and cap behavior, repoUrl format, fullScan meaning, githubToken optional scope). The description reinforces the no-upload semantic but adds little param-level detail beyond what the schema already provides, so the baseline 3 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?

States a specific verb+resource ('Price an audit') and the exact output (tier, pass count, price). The phrase 'runs no audit, calls no model and stores nothing' sharply separates it from sibling audit-executing tools like audit_repo/audit_source/scan_source, so an agent can distinguish estimating a price from running an audit without opening those schemas.

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?

Documents the two input modes (repoUrl or a files manifest) and their mutual exclusivity ('Send one or the other'), plus the fullScan flag for Full Audit pricing. The temporal role is implied by 'before buying one,' but the description never names sibling alternatives or states explicitly when not to use it, leaving alternative selection to inference.

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