Skip to main content
Glama
Sign In
itr-agent

itr-agent

by panchasarapavan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

detect_schedules

Detect required schedules (FA, FSI, TR) from foreign trades and AIS entries to identify which income-tax schedules must be filed.

Instructions

Detect required schedules (FA, FSI, TR) from foreign trades and AIS entries.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. "Detect" implies a read-only derivation with no mutation, but the description never confirms that, nor mentions side effects, permissions, or whether results are persisted; only the presence of an output schema limits the risk of misuse.

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?

A single front-loaded sentence with no filler; verb, output, and data sources all appear immediately. Nothing in it is redundant.

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?

Because an output schema exists, return values need not be explained, and zero parameters keep the calling surface simple. What remains missing is prerequisite context (that trades and AIS must be ingested first) and a gloss on what FA/FSI/TR schedules are, which the agent needs to judge relevance.

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?

The tool takes zero parameters, so the baseline is 4. The description adds what it is worth adding by identifying the implicit data sources it operates over, since the empty schema gives the agent no other clue about inputs.

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?

States a specific verb ("Detect") and resource ("required schedules"), and goes further by naming the concrete schedule codes (FA, FSI, TR) and the input sources (foreign trades, AIS entries). That distinguishes it well from siblings like compute_tax or ingest_ais, though the acronyms themselves are unexplained.

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

Usage Guidelines3/5

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

The phrase "from foreign trades and AIS entries" implies the tool only makes sense after trade and AIS data exist, but the description never says that explicitly or names a prerequisite tool such as ingest_trades/ingest_ais. There is no when-not-to-use guidance or comparison to alternatives like compute_tax.

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