Skip to main content
Glama

add_import

Add a complete import line to a source file, skip exact duplicates, and place it in the correct sorted import group. Use when importing something not yet present.

Instructions

Add an import line, skipping an exact duplicate. It goes into the group of imports it belongs with (same package, standard library or not, relative or not), at its sorted place when the group is sorted, else after the group's last import. A comment heading the group stays first (a next-line directive stays on its import), and so do Python from __future__ imports. With no fitting group it goes after the last import, and a first import after the preamble.

Use this when: importing something the file does not import yet. Don't use this when: adding a name to an existing import (add_import_name).

Example: import_text="from typing import Optional"

Input Schema

NameRequiredDescriptionDefault
file_pathYesAbsolute path to the source or config file.
import_textYesComplete import line in the file's language (e.g. 'import os', '#include <stdlib.h>'); in Go a bare spec ('"fmt"') works too.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.2.0
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
    • addedInput schema / properties / import_text / description
      Added value: +"Complete import line in the file's language (e.g. 'import os', '#include <stdlib.h>'); in Go a bare spec ('\"fmt\"') works too."
  2. First observedv2.0.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the safety profile (writes, non-destructive, not open-world); the description adds substantial context beyond that: deduplication of exact duplicates, group placement rules (same package / stdlib / relative), sorted-position vs. after-group fallback, comment headings and next-line directives preserved, `from __future__` pinned first, and the empty-file/preamble case. That is exactly the kind of placement and preservation detail the annotations cannot convey.

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?

Front-loaded with purpose, then placement semantics, then when/when-not, then an example. Every sentence about placement or preservation earns its place; the block is long but not padded. Minor deduction because the routing guidance is buried at the end rather than up front.

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

Completeness5/5

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

An output schema exists and parameters are fully covered by the schema, so the description need only explain selection and placement behavior — which it does comprehensively, including the fallback cases. Nothing an agent needs to call it correctly is missing.

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?

Schema description coverage is 100% and both parameters are fully documented (file_path, import_text with language-specific examples). The description's example ('from typing import Optional') largely restates what the schema already shows, so no meaningful meaning is added beyond structured fields. Baseline 3 applies.

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 ('Add an import line') plus a key behavioral qualifier ('skipping an exact duplicate'), and explicitly names the sibling it is not (add_import_name). An agent can distinguish it from add_import_name and remove_import without opening a schema.

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?

Explicit 'Use this when: importing something the file does not import yet' and 'Don't use this when: adding a name to an existing import (add_import_name)' with the alternative named. Both the selection condition and the exclusion are stated outright.

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