Skip to main content
Glama
Sign In

tlly

by dev.tlly
OverviewDiscussionsAdmin

Write series points

push_points
DestructiveIdempotent

Write dated values to a series (upsert by date). A date is YYYY-MM-DD (midnight UTC), or a time such as 2026-09-30T14:30Z, floored to the half hour. Use when you compute data yourself. Values are numbers, or short text labels for a text series (e.g. a rating or stance; see Data policy). A series' first write fixes its type.

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": {
      "series": "<series>",
      "points": "<points>"
    },
    "name": "push_points"
  }
}

Input Schema

NameRequiredDescriptionDefault
pointsYes[{"date":"2026-09-30","value":4.6}] or [{"date":"2026-09-30","value":"AA+"}]
seriesYesseries name, e.g. household_credit_yoy

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag destructive/idempotent/openWorld=false, and the description is consistent with them via "upsert by date." It adds genuinely useful behavior the annotations cannot express: timestamps are floored to the half hour, a series' type is fixed by the first write (effectively irreversible), and values must be numeric or short text. It does not spell out what happens to previously stored values at the same dates or what an error/type mismatch looks like.

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?

Four tight sentences, front-loaded with the verb and upsert semantics, then format, then usage, then the type-fixing caveat. Every sentence carries information; the only weak element is the external "see Data policy" pointer, which is not self-contained.

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 two-parameter write tool with full schema coverage and annotations covering the safety profile, the description supplies what's missing: date formatting, value typing, upsert/overwrite behavior, and the immutable-first-type rule. It stops short of describing batch/size limits or error behavior, which matters for a destructive upsert.

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 baseline is 3, but the description adds real semantic constraints beyond the schema's bare examples: the date grammar (YYYY-MM-DD as midnight UTC, or ISO time floored to the half hour) and the value domain (number vs. short text label). The dangling "see Data policy" reference for text labels leaves one point under-specified.

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 and resource ("Write dated values to a series") plus the write mode ("upsert by date"). The clause "Use when you compute data yourself" implicitly separates it from siblings that ingest externally or derive server-side, so an agent can pick it without opening another schema.

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?

Gives a clear when-to-use condition ("Use when you compute data yourself"), which points away from import_once/define_derived without naming them. No explicit exclusions or prerequisites (e.g. series must be created or must match an existing type) are stated.

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

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