Skip to main content
Glama

update_meta

Destructive

Updates the project's header: title and subtitle (shown at the top of the canvas) and currency (EUR, USD, GBP or CHF — the display currency of the cap table amounts). ONLY the fields provided are written. A new title also becomes the project's name in the project list. It does not rename any block. The project record alone (name, description, colour) is changed by update_project.

Input Schema

NameRequiredDescriptionDefault
titleNoTitle of the project, shown at the top of the canvas; it also becomes the project's name in the project list
currencyNoDisplay currency of the project's cap table amounts (canvas cards, simulator, fundraising package). Default: EUR.
subtitleNoSubtitle shown under the title
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / subtitle / description
      Added value: +"Subtitle shown under the title"
    • addedInput schema / properties / title / description
      Added value: +"Title of the project, shown at the top of the canvas; it also becomes the project's name in the project list"
  2. Changed2 schema fields changed
    • changedInput schema / properties / currency / description
      Previous value: -"Devise d'affichage des montants cap table du projet (cartes canvas, simulateur, dossier de levée). Défaut : EUR."New value: +"Display currency of the project's cap table amounts (canvas cards, simulator, fundraising package). Default: EUR."
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already flag a non-read-only, destructive operation; the description adds real context beyond them by declaring partial-write semantics ('ONLY the fields provided are written') and the cross-object side effect that a new title becomes the project name in the project list. It stops short of covering permission/auth requirements or failure behavior, which the schema's expectedProjectId note touches but the description does not.

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 the mutation scope, then the partial-write caveat, then the sibling routing — a sensible order. Slight redundancy in repeating the title-to-project-name mapping that also appears in the schema, but nothing that wastes a reader's time.

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 4-parameter, zero-required mutation with annotations and full schema coverage, the description supplies what structured fields cannot: partial-update semantics, the title→project-name side effect, and the boundary against update_project. No output schema exists, so no return-value explanation is owed.

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%, so every parameter including the currency enum and expectedProjectId is already documented in structured form. The description restates the currency options and their display scope, adding little beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb plus named resource and enumerated fields: 'Updates the project's header: title and subtitle ... and currency'. It also explicitly separates itself from update_project, so an agent can distinguish the two 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?

States the selection rule directly: use this for header fields (title/subtitle/currency), use update_project for the project record (name, description, colour). It also notes it 'does not rename any block', excluding a mistaken use case.

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.