Skip to main content
Glama

ScorpTech x402 Tools

Ics Parse

ics_parse
Read-onlyIdempotent

Parse an iCalendar (.ics) feed from a URL (SSRF-safe; Google / Outlook / Apple calendar exports) or inline text into JSON: calendar name and zone, events with start / end in any IANA zone, all-day flag, location, organizer, attendee count, status and recurrence rule in English. Give a from / to window to expand recurring events (RRULE, EXDATE, RDATE, RECURRENCE-ID overrides) into concrete occurrences. Windows time-zone names are mapped to IANA. Price: $0.003 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/ics-parse

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

Input Schema

NameRequiredDescriptionDefault
toNoWindow end (default from + 30 days)
tzNoOutput IANA zone (default the calendar's zone or UTC)
icsNoiCalendar text
urlNoURL of an .ics feed (or use ics)
fromNoWindow start (expands recurring events); ISO 8601
limitNo
descriptionsNoInclude event descriptions (truncated)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations (readOnly/idempotent/non-destructive/openWorld), the description adds SSRF-safety, per-call pricing ($0.003 USDC via x402 on Solana), and an HTTPS endpoint. These disclose auth/payment and security traits the annotations do not cover.

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?

Dense but front-loaded, with purpose first and expansion behavior, output fields, and pricing layered in logically. It is long but nearly every sentence carries distinct information, though the pricing/endpoint sentence could be trimmed for some audiences.

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

Completeness5/5

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

No output schema exists, yet the description enumerates the return fields (calendar name/zone, event start/end, all-day flag, location, organizer, attendee count, status, Rrule) and explains recurrence expansion, leaving nothing critical for a correct call.

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?

With 86% schema coverage the baseline is 3, but the description adds real meaning: from/to acts as an expansion window for RRULE/EXDATE/RDATE/RECURRENCE-ID, and tz/window zone names are mapped to IANA. This goes beyond the schema's terse definitions.

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 (parse) plus resource (iCalendar .ics feed/URL or inline text) and enumerates the JSON output fields. An agent can immediately distinguish it from siblings like ics_generate or rrule_expand.

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?

Explains that from/to expands recurring events and that either url or ics is accepted, giving clear usage context. It does not explicitly name alternatives (e.g., rrule_expand or ics_generate) or state exclusions, so it falls short of a 5.

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