Dataconto: who buys company records and code

Price private code at a buyer's published per-token rates

code_value

Read-onlyIdempotent

Counts code the way pre.dev's public script does (code files in full, text files up to 10x the code, minified and bundle-named files skipped, 4 bytes per token) and prices it at Pangea's published non-exclusive list rates per million tokens of source and of git history. Give files (path and size in bytes, e.g. from git ls-tree -r -l HEAD), or code_bytes and text_bytes, or source_tokens. History is optional. A list price, not an offer.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "code_value"
  }
}

Input Schema

Name	Required	Description
`files`	No	Files at HEAD, paths relative to the repo root. Skip rules (node_modules, vendor, build output) are applied here.
`code_bytes`	No	Bytes of code files, if you summed them yourself.
`text_bytes`	No	Bytes of text files (Markdown, JSON, YAML, HTML).
`source_tokens`	No	Source tokens, if already counted.
`history_tokens`	No	Git history tokens, if counted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 27, 2026
- addedInput schema / properties / code_bytes / maximum
```
Added value: +10000000000000
```
- addedInput schema / properties / files / items / properties / path / maxLength
```
Added value: +500
```
- addedInput schema / properties / files / items / properties / size / maximum
```
Added value: +100000000000
```
- addedInput schema / properties / history_tokens / maximum
```
Added value: +10000000000000
```
- addedInput schema / properties / source_tokens / maximum
```
Added value: +10000000000000
```
- addedInput schema / properties / text_bytes / maximum
```
Added value: +10000000000000
```
AddedOct 26, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, but the description adds substantive behavior: the counting rules (text capped at 10x code, minified and bundle-named files skipped, 4 bytes per token) and the framing 'A list price, not an offer.' Those are traits no annotation conveys.

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 critical methodology and the 'list price, not an offer' caveat are front-loaded, and the input-mode sentence is compact. The opening sentence is long and packs several rules together, but every clause carries information.

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

Completeness4/5

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

There is no output schema, so the description has to carry the return semantics; it does so implicitly by stating it prices source and history tokens at published rates. The exact shape of the response (a breakdown vs. a single figure) is not stated, which is the one remaining gap for a pricing 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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining the alternate input modes and their relationship, and by naming a concrete source for `files` (`git ls-tree -r -l HEAD`). That resolves the main ambiguity of which parameters to populate.

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 gives a concrete verb-plus-resource (counts code, prices it at published per-million-token rates) and specifies the exact methodology used, so an agent knows precisely what computation happens. It doesn't explicitly contrast itself with the sibling `estimate` tool, which keeps it from a 5.

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 clearly tells the caller which input shapes are acceptable (files, or code_bytes plus text_bytes, or source_tokens) and that history is optional, which is real invocation guidance. However it never states when to choose this over sibling tools such as `estimate` or `fit_check`, nor any exclusion conditions.

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

All Dataconto: who buys company records and code tools Inspect

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

Need Help?