Skip to main content
Glama
Sign In
Errorbook MCP

Errorbook MCP

by stardustlil
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

管理复习 PDF

list_exports

List historical export files with their existence status, preserving problem scheduling state. Use to audit past exports without side effects.

Instructions

列出历史导出文件及其是否仍存在，不会改变题目调度状态。

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_exports"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the transparency burden. It explicitly discloses a key behavioral trait: it does not change scheduling state. It also indicates the output includes existence status. However, it does not mention other potential behaviors such as pagination or performance implications.

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

Conciseness5/5

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

The description is a single, concise sentence that front-loads the main purpose and adds a useful non-mutation caveat. There is no unnecessary filler or repetition.

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?

The tool is simple, but the description leaves gaps: no usage alternatives, no parameter semantics, and only partial return information. The output schema (if present) may cover return details, but the description alone does not make the tool fully self-explanatory.

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?

The schema provides limit and offset parameters with defaults but no descriptions (0% coverage). The description does not mention pagination or explain how these parameters affect results, leaving the agent to rely on parameter names alone. This is a clear gap for a list operation.

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 clearly states the tool lists historical export files and their existence status, using a specific verb (list) and resource (exports). It is distinct from sibling delete_export and get_export_status in being a plural list, though it does not explicitly name alternatives. The title is broader but the description is precise.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The non-mutation caveat hints at safe usage, but the description does not mention cases where other tools like get_export_status or delete_export would be more appropriate.

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