orca-copilot-mcp

by peterbedorjr

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly separated by resource and action: preset retrieval/editing, wiki search/read, settings find/describe, and plate describe/render. The only possible confusion is between get_preset and get_current_presets, and between search_wiki and read_wiki, though their descriptions do disambiguate them.
Naming Consistency4/5
The majority follow a consistent snake_case verb_noun pattern (list_presets, get_preset, set_preset_values, describe_setting, read_wiki). remember, forget, and preflight deviate from that pattern, making the naming mostly but not perfectly consistent.
Tool Count5/5
Fourteen tools is within the ideal 3-15 range and each tool covers a distinct facet: memory, presets, settings lookup, plate inspection, and wiki reference. The size feels appropriate for an OrcaSlicer copilot rather than padded or insufficient.
Completeness2/5
The set has significant gaps: descriptions explicitly defer to absent tools such as get_selection, measure_slice, and suggest_settings, so agents will hit dead ends when trying to identify the current plate/object, measure geometry, or get recommended settings. There is also no tool to delete a cloned/edited preset, leaving the preset lifecycle incomplete.
Average 4.2/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 61 commits in the last 12 weeks
- Last stable release on September 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It reveals only that a new preset is created and inherits from an existing one. It does not explain side effects (e.g., whether changes to the base propagate), failure conditions (e.g., duplicate new_name, missing base), or whether this is a mutation with persistent storage implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 10-word sentence with no filler. It front-loads the core action and resource. It could earn a 5 by adding a brief parameter or behavior note while staying concise, but it is currently well-sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-parameter tool with no annotations, no output schema, and zero schema descriptions, the description is under-specified. It does not explain what 'preset_type' means, what the return value is, or what 'inheriting' entails behaviorally. An agent cannot reliably construct a valid call from this alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds little beyond parameter names. 'base' and 'new_name' are partially inferable from the description, but 'preset_type' receives no explanation, and there is no guidance on valid values, relationships between parameters, or how each parameter is used in the cloning process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('new user preset'), and the defining behavior ('inheriting from an existing preset'). This clearly indicates a clone operation and distinguishes it from read tools like get_preset or list_presets, though it does not name any sibling directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you want to create a new preset based on an existing one. However, it does not explicitly state when to prefer this over alternatives like set_preset_values or remember, 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.
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 clearly indicates a read-only operation and describes the output contents, including effective-value resolution. It does not mention error behavior, unknown keys, or what happens when keys is null, so some behavioral ambiguity remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears in the first line, and the optional parameter behavior adds only what is needed. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a solid high-level picture of what the tool returns and how the optional parameter changes behavior. However, without an output schema it does not disclose the exact return structure, and it leaves the required parameters underspecified, so an agent may still need to guess about preset_type values or result formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the optional `keys` parameter well: it resolves specific settings to effective values and identifies the supplying preset. However, it gives no semantic detail for the required parameters `preset_type` and `name`, leaving their possible values and relationship to the preset unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read') and resource ('a preset'), and specifies exactly what is returned: the inherits chain and the settings the preset overrides itself. This distinguishes it from sibling tools like list_presets and set_preset_values, though it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives concrete guidance for optional use: 'Pass keys to additionally resolve specific settings to their effective values.' However, there is no explicit guidance about when to choose this tool over siblings such as list_presets or get_current_presets; usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'Drop' clearly implies a destructive removal, but the description does not say whether the action is reversible, what happens for an unknown key, or whether any related state (e.g., presets derived from the fact) is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one lean sentence with no filler. It front-loads the action and object, adds a concise condition, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description is mostly complete. It provides the action, target, identifier, and motivation, though it omits edge-case behavior like missing keys or confirmation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter, so the description must compensate. It explains that 'key' identifies a remembered fact, but does not describe where the key comes from, its format, or how to discover valid keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Drop') and resource ('a remembered fact by its key'), making the tool's core function clear. It distinguishes itself from the sibling 'remember' by being the inverse operation, though it does not explicitly name that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a clear condition for use: 'once it is wrong or spent.' This tells the agent when to invoke the tool, but it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral burden and does so well: it discloses persistence across sessions, that stored content is injected into the system prompt, that the tool is write-only, and crucially the upsert behavior ('Writing a key that already exists corrects it in place'). The only notable gap is that it never states what a successful call returns or how the agent confirms success, which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then builds logically through storage criteria and parameter formats, ending with the critical upsert warning. At roughly 130 words it is longer than minimal, but every sentence earns its place: the examples clarify otherwise abstract criteria and the exclusion list prevents misuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter write tool with no annotations, no output schema, and 0% schema coverage, the description covers the essentials an agent needs to call it correctly: valid topic values, key formatting, upsert semantics, and content qualification. The main omission is the return/confirmation behavior, and the topic value set is stated in prose rather than enforced as an enum, leaving room for an agent to invent an invalid value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly documents topic ('one of printer, preferences, outcomes') and key ('short lowercase slug' with examples and correct-in-place semantics), but the note parameter is only implied as the fact content, never named or formally tied to the schema. The compensation is strong for two of three parameters and leaves the third to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Keep one fact for future sessions') that clearly states the tool's function, and immediately distinguishes it from the read-oriented siblings by declaring 'this is for writing, not reading.' It does not explicitly name forget as the inverse sibling, but the write-vs-read framing is sufficient to separate it from the lookup tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit inclusion criteria ('what will still be true next week' with concrete examples) and explicit exclusion criteria ('Not what you can look up — a preset value, a setting's range — and not what happened this turn'). The exclusions map cleanly onto the sibling lookup tools even though no tool is named directly, and no guidance is given for when to use forget instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does meaningful work: it explains the output contents, the meaning of allowed_values, and the list-of-strings implication of per_extruder. It does not explicitly state it is read-only, but 'Read this before setting' strongly implies a harmless query operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states what the tool returns, the second gives actionable usage guidance, and the third clarifies two important edge-case semantics. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter describe tool with no output schema and no annotations, the description covers the purpose, the output fields, when to use it, and two non-obvious behaviors (allowed_values keys and per_extruder list format). A small gap remains because the key parameter itself is not explicitly defined, but overall this is a well-rounded description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 'key' with no description, and schema coverage is 0%. The description never directly explains that 'key' is the setting identifier or how it should be specified, leaving the agent to infer this from the tool name. It adds useful context about setting values but does not compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('a setting') and the specific information returned: label, tooltip, units, default, allowed values or numeric range. It distinguishes itself from siblings like find_settings by describing a single setting's full definition rather than searching for settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Read this before setting anything whose legal values you are unsure of.' This gives a clear trigger for invocation, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a useful semantic distinction — these are profiles, not the model — but does not explicitly state that the tool is read-only, has no side effects, or what happens if no presets are selected. For a simple getter the gap is moderate, but the description could add more behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core definition is front-loaded, and the clarifying contrast with get_selection is placed exactly where it is useful. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description provides enough context for an agent to invoke it correctly: it names the exact data returned and distinguishes it from a likely point of confusion. It does not detail the return format, but that is not essential given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline for a score of 4. There are no parameter semantics to describe, and the description does not need to add any. The schema already fully covers the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what is returned — the currently selected process, filament, and machine presets in OrcaSlicer. It also clarifies that these are profiles, not model selections, which distinguishes it from get_selection. This is a specific verb-plus-resource definition that an agent can act on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when not to use this tool: 'for what the user has clicked on and which plate they are looking at, call get_selection.' This provides clear routing to a relevant alternative. It does not explicitly contrast with siblings like list_presets or get_preset, but 'currently selected' makes the intended use case reasonably 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 burden. It usefully discloses substring matching behavior and that the tool returns short excerpts rather than full details. It does not explicitly state read-only behavior, but 'search' strongly implies it and the overall disclosure is solid for a simple lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then matching semantics, then the follow-up instruction. Every sentence adds value and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool, the description covers what it searches, how matching works, what is returned, and what to do next. It omits limit behavior details, but those are partially available in the schema and the tool's simplicity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the query parameter well (substring matching, examples), but the limit parameter receives no explanation. This partial coverage justifies a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('search settings') and explicit searchable fields: name, label, and description. It also frames itself as the way to find a setting when the key is unknown, which distinguishes it from a tool like describe_setting without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool when the setting key is unknown, and instructs the agent to follow up with describe_setting on the desired result. This both names the alternative and gives the condition that should trigger its use.
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 behavioral disclosure burden. It adds meaningful behavior beyond the schema: default scope is user presets, built-in vendor profiles are searched by substring when `contains` is provided. This helps the agent understand result selection, though pagination and exact return format are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core action, and every sentence adds necessary information. There is no filler or redundant restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with only two parameters and no output schema, the description covers the essential selection behavior and distinguishes default vs vendor search. It is slightly light on return value details and possible filtering edge cases, but it is adequate for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters usefully: preset_type is constrained to three valid values, and `contains` is a substring filter over vendor profiles. This is sufficient for basic invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('List OrcaSlicer presets') and clearly enumerates the valid preset_type values. It is easily distinguishable from sibling tools like get_preset and get_current_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: by default it returns the user's own presets, and passing `contains` searches built-in vendor profiles by substring. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explains what the tool returns for each topic form, and it explicitly describes pagination behavior: long pages arrive in parts, `truncated` indicates more content, and `hint` tells how to request it. This is meaningful behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The first sentence states the tool's core value and appropriate use. The second paragraph covers topic semantics and pagination without unnecessary detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters, no annotations, and no output schema, the description covers the essential behavior: what the tool reads, how topic maps to content, and how pagination works. It could be slightly more explicit about the `part` parameter, but the overall picture is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains `topic` semantics: a setting key yields a settings section, and a search_wiki page name yields a page. The `part` parameter is covered indirectly through the pagination explanation and the `hint` reference, which is enough to infer how to request additional parts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: reading the authoritative wiki on one topic. It clearly distinguishes the tool from search_wiki by explaining that topic can be a setting key or a page name from search_wiki, and it positions the tool as the source of truth for procedures and recommended values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this instead of relying on memory for procedures and recommended values. It also explains the two input types—setting keys and search_wiki page names—and implies search_wiki is the discovery step. It stops short of explicitly naming exclusions or alternative sibling tools, but the guidance is strong.
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 burden and does it well: it identifies the output as a rendered image and explains what each view means, including 'as shown in the UI', 'orthographic top-down', and 'unlit, smallest'. It does not explicitly state that the call has no side effects, but the read-only visual nature is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the main purpose, and presents the view options in a scannable, structured way. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output type, the main parameter semantics, and the key sibling alternative. It leaves the valid range/source of plate numbers implicit, but that is likely established by surrounding context or sibling tools, so the definition is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description adds real semantics for the view parameter by enumerating 'plate', 'top', and 'flat' and explaining each. The plate_number parameter is not elaborated, but it is self-descriptive and has a default value in the schema, so the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a rendered image of the plate for questions that are genuinely visual. It also distinguishes itself from the sibling describe_plate by contrasting image-based answers against name/structure/statistics-based answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use describe_plate first for anything answerable from names, structure, or mesh statistics, and frames this tool as the appropriate choice for visual questions. This is direct when-to-use vs when-not-to-use guidance with a named alternative.
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 burden by explaining that results are excerpts per page and that follow-up page reads require read_wiki. It does not explicitly state the search is read-only or mention result ordering, but the search operation is inherently safe and the main behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence names the resource and scope, the second explains how to phrase queries, and the third gives a concrete example and output/next-step behavior. Every sentence contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a low-complexity search tool with no output schema: it specifies what is searched, how to query, what is returned, and how to continue with read_wiki. Missing details like result limit behavior or pagination are minor given the schema default and the clear usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds real meaning to the query parameter by instructing a natural-language question rather than a key, and it links results to the page parameter for read_wiki. The limit parameter is not described, but its default is present in the schema and the core query semantics are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') with a specific resource ('the OrcaSlicer wiki') and enumerates the content it covers: calibration, troubleshooting, print preparation, and setting pages. It also distinguishes itself from find_settings by explaining that many wiki pages describe no setting, so this tool reaches content the sibling cannot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on how to query ('Ask it the question... rather than a key') and when it should be used over find_settings. It also tells the agent to pass a returned page to read_wiki for full reading, which clarifies the workflow between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses important behavioral traits: the operation edits a persistent FILE, requires an OrcaSlicer restart, and cannot target system presets. It does not fully disclose whether unspecified values are overwritten or merged, but the core side effects are clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place. The main action is front-loaded, followed by the critical operational caveat, the preferred alternative, and parameter typing. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the essential selection and invocation context: what it edits, when to prefer another tool, system-preset restrictions, and value formats. Minor gaps remain around preset_type values and exact merge/overwrite behavior, but the description is materially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates for the most complex parameter by stating that values are strings or lists of strings for per-extruder settings. Name and preset_type are left to their self-explanatory titles, which is acceptable, though possible preset_type values are not enumerated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb+resource combination: 'Edit a preset FILE.' It also explicitly states what cannot be done ('System presets cannot be edited — clone first'), which distinguishes this mutation tool from clone_preset, get_preset, and list_presets. The scope is 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: prefer suggest_settings when available, otherwise use this tool. Also tells the agent what to do with system presets (clone first). This is actionable routing information beyond any schema field.
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 behavioral burden. It discloses that the tool reads from the last saved project file, implying a read-only, file-based operation rather than a live view. It also indicates the kinds of analysis it performs (object names, part structure, mesh defects), which goes beyond a vague 'describe' action. It does not mention behavior for missing/hidden files, but for a simple read tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the core answer of what the tool reports, and the second sentence adds differentiation and data source context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema and no annotations, this description is sufficiently complete. It tells the agent what information the tool provides, why to prefer it over a visual alternative, and where the data comes from. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already covers everything, so the baseline is 4. The description adds relevant context about what the parameterless call returns, which is useful. No additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to report what is on the print plate, including objects, their parts, and mesh defects. It names specific kinds of information and distinguishes itself from image-based inspection. The phrase 'Prefer this over looking at an image' explicitly separates it from the thumbnail-related sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer this tool over looking at an image and explains the conditions: when exact names, part structure, or mesh problems are needed. This provides clear guidance that the render/thumbnail cannot provide this level of detail. It effectively routes the agent away from the image-based alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers richly: rules are deterministic ('no judgement of yours involved'), the scope includes edits not yet saved, and it 'says nothing when nothing is wrong' — a non-obvious silent-success behavior that prevents an agent from misreading empty output as a failure. It also discloses that findings carry their source settings and explicitly denies any plate-model knowledge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight paragraphs with distinct jobs: what it does, when to run it and why, then behavioral caveats. The core action is front-loaded in the first sentence, and every sentence carries non-redundant information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation, no-output-schema tool, the description covers nearly everything: implicit inputs, timing, result semantics (silence vs. findings), and its boundary with measure_slice. The one small gap is the exact structural shape of a returned 'finding' beyond 'carries the settings it came from,' which no output schema exists to compensate for.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds meaning beyond the empty schema by clarifying the implicit input: 'deterministic rules over the selected presets, including edits not yet saved' — this answers how a no-argument tool knows what to check. Since there is no parameter syntax to elaborate on, 4 is the natural ceiling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Check the settings in force against known-bad combinations.' It distinguishes itself from siblings by explicitly carving out measure_slice's domain ('overhangs, size and adhesion area' are not this tool's job) and by positioning its findings as inputs to describe_setting, which separates it from that sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use guidance: 'Run this before advising on a print, and before answering a general "what should I change".' It names the alternative for plate-geometry concerns (measure_slice) and explains why this tool takes priority — findings are facts 'worth saying first.' No timing or routing decision is left to inference.
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:

[![orca-copilot MCP server](https://glama.ai/mcp/servers/peterbedorjr/orca-copilot/badges/card.svg)](https://glama.ai/mcp/servers/peterbedorjr/orca-copilot)

Score Badge

Copy to your README.md:

[![orca-copilot MCP server](https://glama.ai/mcp/servers/peterbedorjr/orca-copilot/badges/score.svg)](https://glama.ai/mcp/servers/peterbedorjr/orca-copilot)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/peterbedorjr/orca-copilot'

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