Skip to main content
Glama

Save the profile

save_profile

Saves a synthesized profile derived from evidence so refs to nonexistent entries are dropped, then returns the stored profile plus instructions for expanding the repository search.

Instructions

Save the profile JSON written from get_evidence. Refs that do not exist are dropped. Returns the profile and the instructions for the search expansion.

Input Schema

NameRequiredDescriptionDefault
synthesisYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false and openWorldHint=false, so the mutation/closed-world profile is known. The description does add real value: it warns that non-existent refs are silently dropped (a data-modifying behavior an agent must anticipate) and states what is returned despite there being no output schema. It omits overwrite semantics, persistence scope, and failure behavior, which are the main remaining risks for a write tool.

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?

Three short sentences, front-loaded with the action, then the caveat about dropped refs, then the return value. Every sentence carries distinct information and nothing is padded.

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?

Given a nested opaque object parameter, no output schema, and a mutation, the description covers the source of the payload and the return value reasonably. It still leaves the agent guessing at the accepted JSON shape and at whether a prior profile is replaced, which matters for correct invocation.

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?

There is a single required parameter, "synthesis", typed only as a bare object with 0% schema description coverage and no declared properties, nested-object structure being the only hint. The description's pointer to get_evidence as the source of the JSON is the sole semantic aid, and it gives no field names, required keys, or shape for the profile object it expects.

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 and resource ("Save the profile JSON") and ties the payload's origin to the sibling tool get_evidence, which distinguishes it from save_expansion and save_recommendations. It stops short of saying what a "profile" actually contains, but the action is unambiguous.

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?

"written from get_evidence" implies the correct workflow order (call get_evidence first, then save), which is useful implied guidance. However, it never states when not to use it, whether it replaces or appends to an existing profile, or how it relates to show_profile and save_expansion.

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