sprinty

by ebursztein

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

search

Find regex matches in sprint text and return each hit with surrounding character context for targeted review.

Instructions

Regex search over sprint text with character context around each match.

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": {
      "pattern": "<pattern>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description	Default
`pattern`	Yes
`agent_token`	No
`context_size`	No
`client_agent_id`	No
`claim_generation`	No
`client_session_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.2.2Oct 23, 2026

addedInput schema / properties / agent_token

Added value: +{
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / claim_generation

Added value: +{
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / client_agent_id

Added value: +{
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / client_session_id

Added value: +{
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

First observedv0.1.9Jun 28, 2026

TDQS

C2.7/5.0

Behavior2/5

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

With zero annotations, the description carries the full burden, yet it only says the search is regex-based. It does not state that the operation is read-only, whether it requires an active claim or agent token, any rate limits, or how much text a default context_size of 512 yields. For a 6-parameter tool with no annotation coverage this is a substantial gap.

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?

A single tight sentence with the most important facts (regex, target, output shape) front-loaded and no filler. It is efficient but so terse that concision shades into under-specification.

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

Completeness2/5

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

Six parameters, four of them auth/session-related, with no schema descriptions, no annotations, and no output schema. The description omits authentication requirements, result format, and match/pagination behavior, leaving an agent unable to call it confidently without guesswork.

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%, so the description must compensate. It conveys only that the pattern is a regex and that context_size controls surrounding characters; agent_token, client_agent_id, client_session_id, and claim_generation are completely unexplained, and even the pattern's required status and matching semantics (global vs first match, case sensitivity) are unstated.

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 operation (regex search), a specific resource (sprint text), and the shape of the result (character context around each match). No sibling offers search, so differentiation isn't needed, but it never states scope (which sprint?) that would let an agent confirm it targets the right data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no statement of when to use this versus reading items/notes via item_get or note_list, and no mention of preconditions such as needing an agent_token or an attached sprint. The agent must infer the usage context entirely.

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