Skip to main content
Glama
Sign In

Dataconto: who buys company records and code

by com.dataconto
OverviewDiscussionsAdmin

Last day to export from each business tool

deletion_clock
Read-onlyIdempotent

For a company canceling its tools or closing: the last day to export from each tool once the account ends, by plan, from what each vendor's own terms say happens after cancellation (export window in days, kept with no export, or nothing). Each row quotes the vendor's words with the date read. With no plan given, the plan with the shortest window is used and flagged. Tool ids as in get_tool_terms.

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": "deletion_clock"
  }
}

Input Schema

NameRequiredDescriptionDefault
endsNoDay the accounts end, YYYY-MM-DD, between 2000 and 2100. Default today (UTC).
plansNoPlan per tool as the vendor spells it, e.g. {"slack": "Pro"}. Keys are tool ids.
toolsNoTool ids, e.g. ["slack", "google-workspace", "hubspot"]. Omit for every tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / ends / description
      Previous value: -"Day the accounts end, YYYY-MM-DD. Default today (UTC)."New value: +"Day the accounts end, YYYY-MM-DD, between 2000 and 2100. Default today (UTC)."
    • addedInput schema / properties / ends / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
    • addedInput schema / properties / plans / additionalProperties / maxLength
      Added value: +60
    • changedInput schema / properties / plans / description
      Previous value: -"Plan per tool as the vendor spells it, e.g. {\"slack\": \"Pro\"}."New value: +"Plan per tool as the vendor spells it, e.g. {\"slack\": \"Pro\"}. Keys are tool ids."
    • addedInput schema / properties / tools / items / enum
      Added value: +[
+  "slack",
+  "github",
+  "intercom",
+  "atlassian",
+  "sentry",
+  "vercel",
+  "hubspot",
+  "zendesk",
+  "google-workspace",
+  "notion",
+  "microsoft-teams",
+  "salesforce",
+  "microsoft-365",
+  "linear",
+  "asana",
+  "zoom",
+  "gong",
+  "freshdesk",
+  "discord",
+  "dropbox",
+  "figma",
+  "quickbooks",
+  "xero"
+]
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this as a safe, idempotent, closed-world read, so the description's added context is the value: it discloses the shortest-window fallback and that such rows are flagged, plus that outputs quote vendor wording with the date read. It doesn't describe error handling for unrecognized tool ids, which keeps it from a 5.

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 purpose is front-loaded in the first clause and later sentences carry distinct payloads — fallback behavior, output shape, id convention. It is dense but every sentence contributes; minor tightening is possible in the opening.

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?

For a three-parameter tool with a nested plans object and no output schema, the description covers defaults, fallback behavior, and the returned row content. It would be complete with a note on what happens for unknown tool ids or unlisted plans.

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 schema already documents the three parameters; the baseline would be 3. The description still adds genuine semantics beyond the schema, notably the no-plan fallback rule and the tie between tool ids and get_tool_terms.

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 names a specific verb and resource — the last export day per tool after account cancellation — and scopes it to vendor Terms. It references get_tool_terms only for id conventions, so an agent can distinguish the two tools, though the boundary is implied rather than stated.

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?

"For a company canceling its tools or closing" gives a clear triggering context, and the default behavior when no plan is supplied is spelled out. It lacks an explicit when-not or a direct comparison against alternatives like get_tool_terms.

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