Skip to main content
Glama

Update education

update_education
DestructiveIdempotent

Edit an education entry on your Himalayas profile by id (get_my_profile lists the ids). Only the fields you pass change. Uses the connected Himalayas account; no extra sign-in needed.

Input Schema

NameRequiredDescriptionDefault
idYesEducation id
fieldNoField of study
gradeNo
degreeNo
schoolNo
currentNoCurrently enrolled
end_yearNo
activitiesNo
sort_orderNoPosition on the profile, 0 first
start_yearNo
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=true), so the description's burden is lighter. It still adds real value beyond them: 'Only the fields you pass change' discloses partial-update semantics and 'Uses the connected Himalayas account; no extra sign-in needed' discloses auth context. It does not explain why destructiveHint is set, but this is a strong additive disclosure for an annotated 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, with each sentence carrying distinct information (action+id, id source, partial-update semantics, auth context). No filler.

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?

For an 11-parameter mutation tool with 36% schema coverage and no output schema, the description covers the essentials (id source, partial update, auth) but leaves most parameter semantics undocumented. Adequate to invoke correctly for the id, but thin for the optional fields.

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?

Schema description coverage is only 36%, so the description must compensate for the bulk of parameters. It clarifies the required id and its source (get_my_profile) and the partial-update behavior, but says nothing about the ten other fields (field, degree, school, grade, current, activities, sort_order, start/end year, description), most of which lack schema descriptions.

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 (Edit) and resource (an education entry) scoped to the user's Himalayas profile, clearly differentiated from add_education/delete_education siblings. An agent can identify the operation without opening the schema.

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

Usage Guidelines4/5

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

Provides a concrete routing hint for the required id ('get_my_profile lists the ids'), which is clear usage context. It does not explicitly state when to prefer this over add_education or delete_education, so it stops short of full when/when-not guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources