Skip to main content
Glama
IEZhu

Agents-Core

by IEZhu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Write the repository summary

write_repo_summary
Destructive

Persist a repository summary to CLAUDE.md and a fingerprint cache after describe_repo indicates a summary is needed, enabling future reuse.

Instructions

Persist a repository summary after describe_repo returned status='needs_summary'.

Writes CLAUDE.md and the fingerprint cache. Refuses the running installation
and runtime source root before creating a lock, summary or cache file.

Call this with the summary you generated from the prompt and the
repo_hash value from the describe_repo response. repo_path and
workspace_id are optional over stdio; over HTTP pass both back from
that response unchanged.

Returns JSON whose fields depend on status:
  refreshed: {status, action, path, hash, word_count, in_word_budget, summary_preview}
  rejected, protected installation/source root or stale repo_hash: {status, reason}
  rejected, summary failed the sanity check:
    {status, reason, word_count, has_heading, summary_preview}
  error: {status, error}; over stdio a workspace error adds pid, workspace_inputs
    and, from a server the Claude desktop app started, hint

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYes
repo_hashYes
repo_pathNoOptional directory within the caller workspace; defaults to the workspace.
workspaceNoAbsolute path of your working directory, the project this session works in. Pass it whenever you have one: one server can serve several sessions.
workspace_idNoOptional workspace id returned by describe_repo.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv26.10.14+1807

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations (destructiveHint=true, idempotentHint=false) by naming exactly what is written, the lock/summary/cache creation sequence, the refusal conditions, and the stale-repo_hash rejection path. The status-by-status return map discloses failure semantics an agent needs to handle retries correctly, which annotations alone do not convey.

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?

Purpose and precondition are front-loaded, but a substantial trailing block enumerates the JSON return shape field-by-field even though an output schema already exists, making that section largely duplicative. The content is informative but oversized for a tool whose return contract is already machine-described.

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?

For a mutation tool with annotations, an output schema, and transport-dependent parameters, this covers everything needed: precondition, required inputs and their source, refusal cases, and status-dependent outcomes. Nothing an agent requires 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.

Parameters4/5

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

Schema coverage is 60%, and the description compensates by explaining repo_hash provenance, that repo_path and workspace_id are optional over stdio, and that both must be echoed unchanged over HTTP. The 'summary' parameter still carries no schema description and only a light hint ('the summary you generated from the prompt'), leaving its expected format/word budget implicit.

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 ('Persist a repository summary'), names the concrete artifacts written ('CLAUDE.md and the fingerprint cache'), and ties itself to its sibling describe_repo via the precondition. An agent can immediately distinguish this write counterpart from describe_repo without opening either 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?

Gives an explicit trigger condition ('after describe_repo returned status=needs_summary'), states what must be supplied and its provenance ('the summary you generated from the prompt and the repo_hash value from the describe_repo response'), and rules out invalid targets ('Refuses the running installation and runtime source root'). It also spells out transport-dependent parameter passing over stdio vs HTTP.

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