Ink/Stitch MCP Bridge

by GreerBK

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: import, list resources, health check, export, transform, validate, generate lettering, etc. No two tools have overlapping purposes; even similar tools like preview_stitch_plan and render_png_preview are clearly differentiated by output (SVG layer vs PNG image).
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun or verb_noun_noun pattern, with clear action and target. Examples: import_embroidery, list_fonts, set_element_params, etc. No mix of conventions.
Tool Count4/5
With 21 tools, the server covers a broad range of embroidery design workflows. While slightly above the typical 3-15 range, each tool serves a distinct purpose and the count feels justified for the domain.
Completeness5/5
The tool set covers the full lifecycle of embroidery design: importing, inspecting, modifying, generating, validating, previewing, exporting, and housekeeping. Obvious gaps like creating elements from scratch are handled by the SVG-first workflow.
Average 3.5/5 across 21 of 21 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions 'annotate' but does not specify side effects like file modification, overwrite behavior, or required permissions. The output_svg_path parameter suggests optional output, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but extremely brief. It could be improved by front-loading key details about parameters and behavior while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is severely incomplete. It fails to provide essential context about parameters, output, or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage, yet the tool description provides no explanation of any parameter (e.g., indicator_size, num_neighbors_red). Without additional context, the agent cannot understand parameter semantics.
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?
The description clearly states the tool's purpose: annotating an SVG with a stitch-density heat map layer using red/yellow/green markers. It distinguishes itself from sibling tools by being focused on density visualization, which is unique among the listed sibling tools.
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 guidance on when to use this tool versus alternatives. With 20 sibling tools, there is no mention of use cases or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'returning it to a plain vector design' but does not clarify whether the operation is destructive (modifies in-place), what error conditions exist, or how the output is handled. The 'strip' action implies mutation, but safety context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it lacks structure. It does not break down information into readable parts (e.g., parameters, usage, effects). While every word contributes, the density of information is low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no output schema, and no annotations, the description is severely incomplete. It does not describe return values, parameter options, or behavioral nuances. An agent would need additional information to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 5 parameters. The description only hints at 'parameters and command symbols', corresponding to 'remove_params' and 'remove_commands', but fails to explain 'remove_print_settings', 'output_svg_path', or 'svg_path'. The agent cannot infer parameter semantics from the description alone.
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?
The description uses a specific verb ('Strip') and clearly identifies the resource ('Ink/Stitch parameters and/or command symbols from an SVG'). It explains the tool's purpose unambiguously and distinguishes it from siblings like 'cleanup_document' by focusing on embroidery-specific data removal.
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?
The description implies usage when converting an SVG with embroidery settings to a plain vector design, but it does not mention when to avoid using it (e.g., when retaining embroidery data) or compare it to similar tools like 'cleanup_document'. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states 'Read' implying no mutation, but omits details on error handling (e.g., invalid svg_path or ids), return format, or any side effects. Basic operation is implied but not fully transparent.
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?
The description is a single sentence with no wasted words. It efficiently conveys the core functionality, but could benefit from a bit more detail on parameters without becoming overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values. It does not describe the structure or content of the parameters returned. With 0% schema coverage and no output schema, the description leaves significant gaps for the agent.
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 coverage is 0%, so description should clarify parameter semantics. It explains the 'ids' parameter's dual behavior (all vs specific), but does not describe 'svg_path' at all, leaving its purpose and format unclear.
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?
The description clearly states the tool reads Ink/Stitch parameters from SVG elements, with a specific verb 'Read' and resource 'SVG elements'. It distinguishes from sibling tools like set_element_params (write) and list_known_params (lists all known parameters, not per element).
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?
The description mentions filtering by ids, but gives no guidance on when to use this tool vs alternatives like list_elements or list_known_params. No explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions adding a layer and mode options but does not state side effects (e.g., whether the SVG is modified in place or a copy is created), permission requirements, or effects on original data. The output_svg_path parameter hints at output behavior, but this is not explained.
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?
Extremely concise with only one sentence plus a mode hint. No wasted words, but could benefit from a brief structure or list to improve scannability. The core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value (likely the modified SVG or a path), the effect of 'layer_visibility', or the purpose of 'render_jumps' and 'needle_points'. Agents are left with many unknowns.
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 coverage is 0%, so the description must compensate. It only adds meaning for 'mode' by listing two values ('simple' or 'realistic-vector'). Other parameters like 'svg_path', 'render_jumps', 'needle_points', 'output_svg_path', and 'layer_visibility' are not described, leaving agents to infer from names and defaults.
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?
The description clearly states the tool adds a rendered stitch-plan layer to an SVG, specifying what will be sewn. It distinguishes from siblings like 'render_png_preview' (renders PNG) and export tools by focusing on a specific visualization. The verb 'add' and resource 'rendered stitch-plan layer' are precise.
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 guidance on when to use this tool vs alternatives (e.g., 'render_png_preview' for bitmap previews, 'design_stats' for analysis). Does not mention prerequisites or conditions for effective use, such as requiring an existing stitch plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses removal of objects and dry run mode, but with no annotations, it misses details on whether the operation is reversible, what the default output path behavior is (in-place or to output_svg_path), and how thresholds are applied.
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?
The description is extremely concise—two sentences that front-load purpose. Every word is necessary; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description fails to provide sufficient context for proper tool invocation. Missing parameter explanations and return value info make it incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains only the 'dry_run' parameter. Other 9 parameters (thresholds, flags, paths) are not described, leaving the agent without meaning for most options.
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 clearly states the tool removes tiny/empty objects that cause thread breaks, using a specific verb (remove) and resource (document). While it doesn't explicitly distinguish from siblings, the embroidery context makes it distinct.
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?
The description mentions dry_run behavior and default, implying usage for inspecting removals before committing. However, it lacks guidance on when not to use this tool vs alternatives like transform_elements or remove_embroidery_settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It hints at a read-only report but does not explicitly state whether it modifies the design, requires authentication, or affects state. For a simple report tool, this is insufficient.
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?
The description is a single sentence with no fluff, but it lacks structure. It is concise but could benefit from bullet points or clearer separation of output fields.
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?
Given the tool's simplicity and presence of an output schema, the description mentions key output fields but omits details like the exact format (e.g., plain-text lines) and any tool constraints (e.g., file must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the 'svg_path' parameter beyond its name. It fails to clarify whether the path is local or remote, required format, or any constraints.
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?
The description clearly states it generates a 'Plain-text thread/color report' for an SVG design, listing design size, stitch counts, and thread order. This distinguishes it from sibling tools like design_stats or density_map.
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?
The description implies it should be used when a text report of threads/colors is needed for an SVG design, but it lacks explicit guidance on when not to use it or how it compares to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns structured errors/warnings, but does not disclose if it modifies state, requires auth, or has rate limits. Adequate but not comprehensive.
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?
Single sentence, no fluff, front-loaded with the core action and output summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should cover more. It fails to explain parameters, return structure details, or behavior beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not explain the svg_path, show_errors, show_warnings, or show_type_warnings parameters. It adds no meaning beyond the schema.
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?
Description clearly states the tool validates embroidery elements and returns structured errors/warnings with positions and suggested fixes. It's a specific verb-resource pair, distinguishing it from sibling tools like health_check or cleanup_document.
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 guidance on when to use this tool versus alternatives like health_check or cleanup_document. There is no mention of conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read operation but does not explicitly state non-destructiveness, required permissions, or error handling (e.g., invalid file).
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?
The description is a single sentence that efficiently conveys what the tool does and what outputs to expect. No unnecessary words.
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 tool with one parameter and no output schema, the description lists the output metrics but lacks details on return format, error behavior, or whether it modifies state. It is adequate but not fully complete.
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 coverage is 0%. The description does not elaborate on the file_path parameter (e.g., format, constraints). It only implicitly references it via 'machine embroidery file'.
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?
The description clearly states it provides stitch statistics for a machine embroidery file, listing specific metrics (stitch/jump/trim counts, color changes, threads, size in mm). This distinguishes it from sibling tools like density_map or preview_stitch_plan.
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?
The description gives no guidance on when to use this tool versus alternatives (e.g., troubleshoot, density_map). It does not provide any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It describes what is returned but does not explicitly state that the tool is read-only, idempotent, or non-destructive. These traits are implied but not confirmed.
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?
The description is a single sentence of 15 words, front-loaded with the action and outcomes. No redundant information. Perfectly sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the output structure or format. It does not, and it also lacks clarity on what constitutes an 'embroiderable element' or any limitations. The tool is simple, but the description leaves the agent guessing about the response shape.
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 0%, so the description must compensate. It mentions 'SVG' in the description, hinting at the svg_path parameter, but does not describe its format (e.g., file path vs. URL) or any constraints. The list of returned data adds some semantic value.
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 verb 'Inventory' clearly indicates a listing operation. The description specifies exactly what is listed (ids, labels, stitch type, existing params), which distinguishes it from siblings like get_element_params or set_element_params. However, it could be more explicit about the tool's role in the workflow.
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?
The description provides no guidance on when to use this tool versus alternatives like get_element_params. No usage context, prerequisites, or exclusions are mentioned, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior but only partially does. It describes operations and mentions saving the result, but it does not clarify whether the tool overwrites files, requires permissions, or handles errors. Key behavioral traits like file modification are ambiguous.
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?
The description is concise and front-loads the purpose. The list of operations is compact, though the abbreviations could be clearer. Overall, it is economical with words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 5 parameters, no schema descriptions, no output schema, and no annotations, the description is incomplete. It lacks details on input/output paths, error conditions, and default behaviors, leaving gaps for an agent.
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 coverage is 0%, so the description must explain parameters. It covers operation (with examples), ids (usage note), and options (example). However, svg_path and output_svg_path are not described at all, missing essential semantics.
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?
The description clearly states 'Apply an Ink/Stitch conversion to SVG elements and save the result.' It lists specific operations and distinguishes itself from siblings like list_elements and set_element_params.
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?
The description mentions that ids is required for all but jump_to_stroke and suggests getting them from list_elements. However, it does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds that conversion is 'direct' and format is from extension, but fails to disclose potential issues like overwriting, supported formats, permissions, or error handling. Minimal behavioral context beyond basic operation.
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?
Two sentences with zero wasted words. The core action is front-loaded, followed by a clarifying example and a crucial detail about format inference. Every sentence serves a purpose.
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?
The description minimally covers the tool's function given its simplicity (2 string params, no output schema). However, it lacks completeness on return values, error cases, and format support, leaving gaps for an agent to fully understand tool behavior.
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 0%, so description must explain parameters. It provides no per-parameter details; only indirectly clarifies input_path and output_path via the example. The agent gains little extra meaning beyond the schema field names.
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?
The description clearly states the verb 'convert' and the specific resource 'machine embroidery file', with an explicit example (dst to pes) that distinguishes it from sibling tools like import/export or listing formats. The note about format taken from output extension adds precision.
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?
The description implies when to use (to change format), but does not explicitly state when not to use or mention alternatives like list_formats or import/export. No exclusion criteria or context for agent to differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral burden. It indicates a read-convert-write operation without side effects on input, but omits details like required permissions, error behavior, or whether it modifies the original file. Some transparency is provided via input format list but not comprehensive.
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?
The description is a single, clear sentence that efficiently conveys purpose. However, it could briefly mention output path without harming conciseness. Still, no unnecessary words.
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?
Given no output schema, no annotations, and 0% schema coverage, the description provides adequate high-level purpose but lacks details on return values, error conditions, or parameter behaviors. It is minimally complete for a simple tool.
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 coverage is 0%, so description must compensate. It implies file_path is the embroidery file and mentions output is SVG, but does not describe output_svg_path's role or default behavior. Both parameters lack explicit semantic explanation beyond the schema itself.
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?
The description clearly states the tool converts machine embroidery files to SVG stitch plans, listing common input formats and noting editability in Inkscape. This verb-resource pair is specific and distinguishes it from siblings like export_embroidery or render_png_preview.
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?
The description implies use when an SVG stitch plan is needed, but lacks explicit when-to-use, when-not-to-use, or alternatives among siblings like preview_stitch_plan or convert_machine_format. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must handle behavioral disclosure. It mentions that SVGs are compiled first, which is useful, but does not state whether the tool is read-only, modifies any files, or has side effects. Additional context about safety would improve score.
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?
The description is extremely concise with two short sentences, front-loading the key purpose. Every word adds value with no redundancy.
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?
Given the tool's simplicity (2 params, no output schema), the description covers the core purpose and input types. However, it omits details about the output format, error handling, and the optional output_png_path parameter, which are important for reliable invocation.
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?
With 0% schema description coverage, the description should compensate. It only indirectly mentions file_path by describing accepted input types. The output_png_path parameter is not described at all, leaving its purpose and default behavior unclear.
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?
The description clearly states the action (render), resource (PNG preview of design's stitches), and input types (machine file or SVG). It distinguishes from siblings like export_embroidery or preview_stitch_plan by focusing on raster preview output.
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?
The description implies when to use (when a PNG preview is needed) but does not provide guidance on alternatives like preview_stitch_plan or when not to use this tool. No explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses the panelization feature (x/y_repeats, spacing) but omits whether the operation is destructive, required permissions, or error behavior. Adds some context but lacks safety profile.
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?
Two sentences with no wasted words. The main action and key features (panelization) are front-loaded. Perfectly concise.
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?
Given 8 parameters, no output schema, and no annotations, the description covers the core export and panelization but omits output path customization and file name. It is adequate but not fully complete for a tool with this complexity.
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 0% in the schema itself, but the description explains the formats array and panelization parameters. However, it fails to describe svg_path, output_path, and custom_file_name. The explanation adds meaning for covered params but missing for 3 out of 8.
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?
The description clearly states the tool exports SVG designs to multiple formats as a ZIP, with explicit examples (e.g., ["dst","pes","svg","threadlist"]). It distinguishes from siblings like export_embroidery which handles single formats.
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?
The description implies use when multiple formats or panelization is needed, but does not explicitly state when not to use it or mention alternative tools (e.g., export_embroidery, convert_machine_format). Guidance is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It mentions returning stitch statistics and default output path, but does not disclose file overwrite behavior, error handling, or permission requirements.
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?
Two concise sentences with key information front-loaded. No redundant or unnecessary text.
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?
With 3 parameters and no output schema, description covers core function and one parameter default. Lacks details on laser_mode, return format of stitch statistics, and potential errors. Adequate but not comprehensive.
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 coverage is 0%, so description should compensate. It explains output_path default but not laser_mode, and svg_path is self-explanatory. Minimal added value beyond schema.
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?
The description clearly states the verb 'Compile' and resource 'SVG design into a machine embroidery file', lists output formats, and distinguishes from siblings like import_embroidery and convert_machine_format.
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 clear default behavior for output_path, implying usage context. However, lacks explicit when-to-use or alternative tool guidance, which is partially mitigated by context signals like sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states what is listed, not behavioral traits like read-only nature, authentication needs, or rate limits.
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?
Single sentence, front-loaded with action and resource, no wasted words.
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?
Adequately complete for a simple listing tool with no parameters, but lacks mention of return format or ordering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 applies as description does not need to add parameter details.
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?
The description uses specific verb 'list' and resource 'legal Ink/Stitch per-element parameter name', clearly distinguishing from sibling tools like set_element_params which modifies.
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?
The description implies usage before set_element_params, but lacks explicit when-to-use or when-not-to-use guidance and does not mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states the tool verifies readiness and that the smoke test exports a design and takes a few seconds. It does not describe potential failure modes, return values, or side effects beyond the time cost, leaving some gaps.
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?
The description is two sentences long, front-loaded with the main purpose, and every word serves a purpose. No filler or redundant information.
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?
Given the tool's low complexity (one optional boolean parameter, no output schema), the description covers the core functionality and parameter behavior. It could be enhanced by briefly indicating the output/return value, but it remains fairly complete for a health check utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by explaining that with run_smoke_test=True, the tool exports a tiny test design end-to-end and notes it takes a few seconds. This adds context beyond the boolean type, though it omits explicit mention of the default behavior (no smoke test means just checking readiness).
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?
The description clearly states the verb 'Verify' and the resource 'Ink/Stitch toolchain', listing the components checked (venv, checkout, fonts, pystitch). It differentiates from sibling tools which focus on import, export, listing, etc.
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?
The description implies the tool is for checking toolchain readiness. It explains when to use the optional smoke test parameter (to run an end-to-end test). However, it does not explicitly state when not to use this tool or mention alternatives, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool overwrites the input SVG unless output_svg_path is provided, a critical destructive behavior. It also specifies boolean and millimeter value formats. However, it does not mention error handling, idempotency, or whether multiple calls accumulate changes. Still, the key behavioral trait is covered.
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?
The description is a compact paragraph with the purpose upfront, followed by details. It avoids redundancy but could be slightly better structured (e.g., bullet points for parameter guidelines). Every sentence adds information, and it is reasonably concise for the complexity.
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?
Given no output schema, no annotations, and a complex object parameter, the description covers purpose, parameter usage, and a key behavior (overwrite). However, it does not describe the return value (likely success indicator or modified SVG) or error conditions (e.g., invalid param names, missing elements). For a mutation tool, these are notable omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the updates parameter structure (element id -> {param: value}) and that null removes a param. It lists example param names from list_known_params. It clarifies the output_svg_path role. But it does not explain the svg_path parameter beyond being required, leaving a small gap. Overall, adds significant meaning beyond the schema.
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?
The description clearly states the tool's action: 'Set or remove Ink/Stitch stitch parameters on SVG elements.' It uses a specific verb ('set or remove') and identifies the resource (SVG elements with stitch parameters). It distinguishes itself from siblings like get_element_params (read) and list_known_params (list valid param names).
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?
The description explains how to use the updates parameter: maps element id to param-value pairs, with null to remove. It also mentions that param names must come from list_known_params, giving examples. It notes the overwrite behavior with output_svg_path as a safeguard. However, it does not explicitly compare to other mutation tools like transform_elements or cleanup_document, lacking explicit when-not alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. While 'list' implies a read-only operation, the description does not explicitly state it is non-destructive, does not mention any side effects, caching, or rate limits. It adds the specific fields returned, which is helpful, but overall transparency is minimal.
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?
The description is a single sentence, front-loaded with the action and resource, and every word provides value. There is no wasted text.
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 tool with no parameters and no output schema, the description sufficiently explains what the tool returns (name, scale limits, description). The purpose is fully covered, and the agent can correctly use the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so per rules the baseline is 4. The description adds no parameter meaning because none exist, but it correctly implies no inputs are needed. Schema coverage is trivially 100%.
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?
The description uses a specific verb ('list') and a clear resource ('embroidery lettering fonts'), and distinguishes itself from sibling tools like generate_lettering by noting these fonts are available for that tool. The fields returned (name, scale limits, description) are listed, eliminating ambiguity.
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?
The description implies usage before generate_lettering by stating the fonts are 'available to generate_lettering'. This gives context for when to use the tool, though it does not explicitly mention when not to use it or compare to other siblings. For a simple list tool, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 correctly discloses that the tool lists formats (a read-only, non-destructive operation) with no side effects. It does not detail return format or side effects, but given the tool's simplicity (no parameters, no mutations), this is adequate. A high score is justified as there are no hidden behaviors.
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?
The description is a single sentence that front-loads the action and resource, with parenthetical examples. Every word earns its place; there is no redundancy or filler. It is concise yet fully informative.
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?
Given the tool has no parameters, no output schema, and no annotations, the description provides all necessary context: it lists readable/writable formats and names examples. No additional details are required for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (no parameters to describe). The baseline for 0-param tools is 4. The description adds no parameter info, but none is needed.
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?
The description uses a specific verb 'List' and identifies the resource as 'machine-embroidery file formats Ink/Stitch can read and write', with concrete examples (dst, pes, jef, exp, vp3). This clearly distinguishes it from sibling tools like import_embroidery, export_embroidery, and convert_machine_format, which involve file operations rather than listing.
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?
The description explicitly states the tool lists readable and writable formats, providing clear context for use. While it does not explicitly mention when not to use it, the sibling names (e.g., convert_machine_format) imply that this tool is for informational queries, not conversion. A brief 'when not to use' could elevate the score, but current guidance is sufficient for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses batch semantics (each line becomes separate design), scale_percent clamping, default formats, output directory behavior, and trim/color_sort/text_align options. With no annotations, this fully informs the agent of side effects.
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?
Dense paragraph front-loads purpose then systematically lists parameter details using colons. Every sentence adds value; no fluff.
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?
Given 11 parameters, 0% schema coverage, no output schema, and no annotations, the description covers constraints, defaults, and side effects thoroughly. The only minor gap is undefined numeric parameters, but overall it's remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains font, formats, scale_percent clamping, trim/color_sort/text_align enums, output_dir default, and batch behavior of text. However, numeric parameters like line_height, word_spacing, letter_spacing are only named with defaults, lacking units or interpretation.
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?
Clearly states the tool creates machine-embroidered text using digitized fonts. The verb 'Create' and resource 'machine-embroidered text' are precise. Distinguishes from siblings like import_embroidery and export_embroidery.
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 clear context: font must come from list_fonts, newline-separated lines become separate designs. Does not explicitly exclude other uses or compare to siblings, but the specific nature of lettering implies when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![InkStitchMCP MCP server](https://glama.ai/mcp/servers/GreerBK/InkStitchMCP/badges/card.svg)](https://glama.ai/mcp/servers/GreerBK/InkStitchMCP)

Score Badge

Copy to your README.md:

[![InkStitchMCP MCP server](https://glama.ai/mcp/servers/GreerBK/InkStitchMCP/badges/score.svg)](https://glama.ai/mcp/servers/GreerBK/InkStitchMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GreerBK/InkStitchMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server