SMSC MCP

Overview Schema Source Related Servers Discussions Admin

Smsc Refresh

smsc_refresh

Ingest one closed-day page into private SQLite while retaining a checkpoint; requires verified currency and a stable redaction key and does not change SMSC or schedule work.

Instructions

Explicitly ingest one page into private SQLite, retaining a checkpoint. Only closed days, verified currency and stable redaction key are accepted. Never changes SMSC or schedules work.

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": {
      "start": "<start>",
      "end": "<end>"
    },
    "name": "smsc_refresh"
  }
}

Input Schema

Name	Required	Description	Default
`end`	Yes
`start`	Yes
`restart`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description goes further by scoping the write to a private SQLite store with a retained checkpoint and explicitly stating it never mutates SMSC or schedules work. That meaningfully de-risks the non-read-only hint. It does not explain whether re-running is safe or resumable via the checkpoint, or what a rejected precondition 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?

Three short sentences, front-loaded with the action and destination, then constraints, then guarantees — a sensible order with no filler. Minor cost: phrases like 'verified currency and stable redaction key' are unexplained jargon that an uninitiated agent cannot act on.

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

Completeness3/5

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

An output schema exists, so return values need not be described. What is missing is parameter-level guidance and failure behavior for a tool with two required, fully undocumented parameters. The safety picture is adequately covered by annotations plus the 'never changes SMSC' guarantee.

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

Parameters2/5

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

Schema description coverage is 0% across three parameters, so the description must carry the load. 'One page' hints that start/end bound a page, but their format (dates vs. timestamps), inclusivity, and ordering are unstated, and the 'restart' flag is never mentioned despite the checkpoint concept clearly relating to it.

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 and destination: 'ingest one page into private SQLite, retaining a checkpoint.' That is far more specific than the title 'Smsc Refresh' and lets an agent tell this is a local write/ingest operation rather than a query. It stops short of naming the sibling read tools it contrasts with, so differentiation is inferred 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'Explicitly' implies this is a manually triggered operation, and the acceptance conditions ('only closed days, verified currency and stable redaction key') give real preconditions for use. However, there is no statement of when to choose this over smsc_read or smsc_history, nor what to do when a precondition fails.

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

Deploy Server