Find the in-browser converter (if any) that turns one format into another, e.g. from='fbx' to='glb'. Returns the tool URL and notes, all client-side (files never upload). Use for 'how do I convert X to Y'.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| from | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is client-side ('files never upload'), states that it returns a tool URL and notes, and notes that the converter may not exist ('if any'). This provides important behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and example, and contains no redundant information. Every sentence adds value: the first defines the tool's function, the second clarifies usage and a key behavioral trait.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two string parameters and no output schema, the description covers the essential aspects: what it does, how to use it, what it returns, and a privacy-relevant behavior. It could mention error cases or lack of converter, but the 'if any' clause partially covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains that `from` and `to` are formats and gives a concrete example ('fbx' to 'glb'), adding meaning to the otherwise bare string parameters. However, it does not enumerate accepted format values or provide additional parameter details, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds an in-browser converter for turning one format into another, with a concrete example (from='fbx' to='glb'). It also specifies the output (tool URL and notes), distinguishing it from sibling tools like compare_formats or identify_format which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for how do I convert X to Y', giving clear context for when to apply the tool. It does not explicitly mention alternatives or exclusions, but the usage directive is specific and actionable enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
get_definition and identify_format both cover file formats, and identify_format also lists conversions, overlapping with convert_file. However, each tool has a distinct primary purpose (definition lookup vs. file identification vs. conversion discovery), so the boundaries are reasonably clear but not perfect.
All tools use a verb_noun pattern (compare_formats, convert_file, get_company, get_definition, identify_format, list_design_jobs) with the exception of 'search' which is a bare verb. This minor deviation is acceptable.
7 tools is within the ideal 3-15 range. Each tool covers a distinct aspect of the reference domain, from search to specific lookups to job listings, without redundancy.
The server covers the stated domain well: search for full-text, get_definition for terms/technologies/sensors, identify_format and compare_formats and convert_file for file formats, get_company for companies, and list_design_jobs for careers. The only notable gap is a dedicated tool for standards or sensors, but get_definition and search cover them adequately.
