7IT Solutions

List 7IT Field Kits

list_field_kits

Read-onlyIdempotent

Use this when someone wants a working checklist for a technical job (webhooks, store speed, integrations, migrations, AI in production, security). Lists 7IT Field Kits: working checklists for custom software, eCommerce, automation, payments, AI, security and reliability work (for example webhook reliability, store speed audits, integration design, SEO-safe migrations, LLM production readiness). Each has a title, a one-line purpose, the number of checks and a link. Optionally filter by a topic word.

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

Input Schema

Name	Required	Description	Default
`topic`	No	Optional word to filter by, for example "shopify", "webhook" or "AI".

Output Schema

Name	Required	Description	Default
`kits`	Yes	Matching kits; pass a slug to get_field_kit

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 1, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "kits": {
+      "description": "Matching kits; pass a slug to get_field_kit",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "checks": {
+            "type": "number"
+          },
+          "purpose": {
+            "type": "string"
+          },
+          "slug": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "slug",
+          "title",
+          "purpose",
+          "checks",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "kits"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 1, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

First observedSep 30, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds the item shape (title, one-line purpose, check count, link) and the optional topic filter, but that is largely output detail that the output schema already carries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The usage trigger is front-loaded well, but the "working checklists" framing is repeated across two sentences and the domain list is enumerated twice in adjacent clauses, which pads rather than clarifies.

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 single-optional-param read-only listing tool with a full output schema and rich annotations, the description supplies enough context to call it correctly. The only missing piece is explicit routing against get_field_kit.

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

Parameters3/5

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

Only one optional parameter and schema description coverage is 100%; the schema already documents topic with examples ("shopify", "webhook", "AI"). The description's "Optionally filter by a topic word" adds nothing beyond what the schema states, so the baseline 3 applies.

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 states a specific verb (Lists) plus resource (7IT Field Kits) and enumerates the domains covered. It differentiates itself from most siblings but never explicitly distinguishes itself from get_field_kit, the obvious single-item counterpart.

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?

"Use this when someone wants a working checklist for a technical job" gives a clear triggering condition with concrete examples. It stops short of naming when not to use it or pointing to get_field_kit for retrieving an individual kit.

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

All 7IT Solutions tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?