visio-mcp

by Lway-ai

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 resource/action, such as document lifecycle vs page management vs stencil operations vs shape operations. The geometry helpers (measured_pins, pin_point, symbol_bounds) are related but serve clearly different query purposes, so no two tools are ambiguous.
Naming Consistency4/5
Most tools follow a verb_noun pattern (new_document, open_document, list_pages, drop_master, export_page) with consistent style. A few names deviate, such as health_check (object_verb) and measured_pins, pin_point, symbol_bounds (noun/adjective phrases), but the overall pattern is readable and predictable.
Tool Count3/5
With 23 tools, the server feels heavy for a single MCP, though each tool serves a specific purpose within the broad Visio automation domain. The count is above the typical well-scoped range (3-15), but the tools are distributed across document, page, stencil, shape, drawing, and export concerns, so it is borderline rather than excessive.
Completeness3/5
The core workflow of creating, editing, and exporting diagrams is covered well: document CRUD, page management, stencil loading, master placement, drawing wires/labels/junctions, and export. However, there is no general shape property editor (only line weight), no text updating, no move/rotate/group operations, and no fill/color settings, which are notable gaps for a full Visio automation tool.
Average 3.6/5 across 23 of 23 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention that closing may discard unsaved changes, the effect of the 'save' parameter, or any error conditions. This is a significant transparency gap for a potentially destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified. It does not provide necessary context about the save parameter or consequences of closing, making the brevity a deficiency rather than a strength.
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 close operation has side effects and there is no annotation coverage, the description is inadequate. It leaves the agent without knowledge of the save behavior, potential data loss, or when to use it relative to save_document. The output schema may exist, but the description still needs to cover essential behavioral context.
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 schema has one optional boolean parameter 'save' with no description. The tool description says nothing about this parameter, leaving its purpose and effect entirely undocumented. At 0% schema description coverage, the description fails to compensate.
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 'Close' and resource 'current document', clearly distinguishing it from siblings like open_document and save_document. It unambiguously states what the tool does.
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, such as whether to save before closing or what happens to unsaved changes. It does not mention any prerequisite 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, so the description carries full burden. It discloses that the new page is selected, but fails to mention whether a document must already be open, potential errors on duplicate names, or the fact that this is a mutating operation (though 'Add' implies it).
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, front-loaded sentence that is clear and free of fluff. It is appropriately concise for the tool's simplicity, but misses parameter and usage details. This is not a padded description, so it earns a high conciseness score.
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?
The tool has a simple one-parameter schema but no annotations. The description covers the core action but is missing essential context about prerequisites (e.g., an open document) and parameter meaning. It is insufficient for an agent to reliably invoke the tool without guesswork.
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 defines a single required parameter 'name' with no description, and schema description coverage is 0%. The description does not explain the meaning or format of 'name', leaving it completely undocumented.
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 'Add' and resource 'page', and also specifies a secondary behavior 'select it'. This distinguishes it from siblings like select_page (which only selects) and new_document (which creates a document, not a page).
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 is provided on when to use this tool versus opening/creating a document first. It does not mention prerequisites such as an open document, nor does it reference any alternatives 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?
With no annotations, the description must disclose behavior. It only states the action without explaining side effects (e.g., setting the current page), error handling for nonexistent pages, or whether it returns anything. The description is too terse to inform the agent of behavioral consequences.
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 filler, making it highly concise. However, the brevity comes at the cost of missing essential usage and behavioral information.
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?
The tool has one required parameter and an output schema, but the description lacks critical context about prerequisites and effects. It is not complete enough for an agent to understand when and how to invoke it correctly, especially given its role among page-related sibling tools.
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?
The schema defines a single 'name' string parameter with no description. The description's 'by name' clarifies that the parameter is the page name, but it adds no additional semantics such as format, uniqueness, or validation. Given 0% schema coverage, this is minimal compensation.
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 'Select a page by name' clearly identifies the action (select) and resource (page), with the parameter 'name' indicating the selection criterion. This distinguishes it from sibling tools like list_pages and add_page.
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 is provided on when to use select_page versus alternatives. It does not mention prerequisites such as an open document, whether it changes the active page, or how it relates to list_pages/open_document. This leaves the agent without context for appropriate invocation.
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 carry the full burden of behavioral transparency. It only describes the label's visual attributes, not side effects, return values, or integration with the document state (e.g., whether it modifies the current page, whether it is reversible).
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 concise sentence with zero wasted words. It front-loads the core action and resource, making it immediately scannable.
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 tool has 8 parameters, no annotations, and a sparse description, it is not contextually complete. It does not explain what happens after adding a label, how x/y units are defined, or how this fits into the broader document workflow. The output schema exists but does not relieve the need for behavioral and parameter context.
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%, and the description only clarifies the meaning of text, x, and y (centered placement). It does not explain h, w, bold, font, or size, leaving the majority of the 8 parameters undefined. The description adds some value for coordinates but fails to compensate for the lack of schema descriptions.
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 ('Add'), the resource ('centered text label'), and key visual traits ('borderless, transparent') plus placement ('at (x, y)'). This uniquely identifies the tool among siblings like draw_wire and add_junction, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., an open document, a selected page) or exclusions. The description simply states the action without contextual usage 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?
With no annotations provided, the description carries the full burden of disclosure. It does not mention that the deletion is permanent, whether any dependent elements are affected, or what happens if the shape_id does not exist. 'Delete' implies mutation but lacks critical side-effect disclosure.
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, concise sentence that directly states the operation. Every word is necessary, and there is no repetition of schema or annotation information. It is appropriately minimal for a simple delete operation.
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?
Despite low complexity and an output schema, the description omits important behavioral context for a destructive operation. It does not note irreversibility, error behavior, or any prerequisites. A delete tool with no annotations should provide at least a caution or a note on effects, which is missing.
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?
The input schema has 0% description coverage and only defines shape_id as a string. The description's 'by id' adds minimal value because the parameter name already indicates it is an identifier. No additional details about format, scope, or required context are provided.
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 (delete) and the resource (shape) with a specific identifier ('by id'). It unambiguously distinguishes itself from sibling tools like list_shapes or find_shape, as it is the only tool that removes a shape.
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 does not provide any when-to-use guidance beyond the obvious purpose. It does not mention alternatives, prerequisites (e.g., whether the shape must exist), or when not to use this tool. The usage is implied by the action verb, but no explicit contextual guidance is given.
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 carries the full burden of behavioral disclosure. It implies a read-only operation via 'List' and states that shape counts are included, but it does not explicitly state side effects, file access requirements, ordering, or error behavior. This is a minimal disclosure for a tool with no annotation safety net.
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, compact sentence that is easy to scan and contains no filler. It front-loads the primary action and resource, making it appropriately concise for a simple one-parameter tool.
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 tool is simple (one parameter) and has an output schema, so the description does not need to detail return values. It covers the core action and output ('with shape counts'), but it omits contextual details like valid path values, whether the stencil must be loaded, and how this relates to sibling stencil tools. It is minimally viable but leaves notable gaps.
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?
The schema provides only a bare string parameter 'stencil_path' with 0% descriptive coverage. The description mentions 'stencil file' but does not clarify whether the path is filesystem-based, relative, or must match a previously loaded stencil. The parameter meaning is only partially inferred from the description, so it does not adequately compensate for the missing schema documentation.
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') with a clear resource ('masters (symbols) in a stencil file') and an output detail ('with shape counts'). This distinguishes it from sibling tools like list_stencils (lists stencil files) and list_shapes (lists shapes in a 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?
The description gives no guidance on when to use this tool versus alternatives, nor any prerequisites such as loading a stencil first. It does not mention whether stencil_path should be a file path, a loaded stencil name, or something else, leaving the selection and invocation context ambiguous.
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 carries the full burden of disclosing side effects and constraints. It only mentions the return value ('Returns shape_id') but does not indicate that this operation mutates the document, whether the stencil or master must already exist, how errors are handled, or if the action is reversible. For a mutation tool, this is a significant lack of transparency.
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 core action, and contains no unnecessary filler. Every word contributes to understanding the tool's purpose and primary output.
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 tool has 8 parameters and no annotations, the description is too sparse to be complete. It does not explain how optional parameters (angle, flip_x, weight, label) affect the result, any prerequisites (e.g., loaded stencil), or failure behavior. The output schema exists but does not compensate for the lack of operational context.
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 the description must compensate by explaining parameters. It only clarifies x and y ('in inches'), leaving the other six parameters (angle, label, flip_x, master, stencil, weight) unexplained. The term 'stencil master' hints at the relationship between stencil and master, but the description falls far short of documenting the full set of options.
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 ('Drop a stencil master'), the resource ('stencil master'), and the location ('at (x, y) in inches'). It also mentions the return value ('Returns shape_id'), which distinguishes it from sibling drawing tools like draw_wire or add_label. This is specific and unambiguous.
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 for placing pre-defined stencil masters at coordinates, which is distinct from drawing wires or adding labels. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites (e.g., loading a stencil) or exclusions. Guidance is solely implied by the verb and resource.
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 available, the description carries the full burden of behavioral disclosure. It does not specify what 'first' means (ordering), whether matching is case-sensitive, what happens if no shape is found, or whether the operation is read-only. The bare mention of 'find' implies a read, but side effects and edge cases are undisclosed.
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 with no filler words. It front-loads the verb and resource, and every word contributes meaning.
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 tool is simple with one parameter and has an output schema, which may document return values. However, the description leaves ambiguity about the term 'first' (ordering) and does not clarify scope (e.g., current page vs document). This is adequate but has clear gaps.
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?
The schema has a single `text` parameter with 0% description coverage. The description adds meaning by indicating that `text` is the substring to search for in shapes' text ('contains `text`'). This clarifies the parameter's purpose but does not explain formatting, case sensitivity, or matching rules.
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: 'Find the first shape whose text contains `text`.' This has a specific verb (Find), a resource (shape), and a precise search condition. It is distinct from siblings like list_shapes, which presumably lists all shapes.
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 is provided about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or indicate how this relates to list_shapes or other search-like tools. The description gives no context for choosing this tool.
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 carries the full burden. It only states the action without disclosing what happens on success/failure (e.g., file not found, already open, effects on current document state), which is a significant gap even for a simple open operation.
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, efficient sentence that is front-loaded and contains no fluff. It earns its place but lacks additional context that could be added without harming conciseness.
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 tool is simple with one parameter, and an output schema exists (though not shown), so return values are likely covered. However, the description lacks behavioral edge cases and prerequisites, making it only minimally complete for an untrusted agent 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?
The schema has one unannotated parameter 'path' with 0% description coverage. The description provides only the '.vsdx' extension hint, which is minimal compensation. It does not clarify whether the path is absolute/relative, a file system path, or any other format, leaving the agent to guess.
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 ('Open') and the resource ('existing Visio document (.vsdx)'), with the file extension adding specificity. It effectively distinguishes itself from sibling tools like new_document or close_document by focusing on opening existing files.
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 phrase 'existing' implies this tool is for loading a saved file, distinguishing it from new_document. Although it doesn't explicitly name alternatives or exclusions, the context of sibling tools makes the intended use clear.
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 provided, the description carries the full behavioral burden. It conveys that the tool is read-only in spirit ('clearance checks') and specifies units (inches) and scope ('ink bounding box'), which adds useful context. However, it does not disclose possible errors, coordinate-space origin, or whether the returned bounds account for transformations like angle and flip_x, leaving some behavioral ambiguity.
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 concise sentence with a clear, front-loaded definition and a purpose clause. Every word contributes meaning: 'absolute' indicates coordinate space, 'ink' clarifies visual extent, 'inches' gives units, and 'clearance checks' states the use case. No waste.
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?
The tool has five parameters, no schema descriptions, and only this sparse text. While an output schema exists, the description does not clarify the required parameters' semantics or how transformations (angle, flip_x) influence the bounding box. For a geometry tool, this is a significant gap, even though the core behavior is stated.
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 names none of the parameters (x, y, angle, flip_x, master). It does not explain what x/y represent (e.g., insertion point, center), how angle/flip_x affect the result, or what master refers to. The description adds no value beyond the parameter names already present in 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 returns the 'Absolute ink bounding box of a symbol body (inches)', giving a specific resource and measurement unit. The phrase 'for clearance checks — keep wires out of it' distinguishes its intended use from sibling tools like draw_wire and pin_point, making its purpose unmistakable.
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 indicates when to use this tool: for clearance checks and to keep wires out of the symbol bounding box. It does not spell out exclusion criteria or name alternative tools, but the context is clear enough that an agent can infer this is a geometric query rather than a drawing or measurement-pin operation.
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 carries the full burden. It discloses a key behavioral trait (opening a temporary copy if the file is locked) and the return value. Missing are error handling, path requirements, or side effects on the Visio session, but what is provided offers useful context beyond the raw schema.
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, front-loaded with the core action, and every clause adds value. No fluff or repeated schema information.
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 tool is simple with one parameter and an output schema, so the description need not detail return structure. It covers the lock behavior and key return, which is helpful. However, it does not differentiate from open_document or mention prerequisites, leaving some usage context unclear.
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 the description must compensate. It mentions 'file' but does not explicitly define the 'path' parameter beyond its name. The context implies path is the stencil file location, but the description adds minimal meaning beyond the schema's parameter name.
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 ('Open') and resource ('stencil file'), clearly distinguishing it from open_document (documents) and aligning with drop_master. The explicit return value ('stencil key for drop_master') further clarifies the tool's role.
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?
Usage is implied: the description says it returns a stencil key for drop_master, suggesting this is a prerequisite for dropping masters. However, there is no explicit statement of when to use this versus alternatives like open_document or list_stencils, and no exclusions are given.
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 carries the full burden. It adds useful context: units (inches), coordinate type (absolute page), and an example output. However, it doesn't explain prerequisites (e.g., whether a symbol must be placed first), error behavior, or whether the operation has side effects. The phrase 'based on measured geometry' hints at dependencies without specifying them.
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 concise: two sentences plus an inline example. It front-loads the core function, provides a concrete usage example, and avoids unnecessary words. Every sentence earns its place.
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 tool has 6 parameters and no annotations, and the description covers the main use case with an example. However, it omits preconditions (e.g., measured geometry requirements), the meaning of angle/flip_x, and edge cases. An output schema exists but is not shown, and the description doesn't rely on it. Overall, it's adequate for a simple example but lacks depth for robust agent decision-making.
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 0%, so the description must compensate. The example pin_point('NMOS1', 4.3, 6.0, 'gate') illustrates the roles of master, x, y, and pin. However, angle and flip_x are not explained at all, and the description does not explicitly define what x and y represent (e.g., symbol placement coordinates). Thus, it provides partial but incomplete parameter understanding.
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's function: returns the absolute page coordinate (inches) of a symbol pin based on measured geometry. It includes a concrete example with output, making the purpose unambiguous. However, it doesn't explicitly contrast with sibling tools like measured_pins or symbol_bounds, so it lacks explicit differentiation.
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 says 'Use the result as the endpoint of draw_wire so wires land on pins,' which is explicit context for when to use this tool. It does not mention when not to use it or list alternative tools, so it's not fully complete guidance but provides a clear application.
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 carries the full burden of behavioral disclosure. It fails to mention whether saving overwrites an existing file, whether it is destructive, requires specific permissions, or what happens if no path is supplied. This is a significant gap for a mutating 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?
The description is a single, front-loaded sentence with no filler. It communicates the core function and the optional parameter efficiently.
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 tool is simple with one optional parameter, and an output schema exists, which likely covers return values. However, the description lacks essential behavioral context—such as overwrite behavior, error conditions, and whether a document must be open—that would make it fully actionable. It is adequate but incomplete for a tool with no annotations.
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 description explicitly explains the 'path' parameter as optional and as a new save destination, adding meaning beyond the schema's bare type definition. With 0% schema coverage, this compensation clarifies the parameter's role, though it omits details like path format or 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 the operation: save the current document, with an optional new path. This distinguishes it from sibling tools like new_document, open_document, close_document, and export_page by naming the specific action and resource.
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 the tool is for persisting the current document, but it provides no explicit guidance on when to use it versus alternatives like export_page or close_document. It also omits any prerequisites, such as having an open document, leaving usage context to inference.
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 carries the full burden. It discloses the key behavior that the weight applies to sub-shapes as well as the main shape, which adds useful context. However, it omits other behavioral details like whether the operation is destructive or how errors are handled.
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, front-loaded sentence with a clear verb and object. It includes a helpful example without unnecessary words, making it highly concise and well-structured.
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, the presence of an output schema, and no nested objects, the description provides sufficient context for a simple setter. It states the core action and an important scope detail (sub-shapes), though it could potentially mention error scenarios or the reversibility of the change.
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?
The schema has zero description coverage, but the description clarifies the 'weight' parameter format via an example ('1.5 pt'). 'shape_id' is left unexplained, though it is a common identifier. The description only partially compensates for the lack of schema descriptions.
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 (Set LineWeight), specifies the target (a shape and its sub-shapes), and provides an example of the weight format. This unambiguously distinguishes it from sibling tools, none of which handle line weight.
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 use case is implied by the verb and resource ('Set LineWeight on a shape'), but there is no explicit guidance on when to use it versus alternatives or any exclusions. The description is self-evident, yet lacks explicit context.
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 the full transparency burden. It discloses key behaviors: orthogonality, inch-based coordinates, consecutive pair segment construction, and that shape ids are returned. It does not cover edge cases or permissions, but for a drawing operation it provides solid context.
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 three concise sentences, each adding distinct value: the action, the construction rule, and the output. It is front-loaded with the primary verb and contains no filler.
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?
For a simple two-parameter tool with an output schema, the description covers the core functionality, input format, and return value. The only notable gap is the unexplored 'weight' parameter and a slight ambiguity about how orthogonality is enforced, but overall it is sufficient for correct invocation.
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 0%, so the description must compensate. It explains the 'points' parameter as a list of [x, y] coordinates in inches, which is the essential required parameter. However, the optional 'weight' parameter is not mentioned, leaving its meaning entirely to the schema's name.
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 draws an orthogonal polyline through a list of [x, y] points, defines how segments are formed, and notes the return value (shape ids). This specific verb+resource combination distinguishes it from sibling tools like add_junction or set_line_weight.
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 for drawing polyline wires, but does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It provides clear context but lacks explicit guidance.
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 carries the full burden. It discloses the action (export), the destination (file), supported formats, and that it returns the written path. However, it does not mention whether it overwrites existing files, requires an open document, or any other 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?
Two sentences, front-loaded with the primary action, and every word serves a purpose. The format list and return note are concise and actionable.
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?
For a simple 2-parameter tool with an output schema, the description covers the core behavior, formats, and return value. It does not address error conditions or prerequisites like an open document, but these are relatively minor given the simplicity and available sibling 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?
Schema coverage is 0%, so the description must compensate. It lists valid values for 'fmt' (png, jpg, gif, etc.) and clarifies that 'path' is the output file path, implied by 'writes a file' and 'returns the written path'. This provides meaningful semantics beyond the bare schema types.
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 ('Export') and resource ('current page'), clearly distinguishing it from sibling tools like save_document. Listing supported formats and return value adds clarity without ambiguity.
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 states what it does but does not explicitly contrast with alternatives like save_document or specify when to choose this tool. Usage context is implied by the verb 'export' and format list, but there is no direct guidance or exclusion.
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 carries the burden of disclosing behavior. It clearly communicates that this is a non-mutating check ('Check server and Visio connection health'), which implies read-only semantics. However, it does not disclose whether the tool may throw errors, return partial results, or have any side effects, leaving some uncertainty about its behavior.
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, clear sentence that wastes no words. It is front-loaded with the key action and resource, making it easy to scan. No unnecessary details are included.
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 simplicity (no parameters) and the presence of an output schema, the description is adequately complete. It conveys the core purpose and what is checked, and the output schema handles return-value details. It could add context about what 'health' means or specific failure modes, but this is not a significant gap for a zero-parameter health check.
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, so the description does not need to explain parameter semantics. Per the rubric, a score of 4 is appropriate for tools with no parameters, as there is nothing to document beyond what the schema already shows.
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 'Check' with a clear resource 'server and Visio connection health', making it distinct from all sibling tools which focus on document, page, stencil, or drawing operations. There is no ambiguity about what this tool does.
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 you need to verify server or Visio connection health, but it does not explicitly state when to use it or mention alternatives. Since no sibling tool performs health checks, the lack of alternatives is acceptable, but there is no explicit guidance on timing or prerequisites.
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 provided, the description carries the full transparency burden. It accurately describes the action (placing a dot) and adds a visual detail ('solid'), but it doesn't disclose any side effects, error behavior, or page requirements. The behavior is straightforward, but some context is still missing.
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, concise sentence that conveys all essential information without unnecessary words or repetition. It front-loads the action and immediately specifies the location and context.
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?
For a simple tool with only two numeric parameters and an output schema (per context), the description provides adequate context. It explains what the tool does and the condition for use. It doesn't go into extraneous detail, but given the tool's simplicity, the description is sufficiently 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?
Schema description coverage is 0%, so the description must explain the parameters. The phrase 'at (x, y)' explicitly maps x and y to coordinates, giving them meaning beyond plain numbers. While it doesn't elaborate on units or origin, for a simple placement tool this is sufficient.
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 ('Place'), the object ('a solid junction dot'), and the location ('at (x, y)'). It distinguishes itself from sibling tools like draw_wire and add_label by specifying a unique resource, making its purpose immediately clear.
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 includes the condition 'for >=3-wire nodes,' which indicates when the tool is appropriate. It doesn't explicitly state alternatives, but the condition implies that this should not be used for fewer wires, providing clear context for its intended usage.
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 carries the burden of behavioral disclosure. It implies a read-only operation via 'List' and identifies the search locations, but does not mention potential side effects, errors, or the output format (though an output schema exists).
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 starts with the action verb 'List' and includes only necessary details, making it concise and well-structured.
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 simplicity, the optional single parameter, and the presence of an output schema, the description adequately covers the function and search source. Minor gaps like error handling or edge cases are not mentioned but are less critical here.
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 no descriptions for the 'directory' parameter, and the description compensates by explaining that the tool searches in the configured directories or the specified directory. This adds meaningful context beyond the raw 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 lists Visio stencil files (.vss/.vssx/.vssm) from configured directories or an optional specified directory. It uses a specific verb and resource, and distinguishes itself from sibling tools like load_stencil and list_masters.
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 provides clear context on the tool's scope (listing stencil files from configured directories or an optional directory), but it does not explicitly mention when to use this tool over alternatives or provide exclusion conditions.
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 the full burden. It discloses a behavioral trait (1:1 scaling meaning coordinates are inches) and states the return value (document name). However, it does not mention permissions, file handling, or whether the operation is destructive, though 'new' implies non-destructive.
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: the first front-loads the primary action, the second adds essential behavioral and return-value context. 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?
For a simple creation tool with an output schema and optional parameters, the description covers the core behavior (creation, scaling, return value). It could benefit from mentioning whether the document is saved to disk or purely in memory, but overall it is reasonably 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?
With 0% schema description coverage, the description compensates by explaining the unit system ('coordinates are inches'), which gives meaning to the units, width, and height parameters. It does not explicitly describe the title parameter, but the parameter name is self-explanatory.
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 'Create a new blank Visio document', which is a specific verb+resource action. It also adds distinct context (page scaled 1:1, coordinates in inches) that differentiates it from sibling tools like open_document and add_page.
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 for creating a new document but does not explicitly mention alternatives or when-not-to-use. It lacks explicit guidance like 'use this when you need a blank canvas' or references to alternative tools, so usage is only implied.
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 carries the burden. The verb 'List' implies a read-only operation, and 'current document' adds scope, but no further behavioral details (e.g., ordering, error handling, return format) are disclosed. This is adequate but 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, clear sentence with no wasted words. The action 'List pages' is front-loaded, and the context 'current document' completes the meaning efficiently.
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 simple list operation with an output schema, the description fully states the tool's purpose and scope. No additional context is required since the output schema covers return details and there are no parameters.
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, so no parameter semantics are needed. Schema coverage is 100% with an empty schema, and the description does not need to explain parameters. The baseline of 4 applies due to the absence of parameters.
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 the specific verb 'List' and identifies the resource as 'pages in the current document', clearly distinguishing it from sibling tools that list stencils, masters, or shapes. The scope is explicit and unambiguous.
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 provides clear context by specifying 'current document', but it does not discuss when to use this tool versus alternatives like select_page or add_page. No exclusions or alternatives are mentioned, but the context is sufficient for a simple list operation.
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 burden. It transparently states the action (list), the scope (current page), and the returned fields, which accurately conveys a non-destructive read operation. It does not discuss edge cases like empty pages or ordering, but for a simple list this is sufficient.
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, front-loaded sentence that states the purpose and the exact fields returned. Every word earns its place, with no redundancy or filler.
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's simplicity, the presence of an output schema, and lack of parameters, the description fully captures the behavior and return value. It is complete for an agent to select and invoke correctly.
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 the schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific meaning because there are none to document; it only clarifies the result shape, which is appropriate.
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 ('all shapes on the current page') plus the fields returned. It distinguishes from sibling tools like list_pages and list_masters by explicitly scoping to shapes.
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 clearly implies when to use (to list shapes on the current page) but does not explicitly mention alternatives or exclusion cases. It would benefit from noting when to use find_shape or list_masters instead.
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. 'List' clearly indicates a read-only, non-destructive operation, and the scope is precisely defined. However, it does not explicitly state read-only behavior or explain what 'measured pin geometry' entails, which could be considered a minor gap, but the behavior is straightforward for a zero-parameter listing tool.
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, concise sentence that is front-loaded with the action and object. Every word earns its place, and there is no redundant information.
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 low complexity (zero parameters) and the presence of an output schema, the description is complete. It clearly states what the tool does without needing to explain return values or further details. It is adequate for an agent to select and invoke the tool correctly.
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 the schema is empty, so there is nothing to document. The description adds no parameter information, but that is unnecessary here. The baseline for 0 parameters is 4, which is appropriate.
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 specific resource ('stencil masters' with 'measured pin geometry'), which clearly distinguishes it from sibling tools like list_masters or list_stencils. It conveys exactly what is returned.
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 you need stencil masters with measured pin geometry, but it does not explicitly state when to use this tool over alternatives like list_masters, nor does it provide exclusions or contrast with sibling tools. The context is clear but not explicit.
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:

[![visio-mcp MCP server](https://glama.ai/mcp/servers/Lway-ai/visio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Lway-ai/visio-mcp)

Score Badge

Copy to your README.md:

[![visio-mcp MCP server](https://glama.ai/mcp/servers/Lway-ai/visio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Lway-ai/visio-mcp)

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/Lway-ai/visio-mcp'

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