Skip to main content
Glama

photext_recommend_tool

Recommend the matching PhoText web tool and provide a link plus steps for editing, replacing, removing, translating, or fixing text in images and PDFs, or identifying fonts.

Instructions

Given a task about text in an image (edit, replace, remove, translate, fix typos, identify a font, PDF text), return the matching PhoText (photext.ai) tool link and steps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesWhat the user wants to do, e.g. 'change the price on this flyer'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait: the tool only returns a link and steps rather than executing the operation, which meaningfully separates it from the executor siblings. However, it says nothing about permissions, supported/unsupported task scope, or failure modes.

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?

One front-loaded sentence with the verb, output, and scope enumeration packed in without filler. Nothing extraneous and nothing buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly states what is returned (a tool link and steps), and with only one required string parameter the surface area is small. Its one gap is the missing routing logic relative to the executor siblings, which matters for a recommender tool.

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% for the single 'task' parameter, so the schema already documents it and includes an example. The description's parenthetical task categories add mild framing but no syntax, format, or granularity guidance beyond the schema. Baseline 3 is appropriate.

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 ('return the matching PhoText tool link and steps') and resource (PhoText tool), and enumerates the task categories it covers (edit, replace, remove, translate, fix typos, font ID, PDF text). The 'recommend' framing distinguishes it from the executor siblings like photext_edit_text_in_image, though it never names them directly.

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

Usage Guidelines2/5

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

No explicit guidance on when to route through this recommender versus calling the specific sibling tools directly — the central ambiguity for a dispatcher tool. The task-type enumeration implies coverage but never states the selection condition or any exclusion.

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