Skip to main content
Glama

Dataconto: who buys company records and code

Check whether a company's records are ready to license

rights_check
Read-onlyIdempotent

Dataconto's rights check: from who can sign, customer contracts, personal data, staff and contractor IP and the tools the company uses, a verdict (ready = nothing in the way, work = steps to finish before signing, not_yet = nobody known who can sign for a closing or closed company) and the steps, each with its level (block, work, note, ok) and the Dataconto page that holds its source. Unanswered questions count as not sure and are listed in missing. With tools, also returns what each tool's terms say on ownership, export and AI training, each quote dated. Sums up published sources; not legal advice. Tool ids as in get_tool_terms.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "status": "<status>"
    },
    "name": "rights_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
ipNoWhether staff and contractor agreements assign their work to the company. gaps = not all of them; na = no documents or code in scope.
toolsNoTool ids the company uses, e.g. ["slack", "notion"].
signerNoWho can sign for the company now. officer = a director or officer; officeholder = an administrator, liquidator or trustee.
statusYesoperating, closing (winding down) or closed.
personalNoPersonal data in the records. regulated = health or financial records.
contractsNoWhether any customer contracts limit what the company can do with their data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds real behavioural detail beyond them: unanswered questions become 'not sure' and appear in `missing`, each step carries a level (block/work/note/ok) and a source page, tool output includes dated quotes, and it disclaims 'not legal advice'. What it does not clarify is how many steps are typical or whether missing entries ever block a verdict.

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?

Front-loaded and dense with substance, but delivered as one long run-on construction joining verdicts, step levels, missing handling, tool output and a disclaimer. Every element earns its place, yet the structure makes it harder to scan than it needs to be.

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, and the description compensates by describing what comes back (verdict, levelled steps with sources, `missing`, per-tool terms with dated quotes). For a read-only six-parameter tool this is close to complete; only the verdict/step interaction and any limits on completeness remain unstated.

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 description coverage is 100%, so the baseline is 3; the description earns a notch above by mapping the inputs to the output (who can sign, contracts, personal data, IP, tools → verdict and steps) and by telling the agent where tool ids come from ('Tool ids as in get_tool_terms') and what supplying `tools` changes in the response. It still does not explain edge interactions, e.g. how 'unsure' values propagate into the verdict.

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?

States a specific resource and operation – a rights/readiness check that returns a verdict plus levelled steps sourced to Dataconto pages. The verdict vocabulary (ready / work / not_yet) and the input dimensions are named, so an agent knows what it gets back. It does not explicitly contrast itself with sibling checks like fit_check or estimate, so not 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?

Usage is implied by 'before signing' and by enumerating the pre-signing facts to gather, and it points at get_tool_terms as the source for tool ids. But there is no explicit when-to-use / when-not-to-use statement and no differentiation from nearby siblings (fit_check, estimate, get_tool_terms).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources