memoire

Server Quality Checklist

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

Latest release: v2.7.9
Disambiguation4/5
Most tools have distinct purposes, with clear descriptions that differentiate them. However, the large number (50) and some overlap between similar tools (e.g., pull_design_system vs pull_design_system_rest, multiple audit tools) could cause occasional confusion for an agent.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun convention (e.g., pull_design_system, get_specs, create_spec). Some deviations exist, such as adjective_noun patterns (check_bridge_health) or noun_verb (simulation_models), but these are minor and the overall pattern is clear.
Tool Count3/5
50 tools is quite large for a single MCP server. While each tool serves a distinct purpose within the broad domain of design system management, the scope may be too broad, making the server feel heavy and potentially better split into smaller, focused servers.
Completeness4/5
The toolset covers a wide range of design system workflows: pulling, creating, generating code, auditing, simulating, and researching. Minor gaps exist, such as the lack of explicit delete operations for specs or tokens, but the overall coverage is robust.
Average 4.2/5 across 50 of 50 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 420 commits in the last 12 weeks
- Last stable release on August 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, destructive, or requires specific permissions. The verb 'convert' suggests mutation, but no safety or side-effect information is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action. It is efficient but could be slightly expanded to include more context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description provides a reasonable purpose. However, it lacks usage guidance and behavioral context, which are important for an agent to use it correctly in different scenarios.
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 covers 100% of parameters with a description for runId. The tool description does not add additional meaning beyond the schema; baseline 3 is appropriate since the schema already documents the parameter adequately.
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 action ('Convert a simulation report into a product-spec impact artifact') with a clear verb and resource. It distinguishes from siblings by specifying the output type ('artifact that agents can paste into specs'), though the term 'product-spec impact artifact' could be more concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like simulation_report or create_spec. The usage context is only implied by the tool's name and description, with no 'when not to use' or alternative suggestions.
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 exist, so the description must fully disclose behavior. It implies a read-only operation, but lacks details on side effects, authorization, rate limits, or error handling (e.g., missing run).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without superfluous words. It effectively communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter read tool, the description is adequate but minimal. It does not describe the output format or error conditions, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of 'runId'. The tool description adds 'for a run', which aligns but doesn't significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads 'model-swarm transcript memory for a run', using a specific verb and resource. It distinguishes from sibling simulation tools that perform actions like running, comparing, or exporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as simulation_report or simulation_stream. No prerequisites or usage context are mentioned.
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 fully disclose behavior. It states the tool writes files and returns next steps, but does not mention if it overwrites existing files, permission requirements, or other side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and adds necessary constraints. Every sentence is meaningful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema/annotations, the description is incomplete. It does not explain all parameters, return format, or error conditions, leaving gaps for the agent to infer.
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 50%. The description adds context about the tool's output but does not explain the 'intent' or 'hypothesis' parameters. The 'source' parameter is partially explained. Overall, the description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes Mermaid Jam-ready FigJam source artifacts from research or simulation runs, specifying the output format (.mmd/.md files). It distinguishes itself from clipboard/paste automation. However, it does not explicitly differentiate from sibling tools like simulation_export_spec.
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 indicates this tool is for file-based output rather than clipboard automation, providing some usage context. It lacks explicit guidance on when to prefer this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions planning and running hypotheses but omits any details about side effects, permissions, resource consumption, or return format, leaving significant ambiguity for an action tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose. While it earns its place by being efficient, it could include additional high-level context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain what the comparison output looks like, how results are returned, or any usage constraints like run limits or dependencies on prior steps (e.g., generating agents).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description adds no extra meaning beyond the schema. It does not explain 'rounds', 'research', or 'maxAgents' usage, and only implicitly references 'hypotheses'. The schema already describes that parameter, so the description contributes no new semantic value.
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 plans and runs multiple model-swarm hypotheses and compares outcomes for product-spec decisions, using specific verbs and resources that distinguish it from siblings like simulation_run (single run) or simulation_compare (comparison only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-hypothesis comparison, but does not explicitly state when to use this tool versus alternatives like simulation_run or simulation_plan, nor provides 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?
No annotations, so description carries full burden. Discloses that writing only occurs if approved=true, and writes five spec types via Memoire registry. Omits side effects, error states, or rollback behavior, leaving 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a prerequisite note, front-loaded with purpose. Concise, no wasted words, but could benefit from clearer separation of conditions.
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?
No output schema, so description should explain return values or errors; it does not. Five parameters, only two described. Lacks details on error handling or side effects, leaving the agent underinformed.
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 40% (only approved and research have descriptions). Description reinforces approved's safety gate but does not explain hypothesis, intent, or runId, failing to compensate for low coverage.
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?
Description clearly states it writes research-backed Atomic Design specs from ResearchStore V2, listing five spec types. Differentiated by prerequisite mention of research_design_package for preview, but does not explicitly distinguish from siblings like create_spec.
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?
Explicitly states prerequisite (research_design_package) and requirement (approved=true) for writing. Provides clear context for when to use, but lacks when-not-to-use or alternative tools.
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 states the tool 'generates' but does not disclose whether it modifies state, returns the cohort, or has side effects. There is no mention of idempotency, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose and key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is somewhat adequate but lacks behavioral details and return value information. It covers the basic purpose and parameter hints, but leaves gaps for an agent to fully understand usage consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds context like '20-60' (matching count range) and 'model-swarm' (matching adapter default), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'agent model-swarm cohort', and distinguishes itself from siblings like simulation_run by specifying 'without starting a run'. It is specific enough to differentiate from other simulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cohort generation without a run, but does not explicitly state when to use this tool over alternatives like simulation_run or simulation_plan. More guidance on prerequisites or context would improve clarity.
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 provided; description does not disclose any behavioral traits (e.g., read-only, side effects, error handling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description; for a simple export tool it is adequate, but lacks details on output format or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one simple parameter; description adds context about report contents but not about the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action 'Export a simulation report' and lists specific contents (recommendations, risks, etc.), distinguishing it from sibling simulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any prerequisites or use cases.
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 full burden. It discloses that the tool operates on a completed run (read-only implication) but does not elaborate on behavioral traits such as state changes, permissions, or rate limits. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core action and resource. It is efficient but could benefit from slightly more detail about the interview process (e.g., that it is async or returns a message).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no output schema), the description is minimally adequate. It covers the purpose and a key prerequisite (completed run), but lacks details on return value or conversational nature, which may be inferred but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all parameters (runId, agentId, prompt). The description adds context about 'simulated product stakeholder' but does not enhance understanding of parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Interview' and identifies the resource as 'simulated product stakeholder,' clearly distinguishing this tool from siblings like simulation_run, simulation_transcript, or simulation_compare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'from a completed local or model-swarm run,' which implies a prerequisite but does not explicitly state when to use this versus alternatives. No guidance on when not to use or which sibling to prefer in other cases.
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 does state that the tool does not modify source files, which is helpful. However, it lacks details on authorization, rate limits, error handling, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear paragraphs: one for purpose and return value, one for usage guidance. Every sentence adds value 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 explains the return format (JSON with specific fields), confirms no file modifications, and provides usage context. For a tool with no output schema, it is fairly complete, though it could mention limitations or what the audit process entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what is already in the parameter descriptions (target, maxFiles, screenshotPath).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: auditing UX tenets and traps from evidence or screenshots, and lists the return fields. However, it does not explicitly distinguish itself from sibling tools like 'audit_interface_craft' or 'analyze_design'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('when an agent needs a focused design critique packet') and lists specific areas evaluated. It does not specify when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It describes the return format and technical behavior (local vs. model-swarm adapter), but lacks details about failure modes, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading the purpose, then prerequisites and technical details, then the output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description outlines the return structure clearly. It covers prerequisites and default behavior. Minor gaps exist (e.g., error handling), but overall it is sufficiently complete for a tool with 7 parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 7 parameters. The description adds minimal extra context (e.g., default values for adapter and name), but does not significantly enrich understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Create' and resource 'clean-room product simulation scenario', but lacks explicit differentiation from sibling simulation tools like `simulation_run` or `simulation_generate_agents`.
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 provides a prerequisite and explains when to use the tool (to create a scenario from research evidence), but does not explicitly state when not to use it or list alternative approaches among 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?
With no annotations, the description fully bears the burden of behavioral disclosure. It details the return object (entryFile, files, findings, critique), error conditions (specName not found, quality-gate blocking), and the effect of force:true. It also notes that critique is informational and does not block. This is fairly comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences: action and folder structure, return value, and error handling. It is front-loaded with the main purpose. Minor waste: the phrase 'informational only, never blocks' is slightly redundant with earlier 'critique is an AI layout score... — informational only, never blocks.' Overall efficient.
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 no output schema, the description adequately explains the return object, error states, and the critique's nature. It covers quality-gate findings and force override. However, it does not specify the exact format of 'files[]' or 'findings', which could be useful for an agent. Still, it is largely complete for a code generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description repeats the schema's parameter descriptions without adding new semantics (e.g., specName is case-sensitive and must match get_specs output; force is for overriding findings). No additional context is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates code from a saved spec and writes to atomic design folders. It uses a specific verb and resource, distinguishing it from sibling tools like get_spec or create_spec, though it could more explicitly contrast with them.
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: it generates code from a saved spec, with errors for missing specName and quality-gate findings. It mentions force:true for override but does not explicitly state when to use this tool versus alternatives like scaffold_swiftui_files or other code generation tools.
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 bears the full burden. It correctly implies a read-only operation ('compare completed simulation runs') and lists the comparison dimensions. However, it does not disclose behavior for incomplete runs, limits on number of runs, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, directly front-loading the verb 'Compare'. Every word contributes to defining the tool's purpose with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the basic action and metrics. However, it omits the return format (e.g., what the comparison output looks like), which an agent would need to interpret results. Adequate but not fully complete.
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 100% coverage for the single parameter 'runIds', describing it as 'Simulation run ids.' The tool description adds context by stating what the comparison does with those IDs (compare by specific metrics), which adds meaning beyond the schema. However, no additional details on format or acquisition are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares completed simulation runs by specific metrics (adoption, confidence, evidence coverage, risk, and cost). The verb 'compare' and resource 'completed simulation runs' are precise, and the listing of metrics distinguishes it from sibling tools like simulation_report (single run) and simulation_list_runs (list only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when comparing completed runs, but provides no explicit guidance on when to use this tool versus alternatives (e.g., simulation_report for single-run details). It also does not mention prerequisites like obtaining run IDs via simulation_list_runs.
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 type and key fields, but lacks details on error behavior, idempotency, or whether the run is synchronous or asynchronous. Given the absence of annotations, more behavioral disclosure would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a clear prerequisite and return description. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains what the tool returns but lacks details on the SimulationRun structure, error scenarios, or potential side effects. With 5 parameters and no output schema, additional context on behavior and constraints would improve completeness.
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 60%, and the description adds meaning by specifying the source of scenarioId. However, it does not explain the purpose or effects of other parameters like rounds, maxAgents, or allowLiveModels, which are only partially covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Run') and the resource ('prepared local or model-swarm product simulation scenario'). It distinguishes from sibling tools like simulation_plan by mentioning prerequisites, though it could be more explicit about its unique role among the many simulation siblings.
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?
Explicit prerequisite to call simulation_plan first and pass scenario.id provides strong usage guidance. However, it doesn't mention when not to use this tool or compare it with alternatives like simulation_run_matrix or simulation_stream.
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 mentions reading from a local file path, which implies a read-only operation, but does not disclose details like what happens if the run doesn't exist or any prerequisites. It is truthful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, and it front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read operation but lacks information about the output contents (e.g., status fields) and assumes prior knowledge of the runId context. With no output schema, more details would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter runId, which is described as 'Simulation run id.' The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Read) and the resource (local simulation run status) with a specific file path. It distinguishes from siblings like simulation_list_runs and simulation_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing the status of a specific simulation run, but does not provide explicit guidance on when to use this tool versus alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'summarize,' which suggests a read-only operation, but it does not explicitly state whether it is read-only, destructive, or has side effects. The behavioral context is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's purpose. It is concise with no extraneous words, front-loading the key action and subject.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter and no output schema, the description adequately summarizes the purpose and mentions the output type (token and cost usage). However, it could be more complete by hinting at the response format or whether the summary is aggregated.
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 input schema covers 100% of the single parameter (runId) with a description. The overall description adds meaning by indicating that the tool returns token and cost usage, which provides context for the output beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'summarize' and specifies the resource as 'token and cost usage for a simulation run,' which clearly states the tool's function. It distinguishes itself from sibling simulation tools like simulation_run or simulation_status by focusing on costs and tokens.
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?
No explicit guidance on when to use this tool versus alternatives such as simulation_report or simulation_models. The usage is implied: after a simulation run to get cost summaries, but no when-not or alternative recommendations are provided.
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 burden. It discloses the return format (base64 image data with mime type) and error conditions (isError if not connected or invalid node). It does not discuss potential side effects (assumed read-only) or rate limits, which leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections: purpose, prerequisites, return value, usage hints, errors. Every sentence serves a purpose with no superfluous 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?
No output schema is provided, but the description adequately explains the return value. It covers prerequisites, error handling, and integration with other tools. Minor improvements could include size limitations or additional limitations, but overall it's complete for a tool with simple parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters already have descriptions. The tool description adds minimal new meaning beyond what's in the schema (e.g., format preference, omitting nodeId for full page). Baselines at 3 since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture a screenshot') and the resource ('Figma node or current page'). It distinguishes from sibling tools by being the only screenshot tool, and provides guidance on format preference (SVG vs PNG) which adds clarity.
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?
Explicit prerequisites are given (bridge + plugin connected, node IDs from other tools). It also positions the tool in the self-heal loop and suggests feeding output into analyze_design. However, it does not explicitly state when not to use this tool or mention alternatives.
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 full behavioral transparency. It details the return values (scores, issues, evidence locations, etc.) and input sources (code or URL). It implies a read-only diagnostic operation and does not mention any side effects. However, it could clarify required permissions or potential rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, output details, and usage guidance. It is front-loaded with the primary action and avoids redundancy. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, no output schema, and no annotations, the description provides sufficient context: it explains the output structure and usage timing. It could mention error handling or edge cases but is otherwise complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a description in the schema. The tool description adds no additional meaning beyond what the schema already provides. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diagnoses UI quality for shadcn/Tailwind apps from code or a URL. The verb 'diagnose' is specific, and the resource 'app quality' is well-defined. However, it does not explicitly differentiate from sibling audit tools like 'audit_interface_craft' or 'run_audit', which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'before planning UI fixes, exporting a registry, or giving an AI editor context on real app design debt.' This is clear context, but it does not mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It mentions the tool returns an item and errors on unknown names, but does not explicitly state read-only or other side effects. Adequate but could be more 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, return fields, error handling. Extremely concise and front-loaded with the most important information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists the return fields and explains the error condition. It is complete for a simple retrieval tool, though deeper details on return structure would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already described in the input schema. The description adds no new 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a single shadcn registry item, listing specific fields (files, targets, etc.), which distinguishes it from sibling tools like get_shadcn_registry that likely list items.
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 implicitly advises using get_shadcn_registry first to discover valid item names, providing a clear usage chain. However, it lacks explicit when-not-to-use or alternative tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states non-mutating behavior for approved=false and that writing only modifies the registry spec. It also mentions quality gates remain intact. Missing details on permissions or side effects, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs. The first sentence provides a clear summary. Every sentence adds value, though it could be slightly more streamlined without losing clarity.
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 10 parameters and no output schema, the description explains the core functionality, key parameter (approved), and the return format for dry-run (JSON plan with path, guardrails, commands). It does not cover all edge cases or errors, but is sufficient for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the 'approved' parameter and the overall workflow, but does not significantly enhance understanding of other parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it previews or writes a spec-first Atomic Design scaffold for agent-created files. It distinguishes between dry-run (approved=false) and write (approved=true) modes, and clarifies that writing only produces a registry spec, not code. This contrasts with sibling tools like generate_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use dry-run (for preview) versus writing (approved=true). It also notes that generated code requires additional steps (generate_code or memi generate). However, it does not explicitly state when not to use this tool or compare directly to siblings.
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 read-only nature and pagination behavior, but does not discuss ordering guarantees, performance implications, or return format. With zero annotations, more detail would be warranted for a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the core purpose and immediately follow with key usage guidance. Every word earns its place; no fluff.
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 covers the main behavior and pagination, but lacks details on output structure (no output schema), ordering key, or performance characteristics. For a moderate-complexity tool with no annotations, additional context would improve completeness.
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 input schema already describes all three parameters (100% coverage). The description adds value by explaining how offset/limit should be used together for pagination, giving practical guidance beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Read') and the resource ('persisted simulation events in stream order'), distinguishing it from siblings like simulation_transcript or simulation_compare by emphasizing stream order and pagination.
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 advises using offset/limit for pagination to avoid materializing the full event log, providing clear usage guidance. It does not explicitly state when not to use this tool or mention alternatives, but the pagination advice covers a key use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool audits interface craft and returns a JSON report, implying a read-only analysis. It does not mention side effects, required permissions, performance characteristics, or limitations. The description adds some context (e.g., use cases) but lacks details on whether it modifies anything, rate limits, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long. The first sentence succinctly states the core function. The second sentence efficiently communicates the return type, usage scenarios, and companion tools. No unnecessary words or repetition. Perfectly front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema), the description provides sufficient context: input sources, return structure (score, critique, dimensions, findings, topOpportunities), and usage guidance. It mentions partner tools for additional context. The only gap is the lack of behavioral details, but the description covers the essential decision-making information for an AI agent.
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 100%, so the baseline is 3. The description adds value beyond the schema by explaining that 'target' defaults to the current project root and that maxFiles is used 'when target evidence is used.' It also clarifies that screenshotPath is optional and intended to 'attach to the craft audit.' This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Audit interface design craft from local app-quality evidence or a screenshot artifact.' It specifies the resource (interface design craft), the action (audit), and the input sources (local evidence or screenshot). The mention of the return type (InterfaceCraftReport JSON) and specific sub-dimensions further clarifies purpose. It also distinguishes from sibling tools by naming partners (diagnose_app_quality, audit_ux_tenets_traps).
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 recommends when to use the tool: 'Use before UI edits or after a redesign; pairs with diagnose_app_quality and audit_ux_tenets_traps.' This provides clear context and partnering tools. However, it does not mention when not to use it or contrast with alternatives like 'run_audit' or 'plan_ui_fixes,' which would elevate it to 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?
No annotations provided, so description carries full burden. It discloses the non-destructive nature ('This tool never modifies source files') and describes the return structure, but lacks details on prerequisites or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs front-load key information: function, return structure, safety, and usage. 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given limited parameters and no output schema or annotations, the description adequately covers purpose, usage, and safety. However, it does not explain how to obtain diagnosis evidence, a minor 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 coverage is 100% with both parameters described. The description adds no meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build a dry-run UI fix plan' and distinguishes from sibling tools by emphasizing it never modifies source files, making its purpose distinct from apply tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this tool: to decide what a human or coding agent should patch before calling memi fix apply or making manual edits.' This defines when to use it but does not list alternative tools for similar tasks.
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 reveals that the tool is 'local-first' (suggests no network dependency) and does not mutate files or run Xcode, accurately conveying a read-only, non-destructive behavior. It could further disclose if it requires any local resources or has side effects on state.
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 unnecessary words. The first sentence captures the core purpose, and the second provides usage context and important caveats. Very efficient.
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 no output schema, the description lists the contents of the brief (mission, skill triggers, availability policy, etc.), which compensates well. It also covers when to use and what it does not do. A minor gap: it does not explain how the parameters affect the output beyond schema defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (detail, intent, platform). The description does not add additional meaning beyond the schema, such as how 'intent' influences the brief or how 'detail' levels map to output structure. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it prepares a design and verification brief for Apple platforms, listing specific contents (mission, skill triggers, etc.). It distinguishes from siblings like `prepare_design_agent_brief` by emphasizing 'Apple-platform' and 'local-first', and specifying target technologies (SwiftUI, SwiftData, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before creating or changing SwiftUI, SwiftData, App Intents, Liquid Glass, or concurrency-sensitive UI.' It also clarifies what it does not do ('does not run Xcode or mutate files'). However, it does not explicitly state when not to use or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that live execution is opt-in and that unavailable providers fall back to deterministic clean-room simulation, which is critical behavioral context beyond a simple list. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence immediately states the main purpose, and the second adds key behavioral nuance. Perfectly front-loaded and concise.
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 tool with no parameters and no output schema, the description provides sufficient context about what is listed and the behavioral nuance. However, it doesn't describe what fields the list contains, which would enhance completeness slightly.
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 schema coverage is 100% by virtue of emptiness. The description adds meaning by specifying the scope ('Codex-first model profiles for Memoire simulations') and fallback behavior, providing value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'Codex-first model profiles available to Memoire model-swarm simulations', with a specific verb ('list') and resource ('model profiles'). It distinguishes from sibling tools like simulation_run by focusing on listing available models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing models before simulations, but does not explicitly state when to use this tool versus alternatives (e.g., simulation_list_runs). It lacks exclusions or alternative suggestions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details return structures per mode, error conditions, and prerequisites. It discloses that the tool is a read/analysis operation (no mention of mutation). The description could be improved by explicitly stating non-destructive behavior.
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 well-structured: purpose, prerequisites, outputs per mode, errors, mode explanations, and use case. Every sentence adds value. It is slightly long but necessary given the tool's complexity.
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?
No output schema exists, so description must explain return values, which it does thoroughly. It covers prerequisites, errors, and mode distinctions. Minor gaps: missing explicit statement that nodeId is optional and defaults to entire page, and no differentiation from similar analysis tools like diagnose_app_quality.
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 100%, so the baseline is 3. The description adds value by explaining each mode's purpose and output beyond the schema, plus error handling. It does not delve into parameter details but provides sufficient context for mode selection.
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: 'Capture a Figma node and analyze it with configured AI vision.' It specifies the resource (Figma node) and the analysis types (general, accessibility, spec-compliance), distinguishing it from sibling tools like capture_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (bridge + plugin, vision-capable AI provider) and explains when to use each mode. It also situates the tool within a self-heal loop, offering clear context for usage. However, it does not explicitly state when not to use it versus alternatives.
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?
Without annotations, the description carries full burden. It discloses return structure (full spec JSON) and error behavior. Adequate for a simple fetch operation; no side effects or auth mentioned but not necessary here.
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 sentences, front-loaded with purpose, then return structure, then error handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose, return type, error handling, and relationship to a sibling. Nothing missing given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the schema's parameter description verbatim, adding no new meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Fetch the full body of one spec by name' – a specific verb and resource. Distinguishes from sibling 'get_specs' (which lists names) and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions error condition (isError if name not found) and directs to use get_specs first to list names. Provides case-sensitivity detail. Lacks explicit when-not-to-use beyond the name-unknown case.
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 fully covers behavior: it reads persisted artifacts, returns HTML+markdown, lists missing sections, and describes the redact parameter's effect. It does not mention side effects or authorization, but as a read-only composition, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey purpose, prerequisite, return structure, and parameter effect. The first sentence is dense with clauses, but every part adds value. Minor improvement could be breaking into points, but it remains clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count (1), no output schema, and many siblings, the description provides all necessary context: prerequisite, output shape, parameter behavior, and handling of missing data. It leaves no gaps for this tool's role.
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 100% with a clear description for the single boolean parameter. The tool description adds useful context: redact=true strips evidence excerpts while keeping paths for NDA-safe sharing, going beyond the schema's brief explanation.
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 specifies the verb 'Compose' and resource 'design-health report', lists included audits (app quality, UX tenets/traps, etc.), and distinguishes from siblings by naming the prerequisite diagnose_app_quality. It is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite (run diagnose_app_quality or CLI audits) and notes that missing sections are listed, not silently omitted. It advises that the output is static content for writing anywhere. No explicit 'when not to use' but context strongly implies this tool is for report generation after audits.
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 and discloses the returned structure ($schema, name, homepage, items[] with details) and a special mapping rule (tokens map to registry:theme). This provides solid behavioral insight beyond the schema, though it could mention side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-structured sentences with no redundancy. The first sentence states the core purpose, the second lists return fields, and the third references a sibling tool. Every sentence is necessary and front-loaded.
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 no output schema and no annotations, the description covers the tool's purpose, output structure, and a sibling link. It lacks explicit prerequisites (e.g., workspace must have component specs) but is otherwise sufficient for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the purpose of each parameter: 'name' as the registry name to embed and 'homepage' used for generating /r/*.json and Open-in-v0 metadata. This goes beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a 'shadcn registry.json-compatible index' from the workspace, with a specific verb and resource. It also distinguishes itself from the sibling 'get_registry_item' by noting the latter handles single items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for building a full registry index and explicitly references an alternative for single items ('For a single item use get_registry_item'). However, it does not fully specify when not to use it or provide more detailed usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the return structure (JSON with mission, evidenceCommands, etc.) and states it is local-first without external calls. No annotations exist, so the description carries the burden; it discloses non-destructive, offline behavior. Does not mention side effects, but likely none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a returns note. The main purpose is front-loaded, and every sentence provides essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return fields. It explains the tool's role as a preparation step and local-first nature. Could elaborate on 'cost-awareness' but overall complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description adds minimal parameter insight beyond the schema; it mentions 'intent' and 'target' but no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prepares a 'cost-aware design-agent brief' for UI editing, specifying the exact verb-resource combination. It differentiates from siblings by positioning itself as the first MCP call for design/audit/refactor tasks.
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?
Explicitly instructs to use 'as the first MCP call when a coding agent is asked to design, polish, audit, refactor, or generate interface code'. Also clarifies it is local-first and doesn't call external services, implying 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?
Clearly states the tool is non-mutating, which is a key behavioral trait. Describes the return object structure. With no annotations, this is good coverage, though it could elaborate on potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence states purpose, second covers return details and alternatives. Efficient and front-loaded.
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?
Covers purpose, return, and key sibling differentiation. Could elaborate on how the optional simulation run affects the package. No output schema, but return shape is described. Adequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters beyond the schema descriptions. No extra guidance on parameter combinations or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the action 'Preview' and the resource 'research-backed vibe design package from ResearchStore V2 plus an optional simulation run'. It clearly distinguishes from siblings 'research_generate_specs' and 'mermaid_jam_export' by stating their different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (preview, non-mutating) and provides specific alternative tools for writing specs ('research_generate_specs') and exporting FigJam files ('mermaid_jam_export'). Also mentions the optional simulation run 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?
No annotations present, so description bears full burden. It discloses that approved=false is non-mutating, and writes are safe (no project file alteration, no overwrite). Also lists generated files. Could mention error handling or permissions, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with purpose and behavior. Every sentence provides essential information with no redundancy. Efficiently covers dry-run, write mode, safety, and file types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, high schema coverage, no output schema, the description clarifies core behavior and safety. However, it doesn't describe the output format (e.g., structure of dry-run plan). Slight gap but acceptable given tool's nature.
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 100% with descriptions for each parameter. The description adds context beyond schema by explaining the purpose of `approved` (dry-run vs write) and how `kind` affects file generation. This adds value.
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 'previews or writes a deterministic SwiftUI feature scaffold' and lists specific file types generated (view, model, preview, test). This distinguishes it from sibling tools like `generate_code` which may be more generic.
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?
Explicit guidance is given: default approved=false is non-mutating (dry-run), set approved=true only after reviewing the plan. It also states writes never alter Xcode project files and refuse to overwrite. No direct comparison to siblings, but context is clear enough for 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, the description discloses error behavior ('Never throws, returns empty store'), prerequisites (reads from local .memoire/research/), and data population methods. It lacks explicit auth needs but the read-only nature is 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 well-structured with separate paragraphs for prerequisites, returns, error behavior, and usage. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains the return shape including specific fields like evidenceObservationIds and findingIds. It covers error behavior, prerequisites, and how data is populated, making it fully informative.
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 100%. The description adds meaning beyond the schema by explaining the default behavior (lightweight overview) and advising to request only needed sections to keep payload small.
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 explicitly states the verb ('Load and return') and the resource ('project's user research V2 store'), listing specific components like observations, findings, personas, etc. It clearly distinguishes from siblings like analyze_design or compose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: before running compose with research-driven intent, to inspect research context, or verify import/synthesis success. It also suggests combining with compose. While it doesn't explicitly state when not to use, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: never throws, returns 0 height/1 line for unparseable fonts, and details conditional return fields (overflow, breakpoints). It honestly sets expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient paragraphs: first explains function and returns, second gives use case. No wasted words; every sentence adds value.
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?
Despite no output schema, the description fully explains return values and conditions. Covers behavior, usage, and parameter hints. Complete for a simple prediction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context (e.g., use same font as target UI) but mostly repeats schema info. Does not significantly extend understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'predict' and the resource 'text layout', and distinguishes itself from sibling tools by focusing on pure text measurement without browser, Figma, or AI dependencies.
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?
Explicitly states when to use ('to verify labels or body copy fit fixed containers or maxLines constraints before generating designs or code'), but does not mention when not to use or explicitly compare to alternatives. Implicit differentiation is clear given no sibling does the same.
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 fully discloses behavior: it fetches design data via REST, requires specific environment variables, returns a structured object, and can fail with specific error codes. It also notes it is headless and does not require a plugin. This is comprehensive for a read-only 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 three sentences with a bullet-like line for errors and usage. It is front-loaded with the core purpose, every sentence adds essential information, and no words are wasted. Structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers prerequisites, return type, error conditions, and operational context (CI/headless). It provides everything an agent needs to decide and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage. The description adds value by documenting external dependencies (env vars) that are not in the schema, guiding the agent on setup. For no-parameter tools, the baseline is 4, and the description meets it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it pulls the design system from Figma via REST API, explicitly distinguishing it from the plugin-based 'pull_design_system' sibling. The verb 'pull' and resource 'design system from Figma' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies prerequisites (FIGMA_TOKEN and FIGMA_FILE_KEY env vars) and recommends use in CI/headless. It also mentions the equivalent CLI command, providing context for when to use this tool. However, it does not explicitly compare with every sibling or state when not to use it, slightly reducing clarity in exclusion.
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?
No annotations provided, so description bears full burden. It fully describes behavior: deterministic, offline, regex/string checks, return format with findings and summary. No side effects or destructive actions implied, and limitations are clearly stated.
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?
Well-structured into clear sections: purpose, exclusions, prerequisites, return format, and usage note. Slightly lengthy but each sentence adds value. Front-loaded with main verb 'Check'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters and no output schema, the description fully explains return format, mechanism, limitations, and integration context. No gaps remain for an agent to understand the tool's capabilities.
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?
Both parameters are described in the schema with 100% coverage. Description adds no additional semantic value beyond the schema (e.g., 'target' defaults to current root is in schema). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it checks real source files for objectively-checkable rules from specific design docs (ATOMIC_DESIGN.md, MOTION_VIDEO_DESIGN.md) using a linter-like mechanism. It distinguishes itself from sibling tools like 'run_audit' by specifying its deterministic, post-hoc nature.
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?
Provides explicit when-to-use context (post-hoc verification), prerequisites (none, offline), and alternatives (CI integration with 'memi audit --skill-compliance'). Also clarifies what it does not do (doesn't read skill docs at check time, doesn't enforce obedience).
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 fully carries the burden of behavioral disclosure. It explains the scraping and parsing process, the AI synthesis step, the exact structure of return values for both modes, and possible errors (unreachable URL, missing key). No contradictions or omissions.
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 well-structured but slightly verbose. It front-loads the main action and output, then covers prerequisites, return formats, errors, and use cases in a logical order. Every sentence adds information, but some details (e.g., the full list of token types) could be condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return values for both raw modes and lists error conditions. It covers the complexity of the tool (multiple token types, AI synthesis, two output formats) and provides clear use cases, making it fully complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the 'raw' parameter's effect (returns raw tokens vs AI-synthesized document) and provides example URLs for the 'url' parameter, clarifying format and accessibility requirements. This goes beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('scrape') and resource ('public URL'), and details exactly what is extracted (CSS custom properties, colors, fonts, etc.) and the optional synthesis of DESIGN.md. It distinguishes itself from siblings like 'pull_design_system' and 'get_tokens' by explicitly framing the tool as reverse-engineering a reference site's system or extracting tokens for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool (to reverse-engineer or compare design systems) and includes prerequisites (publicly accessible URL, configured AI provider for synthesis). It also explains the two modes (raw vs AI-synthesized) but does not directly list alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosure. It describes the return object structure, preconditions, and error states. It does not mention authentication details beyond connectivity, but that is acceptable for a read-only tool.
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 well-structured and front-loaded with purpose, but includes several sentences that could be slightly condensed. However, it remains efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking output schema, the description provides a detailed return format including optional fields (layoutMode?, padding/sizing/itemSpacing?, etc.), prerequisites, error conditions, and usage guidance. It is fully complete for a read-only selection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100% trivially. The description adds value by detailing the output structure, which is necessary since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves selected nodes with layout/style details, distinguishing it from siblings like capture_screenshot and analyze_design which operate on node IDs.
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?
Explicitly lists prerequisites (bridge + plugin connected), edge case (empty selection returns []), error condition (isError if not connected), and recommends usage for obtaining node IDs or reading layout/variants before writing a spec.
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 bears full burden. It states determinism, no prerequisites, no Figma, no AI, and describes return structure. It explains different focus modes but doesn't cover all edge cases or error conditions.
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?
Well-structured with separate lines for purpose, prerequisites, return, and focus details. Front-loaded with main purpose. Slightly verbose but each sentence adds value.
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 3 parameters, no output schema, and no annotations, description is fairly complete. Covers return format, focus options, and sibling distinction. Could mention behavior for other focus values or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds significant value: explains focus values 'contrast' and 'skill-compliance' in detail, clarifies target default, and implies format for maxFiles. Goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'run' and resource 'audit' with specific domains: WCAG contrast, token completeness, spec accessibility. It explicitly distinguishes from sibling analyze_design, stating this is systematic spec/token compliance vs AI vision review.
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?
Provides explicit when-to-use (systematic compliance checks) and when-not-to-use (use analyze_design for AI vision review). Also lists focus options like 'contrast' and 'skill-compliance' with their behaviors.
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 covers the basic behavior (listing runs with lightweight summaries) and implies read-only nature, which is sufficient for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, and the purpose is front-loaded. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple listing tool with no parameters and no output schema. The description mentions 'lightweight summaries' but could specify what fields are in the summary for full completeness.
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 no parameters, so the description doesn't need to add meaning beyond the schema. Baseline 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('persisted simulation runs'), and differentiates from sibling tools by specifying its use for discovering runIds for other simulation 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool to discover runIds for specific sibling tools, providing clear guidance on when and why 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?
No annotations, so description carries full burden. Describes return format { updated, name, pushedToFigma, reason? } and promises that failed pushes are reported, never silently dropped. Also notes error on missing token. Lacks detail on idempotency but sufficient.
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?
4 sentences, front-loaded with main action. Succinct but could merge repeated 'optionally pushing to Figma' reference. Still efficient for the information provided.
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?
No output schema, but description explains return value. Covers prerequisites, usage, error handling, alternative. For a tool with 3 params and nested objects, this is complete and informative.
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 100% (baseline 3). Description adds context: token name matching logic (exact then case-insensitive path), values map is a merge (only specified modes updated), and pushToFigma defaults to false. Adds meaningful value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Update a design token value in the local registry, optionally pushing to Figma', providing a specific verb and resource. It distinguishes from sibling 'sync_design_tokens' which is for bulk Tailwind mapping.
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?
Lists prerequisites: token must exist (names via get_tokens) and Figma connection only for pushToFigma. Explicitly states alternative: 'For bulk Tailwind mapping use sync_design_tokens'.
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 full responsibility and excels: it states the tool is read-only, validates caller-supplied JSON, never fetches URLs, reads/writes files, or executes corpus content. It also describes the return value as 'byte-capped context plus inclusion counts.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences that front-load the purpose, follow with constraints, and end with usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 2 required, no output schema), the description is complete: it explains the two modes, the constraints (read-only, no side effects), and the return type. No output schema is necessary because the return is adequately described.
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 57% (4 of 7 parameters have descriptions). The description adds context by explaining the two modes and the role of 'entries' for mode=corpus, which goes beyond the schema's enum descriptions. However, it does not elaborate on all parameters, so it does not fully compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Normalize design-systems-mcp corpus data into compact, deterministic agent context.' It uses a specific verb ('normalize') and resource ('corpus data'), and distinguishes it from sibling tools like 'pull_design_system' which are likely for retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use mode=corpus with a native manifest plus filename-keyed entries, or mode=category with the proposed category-manifest/v1 envelope.' It also clarifies what the tool does not do (e.g., no URL fetching). However, it does not explicitly compare to sibling tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses prerequisites, return structure ({ tokens, components, styles, lastSync }), and specific error message. While it implies updating the local registry, it does not explicitly state side effects like overwriting existing data. Still, it provides substantial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: four sentences covering purpose, prerequisites, return format, errors, and usage timing. Front-loaded with the main action. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is remarkably complete: it explains what the tool does, prerequisites, error handling, return shape, and provides references to sibling tools for verification and inspection. No gaps detected.
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 input schema has zero parameters, and the description adds no parameter details (none needed). Baseline of 4 applies per rubric for case with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pulls the full design system from Figma into the local registry, specifying tokens, components, and styles. It distinguishes from siblings like get_tokens (inspection only) and pull_design_system_rest by emphasizing 'full' and the integration with a Figma bridge.
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?
Explicit preconditions (Figma bridge running, plugin connected) with verification via check_bridge_health and start command `memi connect`. Recommends running at session start or after designer changes, and suggests inspection with get_tokens. Also mentions error condition 'Figma not connected'.
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?
No annotations provided, so description carries full burden. It discloses depth parameter effects, potential slowness at high depths, and return structure. For a read-only tree retrieval tool, this is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. Purpose is front-loaded. Every sentence adds value: purpose, prereq+output, depth guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains return structure (array of pages with id/name/type/children) and integration with other tools. For a simple tool with one parameter, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (depth) with 100% schema coverage. Description adds value beyond schema by explaining depth levels (1=pages only, 2=top-level frames, 3+=component internals) and performance impact. Provides practical guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get the hierarchical node tree of the current Figma file' with a specific verb and resource. It distinguishes from siblings like capture_screenshot and analyze_design by specifying it returns node structure.
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?
Includes prereq (bridge + plugin connected) and mentions that IDs feed capture_screenshot and analyze_design, indicating integration. However, it does not explicitly state when not to use it or list alternatives.
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, the description fully covers behavioral traits: it is a getter that never throws, works offline, and explains the meaning of clientCount=0. The return structure with possible status values and error field is documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a clear return structure. Every sentence is informative, ending with a directive. No wasted words.
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?
The description covers purpose, usage context, behavioral guarantees, and return value meaning. For a health-check tool with no parameters and no output schema, it provides all necessary information 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?
No parameters exist (schema coverage 100%), so baseline is 4. The description adds value by detailing the return object fields, compensating for lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks health of the Figma WebSocket bridge, specifying the resource (bridge) and action (check health). It distinguishes from siblings by focusing on health monitoring rather than design analysis or other tasks.
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 advises to call this first before any Figma-dependent tool, providing clear when-to-use guidance. It also notes it works without a plugin connected and never throws, setting expectations.
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?
No annotations exist, so description fully covers behavior: returns success message, errors with Zod details, and lists schemas for different spec types, ensuring the agent understands outcomes and pitfalls.
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?
Well-structured with a concise action line, then return/error info, then schema details. Slightly lengthy due to schema enumeration, but the detail is valuable and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description covers input, output, errors, overwrite behavior, and type-specific requirements, making it fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'spec' is a JSON string; description explains required fields (like 'type') and validates via Zod. It also details the schema structure for each spec type, adding substantial context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'create or overwrite' and the resource 'spec in the registry', with Zod validation. It distinguishes from sibling tools like get_specs and update_token.
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?
Explicitly warns about silent overwriting and advises to check get_specs first, providing clear when-to-use and when-to-avoid guidance.
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?
No annotations are provided, but the description thoroughly discloses behavioral traits: it never throws, behaves correctly even when provider pricing is not configured (returns unknown), and is an in-memory tracker. This covers all relevant behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a purpose: stating functionality, behavioral notes, and return structure with usage guidance. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides sufficient information: it explains what the tool does, its behavior, and what it returns. The usage guidance ties it to specific sibling tools, making it contextually 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?
There are no parameters, so schema description coverage is 100%. The description adds meaning by listing the return fields (calls, inputTokens, etc.), which compensates for the lack of an output schema and provides context beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns AI token usage and estimated cost for the MCP session, specifying it is an in-memory tracker. It distinguishes itself from sibling tools by mentioning it is used to monitor spend from specific tools like analyze_design, design_doc, or compose.
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 'Use to monitor spend from analyze_design, design_doc, or compose,' providing clear guidance on when to use this tool versus alternatives among the sibling tools.
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?
Describes the operation as cheap (implying low cost/fast), specifies return format (list of objects with fields), and notes empty array when none exist. No annotations provided, so description fully covers behavioral traits.
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?
Extremely concise: one line for purpose and a tip, followed by return format. 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.
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, the description provides complete context: purpose, usage hints, return format, and empty result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds value by specifying the return structure and usage context, but schema coverage is 100% with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all saved specs and classifies it as a cheap summary operation, distinguishing it from the sibling get_spec tool that retrieves full bodies.
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?
Explicitly specifies when to use this tool: before create_spec (for overwrite check) or generate_code. Implicitly advises against it when full body is needed, directing to get_spec.
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, the description fully discloses the read-only nature, return format (including detailed structure for two formats), and behavior when registry is empty. No contradictions.
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 exceptionally concise with four focused sentences covering purpose, prerequisite, return format, and alternative tool. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully specifies the return structure including fields and formats. Covers all necessary context: prerequisites, filtering, format options, and hints at usage. Complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds value by explaining the benefit of filtering ('keep payloads small on large token sets') and the 'format' parameter's effect, though it doesn't repeat schema details. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get design tokens from the local registry') and specifies optional filtering. It differentiates from sibling tool sync_design_tokens by noting its different purpose.
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?
Explicitly states prerequisite ('Prereq: none — local read; run pull_design_system if empty'), gives alternative for Tailwind mapping, and hints at when to use filtering. Provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: never throws, returns empty object on empty, describes output structure (partial theme with var(--token) references, 'other' tokens skipped), and explains upsert behavior and warning handling for dtcgFile.
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?
Well-structured with clear sections: purpose, prerequisite, behavior, output, and sibling comparison. Every sentence adds value without redundancy.
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?
Despite no output schema, the description thoroughly explains return values, edge cases (empty, skipping 'other' tokens), and optional return with dtcgFile. Covers all needed context for correct agent 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 covers the parameter fully. Description adds extra context: 'Upserts by token name; parse warnings are returned, never silently dropped', which goes beyond the schema description and aids agent understanding.
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: mapping registry tokens to a Tailwind theme.extend object, with optional DTCG file import. It distinguishes itself from the sibling 'get_tokens' by noting that this tool produces a paste-ready Tailwind patch.
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?
Explicitly mentions prerequisite (pull_design_system first) or alternative approach (pass dtcgFile). Also contrasts with get_tokens for inspection vs. this for ready-to-use output.
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, the description fully carries the behavioral burden. It explicitly returns the execution plan and results, explains partial failure behavior ('per-step failures do not abort the plan'), and notes error handling ('success=false with errors on failure'). This is comprehensive for an orchestrator 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 concise (five sentences) and front-loaded with the core purpose. Each sentence adds essential information: purpose, prerequisite, return format, examples, and best-practice tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step orchestrator), the description covers all essential aspects: what it does, prerequisites, return structure including error handling, and usage examples. Without an output schema, it sufficiently explains the return values. It is complete for selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds significant value: it expands on the 'intent' parameter with detailed examples and a guideline to be specific. For 'dryRun', it explains the purpose and practical use. The description enhances the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb-resource pair: 'Run the agent orchestrator on a natural-language design intent.' It explains the classicize-plan-execute cycle, distinct from sibling tools like create_spec or generate_code which are more granular. The examples further illustrate exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite ('Figma bridge only for Figma-touching intents'), provides multiple concrete examples of valid intents, and advises specificity ('name components, atomic levels, and target output'). This gives the agent clear guidance on when and how to invoke the tool.
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:

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

Score Badge

Copy to your README.md:

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

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/memi-design/memi'

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