Skip to main content
Glama

Deliver aspects

deliver_aspects

Describes adaptations for alternative aspect ratios or, with an explicit apply value, rewrites the edit for one selected aspect. Layouts, overlays and text are re-solved while preserving source-space crop aim.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "deliver_aspects"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNo
ratiosNo
project_idYesExplicit project identifier for this request. The connection's navigation pointer does not select the target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Required immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess."New value: +"Explicit project identifier for this request. The connection's navigation pointer does not select the target."
  2. Added

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: layouts, overlays and text are re-solved and source-space crop aim is preserved during the rewrite. It stops short of saying what happens to existing overlays/text (replaced? adjusted?), whether the rewrite is reversible, or what the non-apply mode returns.

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?

Two tightly packed sentences with the default mode stated first and the mutating mode second, so it is front-loaded and free of filler. Some compression jargon ('re-solved', 'source-space crop aim') costs a little immediate intelligibility.

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 a non-destructive but non-idempotent mutation tool with no output schema and only 33% schema coverage, the definition covers the essential behavior but leaves gaps: the ratio string format, what 'apply' accepts, and what the describe-mode returns. Annotations carry the safety story, which keeps this adequate rather than deficient.

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 coverage is only 33% — only project_id is documented — so 'apply' and 'ratios' rely on the description. It clarifies that 'apply' is an optional value selecting one aspect for the rewrite, which is meaningful, but it never explains the accepted format of 'ratios' (e.g. '9:16') or of 'apply', leaving the two undocumented parameters underspecified.

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?

The description names a concrete operation on a concrete resource: computing adaptations for alternative aspect ratios, and optionally rewriting the edit for one selected aspect. It distinguishes its two modes clearly enough to act on, but the verb 'describes' is ambiguous about whether it returns a report or produces a change, and it does not differentiate itself from siblings such as add_aspect_shift, apply_format_pack or auto_reframe.

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?

It implies a mode split: omit 'apply' to preview adaptations, supply 'apply' to commit one aspect. That is real usage guidance, but there is no explicit statement of when this tool should be chosen over add_aspect_shift, remove_aspect_shift, apply_format_pack or render_variants, and no prerequisites or warnings about the rewrite.

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.