@splice-cad/mcp
OfficialServer Quality Checklist
Latest release: v0.6.0
- Disambiguation4/5
Most tools have clearly distinct purposes: search_* for different part types, get_* for retrieving different resources, and execute_command/execute_commands are clearly related but singular/plural. The primary ambiguity is between create_component and create_cable, which could overlap for cable creation, but descriptions guide usage. Overall, boundaries are well-defined.
Naming Consistency5/5The vast majority use a consistent verb_noun pattern (create_component, save_plan, list_projects, get_harness_summary). Exceptions like undo, redo, and is_bridge_connected are still intuitive and follow common conventions for single-word commands and boolean checks. No mixed casing or style inconsistencies.
Tool Count3/5At 28 tools, this server is on the heavy side, exceeding the typical 3-15 range. However, the scope is broad, covering project/plan management, parts database, legacy harnesses, and live bridge control. There is some redundancy (get_plan vs get_plan_summary, execute_command vs execute_commands) that could be consolidated, making the count feel slightly bloated.
Completeness3/5The tool surface covers core workflows: creating/reading/updating plans and harnesses, searching/creating parts, and controlling the live canvas. Notably missing are delete operations for projects, plans, harnesses, and components, as well as update tools for parts. Agents may need to work around these gaps.
Average 4/5 across 28 of 28 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal that the tool reflects unsaved changes and that setComponentState updates form fields, but it does not mention potential persistence side effects of the 'save' action found in the schema, nor other mutation risks beyond the term 'set'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, two sentences, with key information front-loaded. It wastes no words and quickly conveys the dual get/set nature and the specific setter use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, nested object, and absence of output schema, the description is somewhat minimal. It explains the high-level purpose and one use case, but it does not describe return value shapes or the full scope of queries, leaving the schema to fill in gaps. This is sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter description coverage, including detailed meanings for each query value and params structure. The description adds little beyond what the schema already states, like the namespace reference, but it does reinforce the setComponentState usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets or sets live frontend state and explicitly mentions that it reflects unsaved changes, including assemblies. It distinguishes the tool by highlighting the harness:* namespace and component creator setter functionality, though it does not name sibling tools for direct comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one explicit usage instruction: 'Use setComponentState to update the Component Creator form fields.' It also implies the tool is appropriate when unsaved state matters, but it does not provide exclusions or contrast with alternative tools like get_plan_summary or get_harness_summary.
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 clearly communicates that this is a read operation ('Get') and gives some indication of the return content (full details including specification fields like pin count and gauge). However, it does not disclose potential behaviors such as error handling for invalid IDs, authentication requirements, or the exact structure of the returned details. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action and a relevant detail about the return content. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is reasonably complete: it explains the action and provides examples of what 'full details' include. It could be enhanced by mentioning the absence of a return-schema or clarifying how this differs from lookup_part, but overall it covers the essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single 'id' parameter is already described as 'Part UUID'. The description only repeats 'by ID' and adds no new semantic information about the parameter format, constraints, or usage. Since the schema covers the parameter fully, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving full details for a specific part by ID, with a specific verb ('Get') and resource ('part'). It does not differentiate from the sibling tool 'lookup_part', which may serve a similar purpose, so it loses a point for lacking sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 alternative lookup or search tools. There is no mention of prerequisites, when to use lookup_part instead, or any context for choosing this over search_* tools. The description offers no usage context beyond the basic action.
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 behavioral traits. It mentions the environment ('Splice frontend') but does not explain side effects, what happens when there is nothing to redo, error behavior, or the effect of the 'namespace' parameter. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It delivers the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description still leaves critical context unaddressed: how the namespace scopes the redo, what happens if no undo history exists, and whether the operation returns a result. The description is too sparse for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'namespace' as 'Target tab namespace' with 100% coverage. The description adds no further meaning about how this parameter affects the redo operation. Baseline of 3 is appropriate because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Redo') and the specific resource ('the last undone command in the Splice frontend'). It distinguishes from the sibling 'undo' tool by explicitly naming the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after an undo, but it does not explicitly state when to use it vs. alternatives or mention the 'undo' sibling. No exclusions or context are provided, so the usage cue is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns project ID and details, which adds some context, but it does not mention permissions, idempotency, conflict behavior, or other side effects of creation, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences that front-load the verb and resource. It contains no filler or redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with two parameters, but no annotations or output schema. The description covers the basic purpose and return value but lacks details on potential side effects or requirements, leaving it slightly under-specified for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (name and description) are fully described in the schema (100% coverage), so the baseline is 3. The description adds no additional parameter-specific information, so it does not exceed this baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new Splice project' and mentions the return value. This distinguishes it from sibling creation tools like create_component and create_cable, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. The usage is implied by the verb 'create' and the resource 'project', but no prerequisites, exclusions, or alternative tool references 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?
With no annotations, the description carries the full burden. It discloses the return scope (plan and assembly list) but doesn't mention permissions, error behavior, or any side effects. For a get operation, this is acceptable but minimal, lacking details like whether the plan is full or summarized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, containing no unnecessary words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple fetch but lacks detail about the structure of the plan and assembly list. Given no output schema and the presence of sibling tools like get_plan and list_projects, more context would help disambiguate when to use this tool over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents project_id with description 'Project UUID', so the description adds no new meaning. The tool description doesn't elaborate on how project_id is used or any format expectations beyond the schema, but the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (project), and specifies that it includes the plan and assembly list, which distinguishes it from a simple project listing or plan-only retrieval. It doesn't explicitly name sibling tools, but the scope is evident from the wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance is provided, but the description implies that this tool is for retrieving a project along with its plan and assembly list. It doesn't mention alternatives or exclusions, but the context is enough to infer the intended use.
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 disclosing behavior. It states the action but omits critical details such as whether the operation is destructive, what exactly gets undone (e.g., which command types), whether the namespace modifies scope, and what happens if no command exists to undo. This is insufficient for a state-altering 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the tool's purpose. It is appropriately sized for the tool's simplicity and has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description gives the core purpose, but it omits how the 'namespace' parameter affects behavior and does not cover edge cases like undo history limits or error states. The description is minimally acceptable but leaves contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the 'namespace' parameter having a description ('Target tab namespace'). The tool description does not add any extra meaning to the parameter, so the baseline of 3 applies. The schema description itself is terse but sufficient for the single optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Undo' and names the resource 'the last command in the Splice frontend', clearly distinguishing it from sibling tools like 'redo' and 'execute_command'. It leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to revert the last command) but provides no explicit guidance on when to prefer this over alternatives like 'undo' vs 'redo', nor does it mention prerequisites or context. The 'namespace' parameter hints at targeting specific tabs, but its role is not explained in the description.
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 behavioral disclosure. It only states 'Search' and gives examples, but does not mention that this is a read-only operation, how results are returned, or any potential limitations. This is a sparse disclosure for a tool with no annotation safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and includes practical examples and usage guidance. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with 3 parameters and no output schema, the description is adequate but not complete. It does not describe the return format or result structure, relying on the 'search' verb and schema to imply behavior. It's sufficient for basic use but lacks detail for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a second query example ('belden 2 conductor') beyond the schema's example, but does not explain limit or offset semantics beyond what the schema already provides. This contributes marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as searching the Splice cable parts database. It distinguishes from siblings like search_connectors and search_wires by specifying 'cable' and provides concrete examples of supported queries, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool only when the user asks to find a cable, and for most cases to create cable BOM entries directly. This gives clear when-to-use and when-not-to-use guidance, though it doesn't name specific sibling tools as alternatives.
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 only states 'Create' without mentioning side effects, permissions, idempotency, or error behavior. The only behavioral hint is the dependency on lookup_part for URLs, which is more of a usage guideline than a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, followed by a concise prerequisite and a comprehensive category list. While the category list is long, it provides necessary terminology and every sentence earns its place without excessive fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 18 parameters, nested objects, no annotations, and no output schema, the description supplies essential context (purpose, prerequisite, categories) but omits information about success/failure behavior, return values, and how to use nested structures like custom_svg or category_specs. The schema covers parameter descriptions, so it is minimally viable but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting a baseline of 3. The description adds value beyond the schema by enumerating the valid categories (since category has no enum in the schema) and directing users to lookup_part for sourcing img_url and datasheet_url, which clarifies how to fill those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action ('Create a component') and resource ('in the Splice parts database'), and specifies what is included ('full specs, images, and pin labels'). This distinguishes it from sibling creation tools like create_cable and create_project, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to 'Use lookup_part first to get image/datasheet URLs', providing a clear prerequisite and implying a workflow. It does not explicitly discuss when not to use the tool or compare to alternative creation tools, but the context is otherwise clear.
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 discloses the return content (full BOM, connection data) and notes 'legacy' status, but it does not explicitly state that the tool is a read-only operation or describe any side effects. The phrase 'modify' in the usage line could mislead an agent into thinking the tool mutates data, when it actually just loads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficiently front-loaded. The first sentence states the core functionality, and the second sentence gives usage context. No filler or redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately communicates the return value by mentioning 'full BOM (hydrated parts) and connection data.' It gives enough context for an agent to select the tool and know what to expect, though it does not detail the exact response structure or revision handling beyond what the schema already covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (harness_id and revision), so the schema already documents their meanings. The tool description adds no parameter-specific details beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a legacy harness with its full BOM (hydrated parts) and connection data. It uses a specific verb ('Load') and resource ('harness'), and the mention of 'full BOM' differentiates it from sibling tools like get_harness_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to inspect or modify an existing harness.' It gives a purpose but does not explicitly name alternatives or when-not-to-use conditions. The distinction from get_harness_summary is implied but not stated, so it falls just short of explicit exclusion 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?
No annotations are provided, so the description carries the full burden. It discloses the return values (image URL, datasheet URL, specs, parameters) but lacks detail on side effects, limitations, or failure modes (e.g., network dependency, no match handling). This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences effectively deliver the core action, return values, and usage guidance. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 2 params and no output schema, the description adequately covers purpose, returns, and usage. It omits potential edge cases (e.g., ambiguous MPN, multiple matches) but remains sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already described in the schema. The description adds no additional parameter semantics beyond 'by MPN', which aligns with the mpn field. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a real-world part on DigiKey by MPN and lists what it returns. It distinguishes itself from internal part retrieval (e.g., get_part) with the qualifier 'real-world' and 'on DigiKey', but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use directive: 'Use this to enrich components before creating them with create_component.' It does not mention when not to use or alternatives, but the context is clear and actionable.
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 burden of behavioral disclosure. It mentions creating a record and returning a part ID, which communicates the primary side effect and output, but it does not address potential duplicates, permission requirements, or relationship between core_count and the cores array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, followed by usage context and return value. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the tool's purpose, usage condition, and return value, which is sufficient given the thorough parameter schema. However, the relationship between core_count and the cores array is not clarified, and there is no output schema, so a bit more detail on the expected consistency would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter has a description. The tool description adds little beyond the schema, and specifically does not clarify that core_count should match the length of the cores array, which is a non-obvious semantic relationship.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a custom multi-conductor cable'), the target resource ('parts database'), and distinguishes the tool from siblings by specifying it is for cables not found via search. This provides a specific verb and resource with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Use when a cable is not found via search') and implies the alternative of searching first. It does not explicitly name sibling tools like search_cables, but the context is 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?
No annotations are provided, so the description carries the full burden. It indicates the tool returns a structured summary of specific harness components and validation warnings, implicitly suggesting a read-only operation via 'Get'. It does not explicitly state side effects, authentication needs, or output format, leaving some ambiguity, but the listed contents give some behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the tool's output and differentiates from a sibling tool. Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description lists what the summary includes (connectors, wires, cables, connections, validation warnings) and positions it relative to 'get_harness'. It could mention error behavior or response format, but given the tool's simplicity and existing schema coverage, this is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'harness_id' as a 'Harness UUID', providing 100% coverage. The description does not add any parameter-specific detail beyond that, so it does not add value over the schema. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'harness summary', listing specific components (connectors, wires, cables, connections, validation warnings). It explicitly differentiates from the sibling tool 'get_harness' by stating 'More concise than get_harness', making its purpose clear and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: when a concise summary of a legacy harness is needed, and it directly contrasts with 'get_harness' ('More concise than get_harness'). However, it does not provide explicit when-not-to-use conditions or mention alternative tools beyond get_harness, so it falls short of full 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?
No annotations are present, so the description carries the full burden. It discloses the read-only listing scope and user-ownership constraint, but does not mention pagination, ordering, or return structure, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word earns its place and the structure is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema) and the clear ownership scope, the description is largely complete. It could add expected return shape or alternative tool references, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('projects') with an explicit scope ('owned by the authenticated user'). It clearly distinguishes itself from sibling tools like get_project (retrieve one) and create_project (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use as the default listing tool for all user-owned projects but does not explicitly state when to prefer it over alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently describes the return format (structured findings with codes, severity, IDs, suggestedFix) and mentions backward-compatible warnings. It implies read-only behavior but does not state side effects or performance considerations explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences: first states purpose and scope, second details return format. Every sentence adds value with no redundancy. Ideal structure for quick agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers input, validation scope, and output structure. Missing details like error handling for invalid project_id or execution time, but still sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (project_id), fully described in schema as 'Project UUID'. The description adds no additional semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool validates a project's plan for structural issues, enumerating specific checks like orphan nodes, dangling conductors, etc. This distinguishes it from siblings like get_plan (retrieval) or save_plan (persistence).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for validation before or after plan modifications, but lacks explicit guidance on when to use vs. alternatives, prerequisites, or exclusions. No comparison to get_plan_summary which might also provide plan insight.
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 key behavioral traits: 'Returns the created harness ID' and 'appears in Splice as an editable harness linked to the project,' indicating a persistent, editable creation. It does not mention permissions or side effects on the plan, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, no redundant filler. Every word contributes to explaining the tool's function, return value, and effect, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, 4 required) and lack of output schema, the description sufficiently covers key aspects: what it does, how it selects entities, what it returns, and where the result appears. A minor gap is not explaining the relationship between nodes and bundles, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by linking parameters to the concept of 'selecting which nodes and bundles to include,' which maps to node_ids and link_ids. This provides context beyond the individual schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a harness assembly from a plan by selecting which nodes and bundles to include.' This distinguishes it from siblings like create_harness by emphasizing the plan-driven selection process, and it specifies the outcome (returns created harness ID, appears in Splice).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from a plan ('from a plan') but does not explicitly state when to use this tool versus alternatives like create_harness or when not to use it. No exclusions or alternative references are provided, so guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses auth scope ('owned by the authenticated user') and classification ('legacy', 'standalone'), but does not mention return format, pagination, or explicitly confirm read-only behavior. While 'List' implies reading, more transparency would be expected given no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately start with the action verb 'List' and deliver all necessary information without waste. The structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the essential scope (legacy, standalone, owner). It does not describe return values, but the tool's simplicity makes this a minor gap. Overall, it is adequately complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. With 0 params, the baseline is 4. The description adds no param-specific information because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'harnesses' and adds qualifiers 'legacy', 'owned by the authenticated user', and 'standalone harnesses not associated with a project.' This clearly states what the tool does and distinguishes it from sibling tools like list_projects and get_harness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists legacy standalone harnesses owned by the user, which implies it is not for project-associated harnesses. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
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 burden and clearly discloses the destructive overwrite behavior, the requirement for a complete and valid object, and the need to fetch current state to avoid data loss. It does not cover auth or error behavior, but the key behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, front-loaded with the purpose, then concise usage guidance. No wasted words or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a save/overwrite tool with a nested object, the description gives the essential workflow (read schema, fetch current state) and the completeness requirement. It omits return value or failure behavior, but for a write operation the context is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already explain both parameters (project_id as UUID, plan_data as Complete PlanData JSON object). The description adds 'valid' and 'overwrite' semantics, but this is marginal; it does not meaningfully go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save (overwrite) the PlanData JSON for a project', using a specific verb and resource, and the overwrite qualifier distinguishes it from read-only siblings like get_plan and validate_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context: read plan_schema first, fetch current state with get_plan before modifying. This gives clear prerequisites and sequencing, though it does not enumerate when not to use it (e.g., for validation).
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 full responsibility. It implies a read-only operation ('Get') but does not explicitly state side-effect-free behavior, potential cost, or any prerequisites. For a simple getter this is mostly acceptable, but lacks explicit safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action and resource, followed by a clear usage hint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description sufficiently covers what the tool retrieves (properties, specs, SVG templates) and when to use it. It is complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining what the tool returns, which indirectly clarifies why no parameters are needed—it covers all categories globally.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting default properties, specs, and SVG templates for component categories. It specifies the resource (category templates) and the purpose (discovering fields for component creation), which distinguishes it from sibling tools like create_component or get_part.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool ('Use this to discover what category-specific fields are available when creating components'). It does not mention exclusions or alternatives, but the context is clear enough to guide appropriate usage.
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 provided, the description carries the burden of disclosing behavior. It adds meaningful details beyond 'executes a command': it states that canvas updates immediately and the action is added to undo history. This provides operational awareness, though it could also mention error handling or response behavior, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a clear purpose: definition, mode compatibility, and a usage preference plus behavioral notes. It is front-loaded with the core action and avoids any redundant filler. Perfectly concise for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters, nested objects, and no output schema, the description covers key behavioral aspects (immediate updates, undo history) and usage context (both modes, preference for plural tool). It does not explain return values, which would be helpful without an output schema, but overall it is quite complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters clearly. The description adds a bit of context around the namespace parameter (e.g., 'project:*' vs 'harness:*') but does not significantly enrich parameter meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Execute') and resource ('a single command through the live WebSocket bridge'), and clearly distinguishes from the sibling tool 'execute_commands' by emphasizing singular execution. It also specifies the two namespaces it works with, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides an alternative and preference: 'PREFER execute_commands (plural) for batching — much faster.' This tells the agent when to use this tool vs. the sibling, and also clarifies that it works for both plan mode and assembly/harness mode, giving a clear situational 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 provided, the description carries the burden of behavioral disclosure. It adds valuable traits: all commands run atomically, undo as a single action, and it works across plan and assembly namespaces. These are behavioral details not apparent from the schema. While it doesn't cover error handling or return format, the disclosed atomicity and undo behavior are significant and go beyond a generic 'execute' description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the key preference over execute_command, followed by the core functionality and behavioral notes. Every sentence earns its place: purpose, speed advantage, atomicity/undo, and namespace coverage. No redundant or filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch command execution tool with no output schema or annotations, the description covers the essential context: what it does, when to prefer it, atomicity, undo, and namespaces. It lacks explicit mention of failure behavior (e.g., what happens if one command fails), but atomicity implies all-or-nothing. Given the complexity of batch execution, this is complete enough for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description does not add parameter-specific syntax or constraints beyond what the schema already provides (e.g., commands array, namespace, description). It reinforces the 'multiple commands' aspect but does not expand on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute multiple commands in a single call.' It also distinguishes itself from the sibling execute_command by emphasizing the batch capability and speed advantage. This provides a specific verb (execute), resource (commands), and scope (multiple, in one call), 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'PREFERRED over execute_command' and explains why: 'much faster than calling execute_command repeatedly.' It also indicates supported namespaces ('plan (project:*) and assembly (harness:*)'), giving clear context for when to use this tool. This goes beyond a simple when-to-use by naming the alternative and the advantage.
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 provided, the description carries the burden of behavioral disclosure. It warns that output 'can be very large for complex plans,' which is valuable operational context. It also implies that the full plan is returned if filters are omitted. However, it does not describe the return structure or other behavioral nuances beyond size and filtering, so it's good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three purposeful sentences: a clear statement of function, a size warning, and a recommendation for alternatives. It is front-loaded with the core purpose and contains no filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no output schema, and no annotations, the description provides essential guidance: it warns about large outputs and suggests a preferred alternative for overview understanding. While it doesn't detail the return format or edge cases, it covers the most critical contextual aspects for safe and effective use, making it complete enough for most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already explains all six parameters. The description reinforces the purpose of node_ids/link_ids as filters but adds no new semantic information beyond what the schema provides. Per the baseline for high coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get PlanData for a project.' It uses a specific verb and resource, and distinguishes itself from the sibling get_plan_summary by warning that the full plan can be very large. This makes the purpose unambiguous and differentiates it from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'PREFER get_plan_summary to understand plan state' and 'Use node_ids/link_ids to fetch specific elements instead of the full plan.' This directly tells the agent when to use this tool versus alternatives and how to scope the request, which is excellent for decision-making.
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 behavioral disclosure burden. It discloses the destructive 'overwrite' nature and the requirement that harness_data must include harness_id and revision_id from the loaded harness, indicating a versioned save. It lacks details on error behavior or side effects, but covers the critical overwrite aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action. The first sentence states the function, the second provides essential usage instructions. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation, dependency on prior load), the description provides the necessary workflow and prerequisites. No output schema exists, but the description sufficiently focuses on the input requirements. Minor gaps like error conditions or return values do not significantly impair usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the two parameters, but the description adds crucial meaning by specifying that harness_data must contain harness_id and revision_id from the loaded harness. This goes beyond the schema's generic 'Complete WorkingHarness JSON object' and clarifies the required internal structure and provenance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Save (overwrite) a legacy harness' with a specific verb and resource. It distinguishes from siblings like create_harness by emphasizing 'overwrite' and 'legacy', and the usage note about get_harness sets it apart as a follow-up update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit workflow guidance: 'Use get_harness first to load current state, modify it, then save.' This clarifies when to use this tool relative to get_harness and implicitly against create_harness. However, it doesn't explicitly state exclusions (e.g., not for new harnesses), so a slight deduction.
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 does disclose fuzzy query support ('Supports fuzzy queries like "molex 24 pin male"'), but does not mention whether the operation is read-only, what the return format contains, or any pagination/ordering behaviors. This is a moderate level of transparency for a search 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and every sentence provides actionable guidance. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema, no annotations), the description covers the essential context: what the tool does, when to use it, and an example query. It also hints at output usage (sourcePartId). It could mention result limit/pagination, but the schema already covers those parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with descriptions for query, limit, and offset. The description adds semantic value by explaining query style with a concrete example ('molex 24 pin male') and by clarifying the query's purpose (finding parts or getting a sourcePartId). This goes beyond the schema's basic 'Search query' label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search the Splice connector parts database.' This uses a specific verb and resource, and the connection to connectors is explicit, distinguishing it from sibling search_wires and search_cables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Only use this when the user asks you to find a part in the database, or when you need a sourcePartId for linking. For most cases, prefer creating BOM entries directly with the MPN/manufacturer you already know.' This clearly defines when to use and when not to use, including an alternative approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses supported query formats with examples ('22 awg red', '18 awg black white stripe') and implies a read-only search operation. However, it does not describe result shape, pagination behavior, or any access requirements—acceptable for a simple search tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: first states purpose, second gives usage criteria, third provides query syntax examples. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema covers all parameters, and the description supplies usage context, exclusions, and query syntax. It does not describe what fields results contain, but with no output schema, the agent can reasonably infer it returns wire part matches. This is sufficient for a low-complexity search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions, making schema coverage 100%. The description adds value by providing concrete query format examples, which clarifies what the 'query' parameter expects beyond the schema's generic 'Search query' text. Limit and offset are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the Splice wire parts database.' It clearly distinguishes this tool from siblings like search_connectors and search_cables by focusing on wire parts. The statement 'Only use when the user asks to find a wire in the database' further pins down its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Only use when the user asks to find a wire in the database') and when not to use it ('For most cases, create wire BOM entries directly with gauge/color you already know'). This provides both positive and negative usage guidance, satisfying the 'when/when-not' requirement.
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 that the tool creates a new harness and returns it with harness_id and revision_id set, which is key behavioral information. It also mentions the need for BOM and connection data. It doesn't detail error handling or permissions, but the core mutation and response behavior are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each contributing distinct value: purpose, input requirements, prerequisite, and return behavior. It is front-loaded with the main action and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter create operation with no output schema, the description covers the prerequisite (read harness_schema), input specifics (full JSON with BOM/connection data), and return behavior (IDs set). It does not address error scenarios or idempotency, but the essential context is provided given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for harness_data is 'Complete WorkingHarness JSON object (see harness_schema resource),' which is already helpful. The tool description adds meaningful detail by specifying 'BOM and connection data' and instructing the user to read harness_schema first. This significantly enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new legacy harness,' which is a specific verb+resource statement. It clearly distinguishes from siblings like save_harness by emphasizing 'new' and 'legacy', and further specifies the input requirements (full WorkingHarness JSON with BOM and connection data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance by instructing 'Read the harness_schema resource first,' which is a clear prerequisite. It does not explicitly mention alternatives or when-not-to-use, but the 'new' versus 'save' distinction in sibling context is clear. This fits 'clear context, no exclusions'.
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 bears full burden. It discloses that object params of known PlanData type are expanded to nested fields, revealing a key behavioral trait not obvious from the schema. However, it does not state whether the tool is read-only, has any latency, or requires authentication, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three sentences, all tightly focused and front-loaded with the core purpose. Every sentence adds unique value, but the third sentence about PlanData types could be slightly more concise without losing clarity, keeping it from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, lack of output schema, and no annotations, the description sufficiently covers input semantics and the tool's purpose. It explains why the tool is needed (key mismatch) and a notable output behavior (nested field expansion). The absence of any mention of error handling or return format is a minor gap, but overall it's complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how the command parameter works (e.g., parsing 'UpdateNodeCommand' as a class name) and the nested expansion for PlanData types, which goes beyond the schema's generic description. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lookup for command parameter keys used by execute_command/execute_commands. It specifies the exact resource ('bridge command') and verb ('look up'), and distinguishes it from siblings like execute_command by focusing on inspection rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool ('whenever unsure what params a command needs') and highlights that keys differ from constructor parameter names, giving a strong usage directive. It does not mention alternatives or exclusions, but the context signal of 27 sibling tools and a focused use case makes the guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('read plan state'), the output components, and a performance characteristic ('much smaller than get_plan'). While it does not explicitly state side-effect-free behavior, 'read' strongly implies no mutation, and the detail on output is strong. A 4 is appropriate for the lack of explicit side-effect confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the essential purpose ('PREFERRED way to read plan state'), includes a detailed but efficient list of returned data, and provides a clear comparison and usage directive. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is remarkably complete: it tells the agent what the tool returns, how to use it, and when to choose an alternative. It lacks only minor error/edge-case details, which are not expected for this simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter (project_id described as 'Project UUID'), and the description adds no additional meaning beyond that. With high schema coverage, the baseline of 3 is suitable; no extra param context is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reading plan state via a summary. It explicitly lists what is returned (components, bundles, conductors, branch points, unconnected pins, warnings) and distinguishes itself from get_plan by noting it's 'much smaller'. This goes beyond a generic verb+resource and directly differentiates from key sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'PREFERRED way to read plan state' and 'use this first, only fetch full plan if you need raw data for specific elements.' This clearly tells the agent when to use this tool versus get_plan, fulfilling the dimension completely.
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 burden. It discloses that the tool is a read-only check ('Check'), describes the return format (project:<uuid>, harness:<uuid>), and explains how to interpret the results. No side effects or rate limits mentioned, but for a simple status query this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The first sentence states the primary purpose, the second explains the output format and how to use it. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-check tool, the description fully covers what the tool does, what it returns, and how to apply the result. No output schema exists, but the description explicitly states the namespace format and integration with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline is 4. The description adds meaningful context about the output and its usage, which compensates for the lack of parameters. No parameter explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('Check') and resource ('which browser tabs are connected via the WebSocket bridge'). It uniquely identifies this tool among siblings by focusing on bridge connectivity rather than project/harness 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the return value (namespaces) and instructing to use it with execute_command/get_live_state to target a specific tab. It does not explicitly exclude alternatives, but the tool's narrow purpose makes this sufficient.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/splice-cad/splice-cad-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server