CadPlot MCP

by agadraphy

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
Disambiguation4/5
Most tools have clear, distinct purposes (inspect, plan, stage, queue, status, cancel, report), and batch variants are explicitly differentiated by plural names and descriptions. A few similar verbs like 'validate_environment' and 'validate_staged_job' or 'inspect_drawing' and 'inventory_office_resources' could cause minor selection uncertainty, but descriptions resolve the boundaries.
Naming Consistency5/5
The naming follows a consistent verb_noun pattern throughout (inspect_drawing, scan_drawings, create_publish_plan, stage_publish_job, queue_publish_batch, cancel_publish_job, read_publish_receipt). All verbs are lowercase with underscores, and the pattern is predictable across the full set.
Tool Count3/5
At 20 tools, the server sits in the 'heavy but justifiable' range. The detailed publishing pipeline requires many steps, but the count is above the typical well-scoped 3-15 and feels close to the boundary where consolidation (e.g., merging plan and preview) might improve usability.
Completeness4/5
The tool set covers the full lifecycle from inspection and planning through staging, queuing, status monitoring, cancellation, and receipt reading, plus environment validation and resource inventory. Minor gaps exist, such as no batch cancellation or direct job modification, but these are not critical for the core publishing workflow.
Average 4/5 across 20 of 20 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 125 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it clarifies that the tool is restartable and resilient to individual drawing failures. This complements the readOnlyHint and idempotentHint without contradicting them.
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 concise sentence with no filler. However, its brevity comes at the cost of clarity, omitting the primary purpose.
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?
For a tool with 6 parameters and a restartable pagination model, the description is incomplete. It fails to mention that the tool creates batch publish plans, how pagination works, or the role of expected_inventory_id in restartability.
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 description gives no parameter-specific explanations. Schema covers 67% of parameters, but the description does not compensate for the uncovered parameter (recursive) nor connect pagination concepts to offset or expected_inventory_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Inspect' rather than 'Create', which conflicts with the tool's name 'create_batch_publish_plans'. It does not explicitly state that the tool creates batch publish plans; it describes a behavior (inspecting a restartable page of DWGs) rather than the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'one drawing failure does not stop the batch' implies fault-tolerant batch processing, but it doesn't distinguish this tool from siblings like create_publish_plan or stage_publish_batch.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds minimal context ('configured office paper profile') but doesn't disclose any additional behaviors like matching strictness or no-match handling. This is acceptable given the simple read-only nature.
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, focused sentence with no redundant or filler content. It front-loads the action and resource, making it immediately understandable.
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, one-parameter read-only tool with complete annotations, full schema coverage, and an output schema present, the description is adequate. It lacks some context about matching behavior (e.g., exact match, case sensitivity) but is not critically incomplete.
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 fully describes the 'label' parameter with a clear description. The tool description doesn't add any extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'match' and the objects 'frame's paper-size label' and 'configured office paper profile'. It distinguishes this from sibling tools by focusing on the matching operation, though it doesn't explicitly contrast with alternatives.
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 given on when to use this tool versus other tools. The description only states what it does, leaving the agent to infer appropriate usage from the tool name and 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it clarifies the read is bounded ('up to 20'), that it includes exactly 'one final queue-capacity sample', and explicitly confirms 'never writes'. This goes beyond the annotations by specifying scope and non-mutation in operational terms, without contradicting any annotation.
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 front-loads the core action and key limits. It contains no filler or redundancy, and every word contributes meaning: 'Read', 'up to 20', 'live job states', 'one final queue-capacity sample', and 'never writes'.
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 simple read-only nature, the output schema exists, and the annotations cover safety, the description is nearly complete. It communicates the main scope and side-effect-free behavior. However, it lacks a hint about what the output structure looks like, although the output schema is present, so this is mostly covered. A minor gap is that it does not mention error handling or rate limits, but for such a bounded read tool this is acceptable.
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 100%, so the description does not need to explain parameters. The schema already describes plan_ids as exact plan identifiers with constraints (max 20, min 1) and includes a note about write tools requiring approval. The timeout_ms parameter is also self-explanatory. The description adds no additional parameter semantics, so a baseline 3 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 clearly states the tool's function: 'Read up to 20 live job states and one final queue-capacity sample.' This is a specific verb ('Read') with a specific resource ('live job states') and a distinguishing detail ('one final queue-capacity sample'). It also distinguishes itself from siblings like get_publish_job_status by indicating it covers up to 20 job states, indicating a batch-scope read.
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. It does not mention sibling tools like get_publish_job_status or queue_publish_batch, nor does it state any conditional context (e.g., 'use this for batch status reads'). The only implicit hint is the 'batch' in the name, but the description itself offers no explicit when-to-use or when-not-to-use guidance.
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?
The description adds behavioral context beyond the annotations: it discloses that the tool may create output PDFs, indicating a side effect beyond just queueing. It also emphasizes the need for an 'exact approved' plan, implying validation behavior. This is valuable since the annotations only specify readOnlyHint false without detailing the nature 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?
The description is a single, well-structured sentence that conveys the tool's purpose in a front-loaded manner. It avoids unnecessary verbosity and each phrase adds meaning—'exact' signals approval constraints, 'may create output PDFs' notes potential side effects.
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 existence of an output schema and annotations, the description provides sufficient context without needing to detail return values. It covers the key prerequisite (staged plan) and the action (queue), while the schema and annotations handle the rest. It could be slightly more explicit about prerequisites, but it is overall adequate for the tool's 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?
The input schema already provides comprehensive descriptions for all 4 parameters covering 100% of their semantics. The description does not add meaningful parameter-level detail beyond the schema's existing information, so a baseline score of 3 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 clearly states the tool's function: 'Queue an exact approved staged plan for PDF publishing.' It uses a specific verb ('queue'), identifies the resource ('approved staged plan'), and specifies the purpose ('PDF publishing'). This distinguishes it from sibling tools like stage_publish_job (staging) and queue_publish_batch (batch queueing).
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 explicit guidance on when to use this tool versus alternatives like queue_publish_batch or when not to use it. The 'exact approved staged plan' language implies prerequisites, but no direct usage instructions or 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?
Annotations provide no safety hints (all false), so the description carries the burden. It adds a key constraint ('never plots or edits originals'), but does not disclose other potential side effects of staging (e.g., whether it writes files, is stateful, or requires downstream validation).
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. It front-loads the verb and includes the most important constraints (limit and non-destructive guarantee).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich schema and an output schema, the description is appropriately sized. It covers the batch limit and safety, but could benefit from a brief mention of the staging workflow (e.g., must be followed by validate_staged_job or queue_publish_batch). Overall sufficient for selection.
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 input schema already provides 100% description coverage, including path and plan_id constraints. The description adds only the batch limit (up to 20), which duplicates schema maxItems, and no additional parameter-specific meaning.
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 identifies the action ('Stage') and the resource ('up to 20 explicit DWG/plan-ID approvals'). Distinguishes from siblings like stage_publish_job (singular) and queue_publish_batch (queueing) by focusing on batch approval staging.
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 staging multiple approved plans before validation/queueing, but does not explicitly state when to use it over stage_publish_job or queue_publish_batch. It mentions 'explicit' approvals, which signals a prerequisite, but offers no alternative 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the statement 'never modifies the job or outputs', which reinforces the safety profile and clarifies the scope of inspection, but does not disclose additional hidden behavior beyond what annotations provide.
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?
A single sentence that is front-loaded with the primary action, followed by a safety guarantee. No redundant words or repetition of schema details.
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?
With a rich set of annotations, a full output schema, and only one well-defined parameter, the description covers the essential behavioral context. It is complete for a simple read-only audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'manifest_path' with a clear description and 100% coverage. The tool description adds no information about the parameter, so the baseline of 3 applies as the schema does the heavy lifting.
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 ('Inspect') and resource ('expected PDFs'), and states the return type ('hashes/statuses'). This clearly distinguishes it from siblings like get_publish_job_status or read_publish_receipt.
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 a read-only audit use case through 'never modifies', but it does not explicitly state when to use this tool over alternatives such as inspect_drawing or scan_drawings. No direct references to sibling tools or exclusions are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific context of a 'read-only local named-pipe command,' which conveys a local IPC mechanism and implies that the plugin must be present for the check to succeed. This goes beyond the annotations without contradicting 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 a single, concise sentence with no filler. It front-loads the core action and includes the key mechanism, making every word valuable.
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 (1 parameter, output schema present, rich annotations), the description covers the essential context. It could note the dependency on the plugin being installed/running, but the phrase 'installed plug-in' plus the named-pipe mention partially implies this. Overall, it is sufficiently complete for the tool's 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?
The sole parameter timeout_ms has full schema coverage with a clear description ('Bounded local plug-in request timeout in milliseconds'). The tool description adds little beyond this, but the schema alone is sufficient for understanding the parameter, so the baseline of 3 applies.
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 function: 'Check the installed AutoCAD plug-in' via a specific mechanism ('read-only local named-pipe command'). It uses a specific verb+resource pairing and is distinct from sibling tools like get_publish_job_status, which are about publish operations.
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 checking the plugin status but provides no explicit when-to-use guidance or alternatives. It doesn't mention when not to use this tool or how it compares to other tools, leaving usage context to be inferred.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'never edits drawings or output files' reinforces this but adds only slightly more concreteness by naming the specific resources that are not modified. No new behavioral traits such as auth requirements or failure modes are disclosed.
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 action and a safety guarantee. It contains no fluff or redundant filler, earning a perfect score for conciseness.
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?
This is a simple read-status tool with two well-documented parameters, a rich output schema, and annotations covering safety and idempotency. The description sufficiently conveys what the tool does; the only minor gap is that it does not detail what statuses are returned, but the output schema likely covers that.
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 input schema provides 100% coverage with descriptions for both plan_id and timeout_ms, so the schema fully explains the parameters. The description adds no additional parameter semantics, making the baseline 3 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 'Read' with a clear resource 'queued publish job state', which distinguishes it from sibling tools like get_publish_batch_status and read_publish_receipt. It also adds a safety clause 'never edits drawings or output files' that clarifies the tool's side-effect-free nature.
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 that this tool is for reading the state of a queued publish job, which implies when it should be used. However, it does not explicitly mention alternatives or exclusions, such as using get_publish_batch_status for batch-level status, so it lacks explicit differentiators.
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?
Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds valuable behavioral context: 'capacity-full items are deferred for an exact retry,' which is not covered by annotations. This explains a key non-obvious behavior, though it doesn't fully clarify retry semantics.
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 captures the core action and a key exception. Every word earns its place with no redundancy.
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 rich schema (100% parameter coverage) and presence of output schema, the description covers the primary action and the notable capacity behavior. Some ambiguity remains about the meaning of 'exact retry' and workflow placement, but overall it is sufficient for a queue operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for approvals and timeout_ms. The tool description adds no extra parameter-level meaning, so the baseline of 3 applies.
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 function: 'Queue up to 20 approvals' with a specific resource (publish approvals) implied by the title and sibling context. It distinguishes from sibling 'queue_publish_job' by the batch nature (up to 20). The verb 'Queue' is specific and the scope is clear.
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 batch queueing (up to 20 approvals) but does not explicitly state when to use this instead of alternatives like queue_publish_job. No exclusions or alternative guidance is provided, so usage is only implicitly conveyed.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds context about persistence and the restart scenario, but 'never writes files' is redundant with the annotations. No contradiction 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, front-loaded with the core action and resource, and includes a clear side-effect guarantee. Every word earns its place with 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?
Given the low complexity (one parameter), rich annotations, and presence of an output schema, the description is nearly complete. It provides the key scenario ('after AutoCAD restarts') and read-only guarantee, though it could have mentioned what the returned evidence contains or any prerequisites, but the schema covers parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (manifest_path), with its own description about local path policy. The tool description adds no new parameter semantics, so the baseline of 3 applies.
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 identifies the action ('Read') and the resource ('persistent terminal publish evidence'), with the specific condition 'after AutoCAD restarts'. This distinguishes it from sibling tools that create, stage, or queue publish jobs, and the explicit 'never writes files' reinforces its read-only nature.
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 for when to use this tool: after AutoCAD restarts, when persistent evidence is needed. It does not explicitly name alternative tools or state when not to use it, but the 'never writes files' hints at a safe read-only alternative to write operations.
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?
Annotations provide only false hints, so the description carries the burden. It adds meaningful context: the operation revalidates, copies into an isolated workspace, and explicitly guarantees never plots. This goes beyond the annotation fields and gives a clearer behavioral 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?
The description is a single sentence that front-loads the primary action, states the resource, and includes a critical constraint ('never plots'). Every word earns its place with 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?
Given the output schema exists and the tool is one step in a pipeline, the description covers the core behavior. It mentions isolation and the no-plot guarantee, which are important context. It lacks explicit prerequisites (e.g., plan must be approved) but those are partially implied by the name and schema.
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 descriptions cover both parameters 100% (path and approved_plan_id). The description adds a slight hint that 'approved plan' maps to approved_plan_id and the DWG relates to path, but it doesn't clarify whether path is the source or destination. Overall it adds marginal value 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 uses specific verbs ('revalidate', 'copy') and names the key resources ('approved plan', 'DWG', 'isolated workspace'). The phrase 'never plots' clearly differentiates it from plotting/publishing siblings like queue_publish_job and preview_publish_plan.
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 used after plan approval and before plotting, but it does not explicitly state when to use this over alternatives like stage_publish_batch or validate_staged_job. The only exclusion is 'never plots', but there is no direct comparison to sibling tools.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the exact items being validated (configuration, allowed roots, connection), and it reinforces the read-only nature of the COM connection. It does not contradict annotations and contributes useful context beyond the structured hints.
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, highly concise and front-loaded. It communicates the core purpose without any superfluous words, making it easy for an agent to parse quickly.
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 validation tool with no parameters and an output schema (indicated by context signals), the description is largely sufficient. However, it could be slightly more complete by noting its role in the pre-publish workflow or differentiating when to use it over get_autocad_plugin_status. Still, the essentials are covered.
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 takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the input schema is empty. This score reflects that the no-parameter scenario is well handled without any additional burden on the description.
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 function with a specific verb ('validate') and identifies three concrete targets: configuration, allowed roots, and the read-only AutoCAD COM connection. This distinguishes it from sibling tools like inspect_drawing or get_autocad_plugin_status by focusing on environment-level validation rather than drawing inspection or plugin status.
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 alternatives. The description explains what it validates but not when it should be invoked (e.g., before publishing, as a pre-flight check, or how it relates to get_autocad_plugin_status). This leaves the agent without explicit decision criteria.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds useful context beyond them: it explicitly states the tool never 'approves' (a separate non-write action) and emphasizes 'exact' names, indicating precision. This adds meaningful behavioral detail without contradicting annotations.
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 short sentences, front-loaded with the action verb. Every word earns its place; 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 (1 parameter), rich annotations, and presence of an output schema, the description is fully sufficient. It covers purpose, non-write behavior, and precision, leaving no critical gaps for an agent to misuse it.
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 100%, so the path parameter is fully described in the schema including the path policy requirement. The description itself adds no additional parameter semantics, consistent with the baseline of 3 when schema carries the full burden.
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 names a specific verb ('Inventory') and a specific resource ('exact frame/layout/page-setup/plot resource names'), clearly distinguishing it from sibling tools like create_publish_plan or preview_publish_plan. It also adds a clarifying negative scope ('never approves or writes'), making the purpose 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 listing resource names without side effects, but it does not explicitly state when to use this tool versus alternatives like scan_drawings or inspect_drawing. The phrase 'never approves or writes' provides an exclusion but lacks positive use-case context or sibling comparisons.
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?
The description adds behavioral context beyond the annotations: it states the cancellation is 'durable' and excludes running jobs, while annotations already flag the operation as destructive and idempotent. This gives the agent a clear safety model without contradicting the schema. The limitation is that it does not describe post-cancellation effects or error handling, so a score of 4 reflects good but not exhaustive 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 entire description is a single, well-structured sentence that front-loads the core action ('durably cancel one exact pending job') and then adds the key constraint ('never interrupts a running AutoCAD plot'). There is no filler or repetition of schema or annotations. This scores 5.
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 rich schema (100% parameter coverage), annotations that establish destructiveness and idempotency, and an output schema, the description covers the essential selection criteria and behavioral guarantees. It explains what the tool does, when it applies (pending), and what it avoids (running), which is sufficient for an agent to decide. It could mention prerequisites like obtaining plan_id and manifest_sha256 from prior steps, but the schema already indicates these are required and exact, so the description is contextually complete enough.
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?
All three parameters are fully described in the schema, including patterns and validation constraints, so the baseline is 3. The description's mention of 'one exact pending job' reinforces the need for exact identifiers but adds no new parameter-level semantics beyond the schema. Thus the parameter semantics score remains 3.
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 identifies the tool as canceling a publish job, specifies it applies to pending jobs only, and distinguishes itself from any tool that could affect running plots. It includes a specific verb, resource, and scope, and the addition 'never interrupts a running AutoCAD plot' helps disambiguate from generic cancel operations.
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 for when to use the tool: for a single pending job that must be canceled. It explicitly excludes running plots, giving a when-not condition. However, it does not mention alternative tools for batch cancellation or handling running jobs, so it falls short of full guidance; the sibling list includes other publishing tools but no other cancel tool.
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?
The description adds behavioral context beyond annotations by mentioning 'restartable page' (pagination behavior) and 'suggest safe next actions' (advisory output). The 'never writes' reinforces the read-only annotations without contradicting them. It does not detail error handling or prerequisites, but annotations already cover safety.
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 front-loads the core purpose and includes the key safety note. Every phrase contributes meaning, with no redundancy or 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?
Given the presence of an output schema and rich annotations, the description adequately covers the tool's role, pagination, and non-write behavior. It doesn't explain return values (unnecessary with output schema) or edge cases, but the description combined with schema and annotations is sufficient for a straightforward read-only list-style tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (limit, after_job_id), including the cursor pattern. The tool description adds the concept of 'restartable page', which aligns with after_job_id, but does not provide new parameter-specific information. With schema coverage at 50%, the description partially compensates but not fully.
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 function: 'Summarize staged jobs as a restartable page and suggest safe next actions.' It uses a specific verb ('summarize') and resource ('staged jobs'), and the phrase 'never writes' differentiates it from mutation tools. The name and title also align, making the purpose 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 implies use when you need an overview of staged jobs and safe next actions, and the 'never writes' note sets expectations. However, it does not explicitly mention when not to use it or reference alternative tools like audit_publish_outputs, so it lacks explicit exclusions or alternative guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful context beyond those: files are not opened, and the path must pass CadPlot's configured path policy, which is an authorization-related behavioral detail. No contradiction with annotations is present.
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 14 words, front-loaded with the verb and object. Every phrase contributes meaning, with no filler, tautology, or repetition.
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 rich annotations (readOnly, idempotent, non-destructive) and the presence of an output schema, the description sufficiently conveys purpose and key constraints. It could mention max_files or recursive behavior, but the schema covers most parameters, so the description is complete enough for tool selection and 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?
The schema already documents root and max_files with descriptions, giving 67% coverage, but recursive has no description. The overall description reinforces the root policy but does not add semantics for max_files or recursive, leaving recursive's meaning implicit in its schema default of true.
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 uses the specific verb 'List' with the resource 'DWG files' and adds valuable scope: 'under an explicitly allowed project root' and 'without opening them'. This clearly distinguishes it from the sibling inspect_drawing tool.
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 states a clear prerequisite: the root must be an explicitly allowed project root, which gives context for when this tool is applicable. It does not explicitly name alternatives or exclusions, though 'without opening them' hints that it is not for inspecting file contents.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds 'deterministic' and 'never modifies or plots it', which goes beyond the annotations by specifying the exact behavioral guarantee. This is valuable additional 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 a single, front-loaded sentence that immediately states the action and safety guarantee. There is zero redundancy or extraneous detail.
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 simple tool (1 parameter), rich annotations, and presence of an output schema, the description adequately covers all necessary context: what it does, the single-file scope, determinism, and lack of side effects. No gaps are apparent.
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 100% for the single 'path' parameter, with a description that explains the path policy. The tool description adds minimal extra meaning ('one DWG') that is already implied by the tool's purpose, so the baseline of 3 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 clearly states the tool's function with specific verbs ('Inspect', 'return') and a specific resource ('one DWG'). It explicitly distinguishes this from batch operations by using 'one' and from actual publishing by stating it is a 'dry-run plan' and 'never modifies or plots'.
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 context is clear: use for a single DWG to get a deterministic dry-run plan without side effects. While no explicit alternatives are named, the sibling tool 'create_batch_publish_plans' is implicitly contrasted via 'one DWG', providing adequate usage 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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by confirming the read-only nature and listing specific inspection targets (layouts, plot settings, frames), plus the 'allowed' constraint. No contradictions with annotations.
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 immediately states the verb, resource, and scope, and every phrase ('explicit allowed', 'read-only', 'layouts, plot settings, and frames') carries meaning.
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 one-parameter tool with a rich output schema and comprehensive annotations, the description is complete. It covers the tool's purpose, scope (single allowed file), and content areas, while leaving return values to the output schema.
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 description for the single 'path' parameter is fully explicit, including the CadPlot path policy. Since schema coverage is 100%, the description does not need to add further parameter details, and it doesn't, which is acceptable. Baseline 3 applies.
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 'Inspect' and clearly defines the resource as 'one explicit allowed DWG/DWT' with concrete content ('layouts, plot settings, and frames'). It differentiates from sibling tools like scan_drawings by emphasizing the singular focus.
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 when to use the tool: for inspecting a single explicit DWG/DWT file. It provides clear context and the 'one' qualifier distinguishes it from batch operations. However, it does not explicitly name alternatives or provide when-not-to-use scenarios.
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 readOnlyHint, idempotentHint, and destructiveHint already provided, the description adds extra behavioral context by noting it 'never queues or plots the job' and works with the 'local plug-in'. This goes beyond the annotations without contradicting 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 a single concise sentence that front-loads the primary action and includes a key exclusion. Every word earns its place with no unnecessary detail.
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, rich annotations, and presence of an output schema, the description is complete. It states the action, the non-actions, and the local scope, making it fully 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description does not add any parameter-specific meaning beyond what the schema already provides, so the baseline of 3 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 clearly states the action ('Cross-check a staged manifest') and the resource ('with the local plug-in'). It distinguishes from siblings by explicitly noting 'never queues or plots the job', which separates it from queue_publish_job and plotting tools.
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 for when to use the tool (validating a staged manifest) and includes an exclusion ('never queues or plots'). However, it does not explicitly name alternative tools or state 'use this instead of X', leaving some room for interpretation.
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?
The description discloses specific behavioral guarantees: 'never edits, saves, or plots the DWG'. This goes beyond the annotations (readOnlyHint, destructiveHint) by naming concrete actions it will not perform, which is highly valuable for the agent to understand side-effect boundaries.
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 packed with purpose and behavioral constraints. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety, schema covering parameters, and an output schema present, the description provides enough context for a validation tool. It explains what it does and what it avoids, though it could briefly mention what kind of validation result is returned, but the output schema likely handles that.
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?
Input schema has 100% description coverage and both parameters (path, timeout_ms) are well-documented in the schema. The tool description itself adds no parameter-specific meaning, but schema already covers the semantics, so baseline 3 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 clearly states the tool's purpose: 'Validate a ready dry-run plan with AutoCAD' – a specific verb, resource, and context. It also explicitly distinguishes itself by adding 'never edits, saves, or plots the DWG', which separates it from publishing/plotting tools and other validation tools in the sibling list.
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 when you have a ready dry-run plan to validate, which is clear context. However, it does not explicitly mention alternatives or exclusions, even though sibling tools like validate_staged_job exist and operate in a related but distinct phase. Lacks explicit 'use this instead' guidance.
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:

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

Score Badge

Copy to your README.md:

[![cadplot-mcp MCP server](https://glama.ai/mcp/servers/agadraphy/cadplot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/agadraphy/cadplot-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/agadraphy/cadplot-mcp'

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