Skip to main content
Glama
Choaterboater

casper-network-mcp

by Choaterboater
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

invoke_read_tool

Read-onlyIdempotent

Run read-only network operations and non-disruptive checks (ping, show) while automatically refusing tools that can change configurations.

Instructions

Run a tool that only reads, or a non-disruptive troubleshooting check (ping, show). Names come from find_tool.

    Cable tests can interrupt a link and require invoke_tool.

    A tool that can change something is refused with "not_a_read_tool".
    cursor: the next_cursor from a reply that was cut short, to get the rest.
    login: a named Central login from access_check (default: the main one).
    all_pages: fetch every page of a list here (up to 50 pages / 10,000 items) instead of one.
    fields: keep only these keys of each item ("radio.channel" reaches inside); cuts big replies.
    group_by: return a count per value of this field instead of the items ("firmwareVersion").
    Together they answer site-wide questions in one call: all_pages + group_by="status".

Input Schema

NameRequiredDescriptionDefault
nameYes
loginNo
cursorNo
fieldsNo
group_byNo
all_pagesNo
argumentsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.6
    • addedInput schema / properties / all_pages
      Added value: +{
+  "default": false,
+  "title": "All Pages",
+  "type": "boolean"
+}
    • addedInput schema / properties / fields
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Fields"
+}
    • addedInput schema / properties / group_by
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Group By"
+}
    • addedInput schema / properties / login
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Login"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the exact refusal error for mutating tools, the link-interruption caveat that routes cable tests elsewhere, and concrete pagination caps (50 pages / 10,000 items). It does not describe error shapes or response structure, keeping it just short of 5.

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?

Purpose and the invoke_tool boundary are front-loaded, followed by compact parameter notes; nearly every line carries information. It is somewhat list-heavy and the pagination/group_by examples could be tighter, but there is little waste.

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 7-parameter, no-output-schema tool, the description covers routing, refusal behavior, paging limits, and field/group_by semantics, plus an example combining all_pages + group_by. The unexplained 'arguments' parameter and absence of response-shape notes leave a modest gap.

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 0%, so the description must carry the burden, and it explains most parameters substantively: cursor as 'next_cursor from a reply cut short', login as a named Central login defaulting to main, all_pages limits, fields with dot-path nesting ('radio.channel'), and group_by with an example ('firmwareVersion'). The 'arguments' parameter is left unexplained, which keeps it from a 5.

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 ('Run a tool that only reads, or a non-disruptive troubleshooting check') and names the source of the name ('Names come from find_tool'). It also explicitly distinguishes itself from the sibling invoke_tool by noting cable tests and mutating tools belong there.

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

Usage Guidelines5/5

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

Gives explicit routing rules: read-only/non-disruptive work uses this tool, while cable tests 'require invoke_tool' and changing tools are 'refused with not_a_read_tool'. The agent knows when to use this tool and when to use the alternative, without inference.

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

Deploy Server

Other Tools