ScientificFigureLibrary

by xuzhougeng

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation3/5
The plan/apply pairs are clearly separated, but preview and confirmation tools overlap heavily: preview, preview_exact, preview_exact_headless, preview_working_revision, and confirm_selection vs confirm_selection_headless can be confused. Descriptions clarify intended calling context, so it is not chaotic, but there is real overlap.
Naming Consistency4/5
Most tools follow a consistent figure_library_<verb>_<object> pattern, with plan_/apply_ pairs standing out clearly. A few names like source_status, github_auth_status, and review_open are noun-ish or inverted, but they are minor deviations.
Tool Count1/5
At 51 tools, the surface is extremely large for an agent to navigate. Many app-only/internal tools such as record_ui_event, confirm_selection, and preview_exact, plus duplicate plan/apply pairs, inflate the count well beyond what an agent-facing server needs.
Completeness4/5
The set covers the full figure lifecycle: search, preview, bind, working revision, review gate, publish, restore, export/import, provider sources, and GitHub PR publication. Minor gaps exist, such as no simple list/delete of published releases or direct revision retrieval, but agents can work around them.
Average 3.7/5 across 51 of 51 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 69 commits in the last 12 weeks
- Last stable release on September 1, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: readOnlyHint=true but the description says 'Create,' implying a state change. The phrase 'No files or pointers are changed' aligns with read-only, but the 'create' wording directly contradicts the annotation's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified and contradictory. It is not appropriately concise because it omits essential information and uses misleading terminology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, one of which is a nested array, and no output schema, the description should explain the purpose, parameters, and behavioral implications. It only offers a vague and misleading phrase, leaving the agent without adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about 'templateId' or 'decisions.' The tool description does not compensate at all for the lack of parameter explanations in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name indicates it updates plan review gate decisions, but the description says 'Create a read-only lifecycle plan,' which is a different verb and resource. This is vague and potentially misleading, failing to clearly state the actual action of updating decisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes many plan-related tools, but the description does not mention any exclusions, comparisons, or specific contexts.
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?
The description adds some behavioral detail beyond annotations by mentioning 'idempotency' and 'stale-state checks', which are not explicitly covered by the annotations. However, it does not explain the implications of these checks or that it is a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without redundancy or fluff. It is concise and to the point, though somewhat cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not provide sufficient context about the operation, its input/output, or its place within the broader tool family. Key details such as what a 'release' is, what 'restore' entails, or the expected output are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, and the tool description does not explain the meaning of any of the four required parameters. The parameter names are suggestive but not defining, leaving users to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply the exact cached plan' but does not specify what a 'restore release' actually does. It is not a tautology but lacks a clear, specific verb-resource combination that distinguishes it from other 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling plan/apply tools. There is no mention of scenarios, prerequisites, or 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?
Annotations already declare idempotentHint=true, and the description adds that idempotency is achieved via operation-id and that stale-state checks are performed. This provides useful context beyond the annotation but doesn't disclose error behavior or side effects on failure, so it's adequate but not 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?
The description is a single, tight sentence that front-loads the core action ('Apply the exact cached plan') and packs in key behavioral details without wasted words. Excellent conciseness.
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?
With 4 required parameters and no output schema, the description should explain what the plan does, the meaning of each parameter, and the result of applying it. It mentions only idempotency and stale-state checks, omitting the actual effect (applying a review gate decision) and any return behavior, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implicitly hints at parameter roles (operation-id idempotency, stale-state checks). It does not explicitly explain planDigest, expectedTemplateId, or expectedSeriesDigest, so the agent must infer their meaning from property names and patterns, which is insufficient for a tool with 4 required params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it applies an exact cached plan, which is a clear verb+resource, but it doesn't specifically mention 'review gate' or differentiate from the many sibling apply_* tools. It could be more specific by saying it applies a review gate update plan, but the name and context provide some clue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other apply_* siblings. It doesn't say 'use this after planning a review gate update' or mention any prerequisites/alternatives, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotency and non-destructiveness, and the description mentions idempotency and stale-state checks, but it does not clarify what side effects occur on success or failure, or what state changes are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core functionality without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain the concept of a 'cached plan', the operation-id mechanism, or how this tool fits into the broader workflow of planning and applying revisions, which is essential for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides parameter names and patterns but no descriptions, and the tool description offers no explanation of what each parameter (e.g., planDigest, operationId) means or how they should be used.
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 action (apply a cached plan) and mentions key features (operation-id idempotency and stale-state checks), but 'cached plan' is somewhat ambiguous without additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus the many sibling 'apply' tools, nor does it explain prerequisites or conditions for invocation.
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?
It explicitly states 'No files or pointers are changed,' which is a clear disclosure of its non-destructive behavior. This aligns with the readOnlyHint annotation, providing transparency about the tool's side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a single sentence to convey the core action and its key property. It is well-structured and to the point, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks sufficient context about what a lifecycle plan entails, what output to expect, or how it fits into the broader workflow. It does not explain the significance of the read-only nature or any typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, templateId, is not described in the description. Its purpose, cardinality, and expected values are unexplained, leaving the user to infer its meaning from the schema alone.
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 it creates a read-only lifecycle plan, which clearly indicates a planning action without side effects. However, it does not specify what kind of lifecycle plan (e.g., publishing a working revision) beyond the tool name, leaving some ambiguity about the specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, such as before applying changes or as a dry-run. It does not mention any alternatives or prerequisites, leaving the user without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint, idempotentHint, and destructiveHint annotations by clarifying nothing is modified. It adds the concrete detail that files and pointers remain unchanged, but beyond that it does not disclose additional behavior such as return format, plan semantics, or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence states the primary action, and the second reinforces the safety guarantee, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with strong annotations, the description is minimally adequate, but it lacks operation-specific context: it never states that this plan is about discarding a working revision, nor does it mention the apply counterpart. Since there is no output schema, some note about what the plan represents would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for templateId, and the description does not mention the parameter at all. While the parameter name is somewhat self-explanatory, the description fails to explain how templateId relates to the discard planning process, leaving a clear semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a read-only lifecycle plan,' which is a clear action, but it never mentions the specific operation 'discard working revision.' On its own, the description would not distinguish this tool from other plan_* siblings; the name and title provide the missing specificity.
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 during the planning phase by emphasizing 'read-only' and 'No files or pointers are changed,' but it gives no explicit guidance on when to use it versus apply_discard_working_revision or other plan tools. No alternatives or exclusions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the constraint that the result set must already exist and be complete, but gives no detail on cursor behavior, invalid inputs, or page contents. No contradiction found.
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-loaded with the core concept of pagination. 'App-only' is a slightly unclear qualifier, but the overall structure wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and strong annotations, but the description omits essential context: how the resultSetId is acquired (e.g., from figure_library_search), how the cursor is obtained, and what 'App-only' means. With no output schema, some return behavior should be clarified.
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 0% schema coverage, the description must compensate, but it only vaguely references the result set and pagination. It does not explicitly explain that resultSetId identifies the prior search result set or how cursor is obtained/used, relying on self-evident parameter names.
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 tool as pagination over an existing complete search result set, which distinguishes it from the sibling figure_library_search tool. However, 'App-only' is vague and not explained, so it does not fully qualify as a 5.
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 phrase 'existing complete search result set' implies the tool is for paging through results already obtained, but it does not explicitly say to use this after figure_library_search or mention any exclusions/alternatives. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive with idempotent hint. The description adds that it only applies as Working Revision, not publish, and mentions reverification, which provides context beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose. It avoids redundancy and wasted words, though it could be slightly more descriptive without losing efficiency.
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's domain (template bundle import) and the presence of many sibling tools, the description is under-specified. It lacks parameter explanations, prerequisites, and a clear connection to the planning step. It does not clarify the expected outcome or failure modes. The note about local review and publish is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description does not explain planDigest or operationId at all. The names are somewhat self-explanatory but the description adds no meaning about format, purpose, or relationship to the bundle import.
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 applies a template-bundle import as a Working Revision, with reverification. It aligns with the name and title, and distinguishes from sibling apply tools by specifying it's for template bundle imports. However, it does not explicitly mention the action 'apply' as a verb, though it's implied.
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 in a workflow by mentioning 'Reverify the exact bundle' and 'apply only the planned Working Revision', suggesting it follows planning. It also states 'Local review and publish remain mandatory,' which clarifies what does not happen. But it does not explicitly name the plan counterpart or contrast with alternatives like apply_working_revision.
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?
The description adds context not captured by the annotations: it records structured diagnostics, is App-only, and accepts only a fixed enum rather than free-form text. However, it does not disclose side effects, persistence behavior, or what happens if required identifiers are invalid, which matters for a non-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?
Two short sentences and a clear title, with no filler or duplicated schema details. The description front-loads the most important constraints: internal-only and fixed-enum diagnostics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has seven parameters, sparse annotations, and no output schema, yet the description only explains the event constraint. It omits context for required IDs, metric fields, side effects, and intended invocation scenarios, making it incomplete for an agent 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and seven parameters, the description must compensate, but it only mentions the event enum and the absence of arbitrary log text. Required parameters such as resultSetId and candidateId are left completely unexplained, and optional metrics like durationMs and payloadBytes receive no semantic guidance.
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 title and description clearly identify a recording operation: 'Record a bounded candidate-workbench event' and 'structured diagnostics.' The added restriction to a 'fixed event enum and no arbitrary log text' distinguishes it from generic logging or free-form reporting. It is somewhat domain-specific, but the purpose is comprehensible.
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 notes 'Internal App-only,' implying it should be used by the internal application rather than end users or external callers. It also implies a diagnostic/telemetry context, but it does not explicitly say when to use this tool versus any alternative or mention exclusions beyond 'no arbitrary log text.'
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe, read-only profile. The description adds the adjective 'immutable', which reinforces the non-changeable nature of the history but does not disclose additional behavioral details such as pagination, ordering, or response structure. It provides a small amount of context beyond annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It contains no fluff and is appropriately concise for a straightforward retrieval tool. However, it may be too sparse given the need to explain parameter meaning and return format, so a 4 is warranted.
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?
With one parameter, no output schema, and only minimal annotations, the description needs to provide sufficient context for the agent to confidently invoke the tool. It fails to mention what the returned history contains, how it is structured, or any ordering or limits. The description is under-specified for a tool that returns a non-trivial data set (revision and release history), leaving the agent with incomplete expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0% and the description does not mention the single parameter 'templateId'. While the name is somewhat self-explanatory, the tool fails to clarify what templateId refers to (e.g., the unique identifier of the template) or any constraints beyond the regex pattern. Since the description must compensate for low schema coverage, this is a significant gap.
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 immutable Content Revision and Release history, with a specific verb and resource. It is distinct from sibling tools like preview, diff, and planning/apply operations, as it focuses on historical retrieval rather than modification or preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus others. It neither specifies appropriate contexts (e.g., auditing changes, comparing versions) nor mentions any exclusions or alternatives. Users must infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present (readOnlyHint: false, idempotentHint: true), and the description's mention of 'operation-id idempotency' consistently reinforces the idempotentHint, while 'stale-state checks' adds some behavioral detail beyond the annotations. However, the description stays surface-level and does not disclose consequences of stale state or expected outcomes. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded 13-word sentence that is front-loaded with the core action. It is highly efficient, though perhaps slightly too terse—a few extra words about prerequisites (e.g., 'run plan_adopt_versioning first') would improve value without sacrificing concision.
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 this is a mutation tool with no output schema and no parameter descriptions, the description is under-specified. It does not explain what happens on success, what the response looks like, what triggers a stale-state failure, or how this 'apply' pairs with its plan counterpart. An agent would struggle to know the postconditions or how to handle results.
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?
With 0% schema description coverage, the description must carry the semantic weight. It partially does: 'operation-id idempotency' clarifies operationId's role, and 'stale-state checks' hints at the expected* parameters' function as concurrency guards. Yet the mapping to individual parameters is indirect and requires significant inference; it does not explicitly enumerate or clarify each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Apply the exact cached plan'), clearly indicating that this tool applies a previously created plan. However, it does not explain what 'adopt versioning' accomplishes or differentiate itself from the many other 'apply_*' siblings, leaving some ambiguity about the broader operational purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit. Phrases like 'exact cached plan' suggest a plan must be created first, and 'operation-id idempotency' implies retries are safe. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives (e.g., 'use after plan_adopt_versioning').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, lowering the bar. The description adds meaningfully beyond these: "The server never calls a model or executes code" and the returned plan being "immutable" disclose deterministic, side-effect-free behavior that the annotations do not capture. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing. The first front-loads the core action (validate intake, return an immutable plan); the second delivers the critical constraint (no model calls, no code execution). Zero redundancy with the annotations or schema, and no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 29-parameter tool with deeply nested objects and no output schema, two sentences leave significant gaps. The description omits what the returned plan contains, how the plan feeds into apply_working_revision, the create/update mode implications, and any return-value structure. The annotations cover the safety profile and the input schema is self-documenting, but the complexity here demands far more — especially with no output schema to fill in the response contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for 29 parameters. The phrase "user-confirmed image/code intake" loosely orients the agent toward the intake/visualAssets/codeAssets/confirmations parameter groups, but it adds no meaning for the bulk of parameters (validationState, figureCodeLinks, packages, license, mode semantics, etc.). Self-describing enum values carry some weight, but the description alone does not compensate for the coverage gap.
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 — "Validate user-confirmed image/code intake and return an immutable Working Revision plan" — with a clear verb, resource, and scope. The "direct-intake" qualifier in the title plus "user-confirmed image/code" in the description distinguishes it from plan tools for other workflows (adopt_versioning, bind_global, publication), though no sibling is named explicitly. It falls short of 5 because sibling differentiation is implicit rather than explicit.
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 when-to-use guidance or exclusionary statements exist. Usage must be inferred from the plan_* vs apply_* naming convention and the qualifiers "user-confirmed" and "direct-intake," which imply this is the planning phase for confirmed intake rather than an apply or alternative-planning workflow. No alternatives are named, leaving the agent to reason from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the preview is model-visible and limited to one candidate, but it does not explain exactSelector resolution, failure behavior, or whether the preview affects the library in any way. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core purpose and follow immediately with the most important invocation constraint. Every sentence earns its place, with no filler or 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?
The invocation context is well covered, but the tool has an undocumented nested exactSelector object and no output schema. An agent would likely be unsure what keys/values exactSelector requires, what providerId and resultSetId refer to, or exactly what the returned preview contains beyond being 'model-visible'.
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 0% schema description coverage and three required parameters, the description needs to compensate, but it never explains providerId, resultSetId, or how to construct the nested exactSelector object. The phrase 'one exact preview' provides only a weak hint that exactSelector identifies a single candidate.
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 resource as 'one exact preview' and makes the headless/model-visible scope clear, distinguishing it from general preview or working-revision preview tools. It lacks an explicit action verb in the description itself, though the title and 'Model-visible exact preview' make the action 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 explicitly states when to call ('only after the user selects a candidate, explicitly delegates visual review, or an App updateModelContext handoff selects one candidate') and warns against iterating through all results. It provides clear when/when-not guidance but does not name alternative preview tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds valuable context beyond these: it explicitly states 'write a new directory bundle without overwrite' (non-destructive, idempotent) and 'persist an idempotent export receipt' (recording behavior). It also mentions recovery after server restart, which is not in the annotations. No contradictions with annotations; the description enriches the behavioral model.
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, consisting of two sentences. The first sentence lists the primary actions (reverify, write, persist) in a logical order, and the second adds a relevant recovery note. It is front-loaded with the core purpose. No unnecessary words, though the sentence structure could be slightly clearer (e.g., 'A durable pre-write intent can recover...' is jargon-heavy).
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?
While the description conveys the tool's immediate actions, it lacks broader context: it does not reference the planning prerequisite (plan_bundle_export), explain what a 'portable bundle' is, or describe the overall workflow. There is no output schema, so the description is the only place to set expectations about return values, but it omits them. For a tool with many siblings, this leaves gaps in understanding the full lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: none of the three parameters (planDigest, operationId, expectedTarget) have descriptions in the schema. The description fails to compensate: it only mentions 'expectedTarget' in passing ('visible expectedTarget') and provides no explanation of planDigest or operationId, their purpose, or how they relate to the workflow. This is a significant gap for a 3-parameter tool with zero schema coverage.
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: 'Reverify the exact source inventory and visible expectedTarget, write a new directory bundle without overwrite, and persist an idempotent export receipt.' It uses a specific verb ('apply') and resource ('bundle export') and describes concrete actions, distinguishing it from sibling plan/apply pairs (e.g., plan_bundle_export). The title 'Apply a confirmed portable bundle export' further reinforces the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for applying a confirmed bundle export, but it does not explicitly state when to use it versus alternatives like plan_bundle_export or other apply_* tools. It mentions 'confirmed' and 'Reverify' but lacks explicit when/when-not guidance or a reference to the planning step. This leaves the agent to infer the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false; the description's 'No files or pointers are changed' reinforces but does not extend beyond them. It does not add details about the plan's output or persistence, though no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences convey the essential information with no wasted words. Every phrase earns its place for a simple read-only plan tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a plan/apply tool with no output schema, the description should at least mention what the plan contains or that apply_adopt_versioning executes it; it does neither. Parameter semantics are also uncovered, leaving the description incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description needed to explain templateId and canonicalImplementationAssetPath but says nothing about parameters. The schema's names and constraints are the only semantics available, leaving the agent to guess their roles.
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 'Create a read-only lifecycle plan', a specific verb and resource, and 'No files or pointers are changed' clearly separates it from the apply_* siblings. The title adds 'flat-v1 adoption' context, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only phrasing implies this is the planning stage for adopt_versioning, and the sibling list contains apply_adopt_versioning, but the description never explicitly names the apply counterpart or states when to choose this tool over alternatives. It provides no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, and idempotent behavior. The description adds useful context by stating that after this first binding, subsequent MCP starts reuse the same directory, which is a persistent side effect. It does not contradict the annotations and adds value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action front-loaded. Every clause earns its place: the first states the exact apply action, and the second explains the persistent consequence that justifies why this tool exists.
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?
With two required parameters at 0% schema coverage, no output schema, and no explicit mention of prerequisites or sibling alternatives, the description is not fully self-sufficient. An agent would need domain knowledge or external documentation to know how to produce planDigest and operationId, and where this fits relative to figure_library_plan_bind_workspace and figure_library_apply_bind_global.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain planDigest or operationId at all. The name 'planDigest' hints that it identifies the reviewed plan, and 'exact reviewed' loosely connects to it, but the agent is left without guidance on how to obtain these values or what operationId refers to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Apply the exact reviewed workspace binding plan.' It also adds the persistence consequence, 'later MCP starts reuse the same directory across projects,' which clarifies the tool's role. However, it does not explicitly contrast with the sibling apply_bind_global, so it relies on the title for the Local vs. Global differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'After this first confirmation' gives clear contextual guidance that this is a one-time post-confirmation apply, and the note that later MCP starts reuse the same directory implies this should not be repeated on every start. It does not explicitly name alternatives like figure_library_plan_bind_workspace or figure_library_apply_bind_global, but the workflow placement is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as a mutating, idempotent, non-destructive operation. The description adds useful behavior beyond those annotations by disclosing that it re-checks gh account, permissions, source, merge gate, base, and file identities, and that it never merges the PR. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core action, and the critical non-goal 'never merges' is stated explicitly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main outcome and a key boundary, but for a mutating GitHub PR operation with no output schema and zero parameter descriptions, it leaves the meaning of planDigest/operationId, failure states, and return behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description needed to explain planDigest and operationId, but it never mentions either parameter. An agent cannot learn from this description what value to pass for those two required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action (re-check, then create branch/commit/PR), specifies the resource (a reviewed staged central publication pull request), and adds an exclusion (never merges). This makes it clearly distinguishable from sibling plan and export 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 phrase 'reviewed staged' and the pre-flight re-checks imply this is the apply step after planning and review, but the description does not explicitly say when to choose it over plan_publication_pr or apply_publication_export. The 'never merges' warning is useful but not alternative routing.
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?
Going beyond the idempotentHint annotation, the description reveals operation-id scoped idempotency and stale-state validation. This tells the agent that expectedTemplateId/expectedSeriesDigest are used as optimistic concurrency guards and that retries are safe. However, it omits failure behavior (e.g., what error does a stale state return?) and the full set of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 15-word sentence starting with the imperative verb. Every phrase pulls weight: 'exact' clarifies planDigest fidelity, 'operation-id' names the idempotency key, and 'stale-state checks' flags concurrency. No filler or repetition of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating publish/commit tool with four required parameters and no output schema, many essential details are absent: what is the success/failure return shape? What if the cached plan is missing or invalid? What are the synchronization semantics with figure_library_plan_publish_working_revision? The description assumes the agent comprehends a complex distributed workflow (plan-cache-apply-publish) without adequate guardrails.
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?
With 0% schema coverage, the description carries the burden and does provide oblique references: 'exact cached plan' → planDigest, 'operation-id' → operationId, 'stale-state checks' → expectedTemplateId/expectedSeriesDigest. Yet the mapping is never made explicit, forcing the agent to infer meaning, and the concurrency tokens' checkpoint role is only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Apply' followed by a concrete object ('the exact cached plan') and qualifiers that differentiate it from siblings like figure_library_plan_publish_working_revision. The title adds 'atomic approval and publication' context. However, it doesn't explicitly state 'publish a working revision' in the description, which would make it unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a two-phase flow through 'cached plan' (planning must precede) and 'operation-id idempotency' (safe retries after a previous attempt). But it never explicitly contrasts with alternatives like figure_library_apply_working_revision or states when to use this versus the plan_* counterpart. No explicit when-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds 'host-neutral' and enumerates the inspection scope (Working, Published, history, Diff, Review findings), which provides context beyond the annotations. It aligns with the read-only nature and gives a fuller picture of what the tool covers, though it doesn't describe return format or behavior in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key qualifiers 'host-neutral' and 'read-only', and efficiently enumerates the inspection targets. There is no redundancy or unnecessary information, and every word adds value.
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?
With a simple single-optional-param tool, no output schema, and good annotations, the description is adequate but not fully complete. It conveys the scope of inspection but doesn't clarify what the result will look like or how the multifaceted information is presented. Given the many sibling tools, it might benefit from stating that it provides a combined view, but it doesn't, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the templateId parameter at all. The parameter's name is self-explanatory, but the description offers no additional meaning about how it is used, constraints, or interaction with the tool's behavior. Since coverage is zero, the description should compensate but fails to do so.
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: 'Host-neutral read-only inspection of Working, Published, history, Diff, and Review findings.' It uses a specific verb (inspect), identifies the resource (template review state), and lists the specific aspects covered. This differentiates it from siblings like template_history or diff_revisions by being a comprehensive inspection tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It simply states it is a read-only inspection without mentioning when it should be preferred over more specific sibling tools (e.g., figure_library_template_history, figure_library_diff_revisions). There is no indication of exclusions or alternatives, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool destructive and idempotent. The description adds meaningful behavior beyond that: it archives the lock unchanged and writes a receipt, which clarifies what side effects occur. It does not contradict annotations and enriches the safety profile with context about the preservation and receipt-writing actions.
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 redundancy. Every phrase adds value: 'exact unchanged abandoned lock', 'after all writers are confirmed stopped', and 'write a recovery receipt' all contribute to understanding. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and zero parameter descriptions, the description is too sparse. It omits what planDigest and operationId refer to, what the recovery receipt looks like, and any post-conditions beyond the action itself. The precondition is helpful, but the absence of parameter semantics and return details leaves the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not mention planDigest or operationId at all. The parameter names are suggestive (a digest and operation ID), but the description fails to explain their role in the recovery process. This is a clear gap in compensating for missing schema details.
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 specifies the action: archive the exact unchanged abandoned lock and write a recovery receipt, with a clear precondition that all writers are stopped. This distinguishes it from the sibling plan tool (plan_recover_write_lock) by describing the execution step, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear context for use ('after all writers are confirmed stopped') which implies when to invoke it, but it does not explicitly mention alternatives, exclusions, or the relationship to the plan counterpart. The guidance is present but implicit; no direct 'when not to use' or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a valuable non-obvious behavioral guarantee—'SFL never reads or prints the token'—which is security-relevant context an agent needs before invoking an auth-related tool. This goes meaningfully beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the first front-loads the core purpose, and the second delivers the critical security guarantee. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter, read-only status check with rich annotations, the description covers what is checked and the sensitive-token behavior. The only omission is a description of the return value format, but no output schema exists and this is a minor gap for a status probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to document about inputs; the rubric baseline of 4 for 0-param tools applies. The description instead clarifies what is being checked, which is the relevant semantic content for a parameterless status probe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') with a specific resource ('official gh login and central repository permissions'), making the tool's function immediately clear. It inherently distinguishes itself from the sibling figure_library_github_auth_instructions by being a status check rather than instructional content. However, it does not explicitly name sibling alternatives, so some differentiation is left to inference.
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 is given for when to use this tool versus alternatives. Related siblings such as figure_library_source_status and figure_library_github_auth_instructions exist, and the description does not clarify when auth-status is the right choice over them. Usage context is only weakly implied by the 'read-only check' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context that restore preserves libraryId and requires explicit authority transfer, while fork creates a new libraryId with fork provenance. This goes beyond the annotations, though it doesn't detail what verification entails.
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 that front-load the main action and then explain the modes. No wasted words, appropriate structure.
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 plan tool with no output schema, the description doesn't clarify what the plan returns or that it doesn't execute the operation, which is important given the apply sibling. The mode differentiation is helpful, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'mode' parameter (restore vs fork), implies 'authorityTransferConfirmed' via 'requires explicit authority transfer', and relates 'bundleDirectory' to 'backup directory'. However, 'targetDirectory' is not elaborated, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verify') and resource ('full backup directory'), and clearly distinguishes the two modes (restore vs fork) by their outcomes. However, it doesn't explicitly mention that this is a planning step as opposed to the apply tools, so it slightly lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to choose restore vs fork based on libraryId preservation and authority transfer, but does not explicitly state when to use this tool versus the apply_full_restore sibling or other plan tools, nor any 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?
The description adds significant context beyond annotations: it mentions the optional copy-to-directory side effect, which aligns with readOnlyHint=false, and clarifies it does not authorize materialization. This is useful context not derivable from the annotations, though it does not detail overwrite behavior 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 two sentences with no filler. It front-loads the primary function and then adds the critical compatibility caveat, earning its place with every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is missing essential usage details: there is no output schema to explain the returned image content beyond the phrase 'standard MCP image content', and exactSelector is unexplained. It also does not differentiate this tool from the similar preview_exact and preview_exact_headless siblings, making it insufficient for an agent to confidently select this tool.
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 0% schema description coverage, the description should compensate but barely does. It hints that destination must be a 'trusted absolute directory' but provides no guidance on providerId or exactSelector, which are required and structurally complex.
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 selected preview as standard MCP image content and optionally copies it to a directory. It also distinguishes itself from siblings by declaring it is a compatibility tool that does not authorize materialization, which is a key differentiator from plan/apply materialization 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 previewing without materialization authorization, but does not explicitly name alternative tools like preview_exact or preview_exact_headless. The 'compatibility tool' phrase hints at legacy use but no clear when-to-use instructions are given.
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?
Adds context beyond annotations: app-only scope, returns image bytes only to the component, and issues session-bound confirmation challenge. Read-only hint already covers safety, so description enriches the behavioral model without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core scope. No filler words; every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no param descriptions, the description does not clarify the confirmation challenge workflow or the exactSelector object structure. It covers return behavior but leaves operational details ambiguous.
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 coverage is 0%, yet description does not explain providerId, resultSetId, or exactSelector structure. The word 'exact' loosely maps to exactSelector but no concrete syntax or semantics 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?
Clearly states it is an app-only exact preview that returns image bytes and issues a session-bound confirmation challenge. Distinguishes from headless preview and confirmation tools by emphasizing app-only and confirmation challenge.
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?
Implies usage context through 'App-only' and 'session-bound confirmation challenge' but does not explicitly name alternatives or state when-not-to-use. No explicit exclusion of headless variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read-only operation. The description adds the behavioral context that it is an app-only confirmation occurring after specific user actions, which goes beyond the annotations. It does not contradict the annotations, and it provides additional context about the tool's operation within the workbench flow.
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, consisting of two short sentences. The first sentence establishes the tool's scope ('App-only confirmation'), and the second adds the precise invocation conditions. Every word earns its place, with no unnecessary filler or duplication of schema details.
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 provides adequate context for when the tool is called, but it fails to explain the meaning of the only parameter, which is critical for proper invocation. Since there is no output schema, the user cannot infer the return value. For a simple confirmation tool with a single opaque token, the description is minimally adequate but leaves the agent guessing about the parameter's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'previewChallenge' has zero schema description coverage, and the tool description provides no explanation of its meaning, format, or purpose. The parameter appears to be an opaque challenge token, but the agent is left with no guidance on what to pass. This is a critical gap for a required string parameter, and the description does nothing to compensate.
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 it is an app-only confirmation step, which distinguishes it from the headless variant. It specifies the conditions (after exact image load event and explicit user click) that define its purpose. However, it does not explicitly identify the resource being confirmed (e.g., 'the selected preview'), so it's slightly less precise than the calibration example.
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 states when to call this tool: 'only after the exact image load event and an explicit user click.' It also states 'App-only' which implicitly distinguishes it from the headless sibling (figure_library_confirm_selection_headless). This provides strong usage guidance, including a precondition for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so a planning-only behavior is well covered. The description adds useful behavioral nuance by stating that Catalog mode re-verifies the commit and ZIP after a manual merge, which informs the agent about validation behavior beyond the annotation layer.
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 with no filler, and the core distinction between Archive and Catalog is front-loaded. The abbreviation 'PR' might be slightly cryptic for an agent, and the sentence could be clearer about the workflow, but overall it is compact and readable.
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 planning tool with strong annotations (read-only, idempotent, non-destructive) and no output schema, the description conveys the primary workflow difference between the two modes. However, it lacks information about which parameters are expected in each mode (e.g., archivePullRequestNumber is needed for catalog but likely not for archive), and it doesn't tell the agent what the plan output looks like or how to act on the plan. This is adequate but has clear gaps for a tool with five undocumented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are five parameters, so the description carries the burden for clarifying them; however, it only explains the semantic split of the 'action' parameter (archive vs catalog) and does not add meaning to expectedTemplateId, submissionDirectory, expectedReleaseVersion, or archivePullRequestNumber. The baseline is 3 per the rubric, and the description adds no parameter semantics beyond the action enum, so a 3 is the ceiling here.
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 tool as a planning step for a central publication pull request with two distinct modes (Archive and Catalog), which differentiates it from the apply counterpart and other plan tools. It names the resource ('PR Plan') and the action ('Plan a staged central publication pull request'), though the phrasing 'Read-only Archive or Catalog PR Plan' is terse and omits a fuller explanation of the staging workflow that the title implies.
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 tells the agent when each action value is appropriate: choose 'archive' for a single sanitized submission, or 'catalog' when a manually merged Archive PR exists and the tool must re-verify the fixed merge commit and ZIP. It does not explicitly say 'use this instead of apply_publication_pr' or list exclusions, but the read-only annotation and the plan/apply sibling pattern make the usage context reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds specificity with 'No files or pointers are changed', which goes beyond the annotations' readOnlyHint by clarifying the exact impact. This is useful context for the agent, though it doesn't cover all behavioral aspects like idempotency.
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 no redundancy. The purpose and safety guarantee are front-loaded, making it easy to parse.
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 planning tool, the description covers the core purpose and safety, but does not explain what the plan entails or how it relates to the apply counterpart. Given no output schema, the agent might wonder about return values or next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention parameters. Neither releaseId nor templateId are explained beyond their names. With low schema coverage, the description should compensate but does not.
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 verb 'Create' with resource 'read-only lifecycle plan' is specific. The read-only aspect clearly distinguishes it from apply tools like figure_library_apply_restore_release.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a planning step (read-only, no changes), implying it should be used before applying. However, it does not explicitly name alternatives or give when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it does not create a preview receipt or authorize materialization, which is useful behavioral context beyond the annotations. It also clarifies the output is the canonical image, but does not mention error conditions or auth requirements.
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 only two sentences, front-loaded with the primary action and immediately clarifies side effects. Every sentence adds value without redundant information, achieving ideal 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 three required parameters, no output schema, and no param explanation, the description is incomplete. It covers purpose and side-effect disclaimer, but omits parameter semantics, alternative tool guidance, and any error/edge-case behavior. For a tool of moderate complexity with no output schema, it should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three required parameters (revisionId, templateId, contentDigest) or their roles. With three required parameters and no explanation, the description fails to compensate for the lack of schema descriptions, leaving agents unsure how to select valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the canonical image for an exact active pending Working plan or current Working Head, specifying the verb and resource. It distinguishes from siblings by focusing on working revisions and explicitly noting it does not create a preview receipt or authorize materialization, which aligns with its read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (use for exact active working revisions) and implies it is for read-only previews without side effects. However, it does not explicitly name alternatives or when-not conditions, such as comparing to figure_library_preview_exact or other preview variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds critical behavioral context: all failures are terminal and must not be retried with variations. This goes beyond the annotations and clarifies failure 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?
The description is two concise sentences, front-loaded with the core action and then adding the critical failure caveat. Every word earns its place with no fluff or 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 the tool has 4 required parameters, no output schema, and no parameter descriptions, the description is insufficiently complete. It lacks details about prerequisites, what 'expected' means, what happens on success, and why failures are terminal. A more complete description would explain the materialization flow and parameter roles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides almost no parameter-level detail. It implies planDigest refers to a cached plan, but does not explain operationId, expectedProviderId, or expectedTarget, leaving the agent without sufficient semantic grounding for these fields.
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 action: 'Apply the cached exact plan once.' It uses a specific verb ('Apply') and resource ('cached exact plan'), and distinguishes itself from sibling planning tools (plan_materialize) and other apply variants by emphasizing 'exact' and 'confirmed.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: this is for applying a cached, confirmed exact plan, and it explicitly warns not to retry failures with any alternative mode, provider, downloader, or template. While it doesn't name sibling alternatives directly, the exclusion guidance effectively tells the agent when not to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and readOnlyHint=false. The description adds beyond that by disclosing 'Reverify source bytes' and 'stale-state checks', which describe preconditions and safety behaviors not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one compact sentence that packs the core behavior without filler. The title is also concise and aligned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 required params and no output schema. The description covers reverification, idempotency, and stale-state checks, but omits details on stale-state error triggers, the role of expectedAction enum, and return/error 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?
The schema has 5 required parameters with 0% coverage (no descriptions). The description adds semantics by linking 'operation-id' to idempotency, 'cached plan' to planDigest, and 'stale-state checks' to expected fields, but it does not explain each parameter's exact purpose or interaction.
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 specific verb ('apply') and resource ('exact cached plan' for working revision), and distinguishes itself from siblings by mentioning 'reverify source bytes' and 'stale-state checks', which are unique to this apply operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the apply step for a confirmed plan ('apply the exact cached plan'), but it does not explicitly name alternatives or state when to use it over other apply_* tools such as apply_publish_working_revision. Usage context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and non-destructive; the description adds useful context by noting this is a headless/model-visible confirmation and explicitly warning but it cannot prove UI visibility. There is no contradiction: the readOnlyHint is consistent with 'confirmation' acting as a non-mutating signal rather than a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The title states the exact action and the description front-loads the purpose in the first sentence, then adds preconditions and the caveat in the second sentence. There is no redundant repetition of annotation or schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-argument headless confirmation tool, the description covers the important workflow and limitation, but it does not describe what happens after the confirmation is sent, whether the call returns a result, or how the challenge should be selected beyond implication. It is adequate but has meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter previewChallenge has no schema description and the tool description does not explicitly explain how to obtain or form it. The references to the previous headless preview tool imply the challenge comes from that call, which provides some context, but the description still leaves too much up to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence makes it clear that this tool confirms a preview produced by figure_library_preview_exact_headless, and the title adds that it is an exact assessment confirmation. It is not a tautology, but it could be more explicit about what the confirmation accomplishes or persists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong preconditions: use only after a user selection, explicit delegation, or an App updateModelContext handoff when serverTools is unavailable. The caveat that this call cannot prove UI visibility also helps the agent know it should not treat this as a reliable UI-visible confirmation, though it does not explicitly name the non-headless alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no positive safety hints (all false), so the description carries the burden. It adds meaningful behavioral context: 'never uploads data', 'excludes user text and absolute paths', and 'Defaults to sanitized_bundle'. It does not contradict annotations, though it could further clarify that includeUserText/includeAbsolutePaths can override the exclusions.
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 dense sentence with no filler. Every clause adds value: bounded, secret-safe, diagnostic ZIP, current session, sanitized_bundle default, exclusions, and no uploads. It is front-loaded and appropriately sized for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no helpful annotations, the description is too brief to be fully actionable. It does not explain how to use time_range/correlation_id scopes, what 'bounded' means, what full_local includes, or how the ZIP is returned. The safety guarantees are useful but the operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 7 parameters. It only addresses detail (via 'sanitized_bundle'), includeUserText/includeAbsolutePaths (via 'excludes user text and absolute paths'), and scope (via 'current server session'). It leaves scope enum values, since/until, and correlationId unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('diagnostic ZIP') with clear scope ('for the current server session'). It distinguishes itself from sibling bundle-export tools by emphasizing 'diagnostics' and 'secret-safe', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when this tool is appropriate: exporting a bounded, secret-safe diagnostic ZIP for the current session. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can infer this is the diagnostic-export tool rather than the bundle-export or planning 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?
Beyond the readOnlyHint annotation, the description adds the important behavioral detail that network access occurs only when the requested action must verify a snapshot, and that planning never writes configuration or snapshots. This is meaningful extra disclosure, though it does not detail what happens if the network is unavailable or how snapshot verification is triggered.
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 long and front-loads the core purpose and action set. Every sentence adds behavioral or scoping information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has eight parameters and no output schema, so the description should carry more of the burden for explaining what a 'plan' produces or returns. It adequately covers scope, side effects, and network behavior, but it does not describe the plan output, possible validation failures, or the expected next step after planning.
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 high at 75%, so much of the parameter meaning is already captured in the schema. The description adds value by enumerating the actions and highlighting the trust-reset semantics, but it does not further clarify the relationships between parameters like providerId, manifestUrl, and expectedProviderId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Plan') and resource ('signed personal provider'), then enumerates the full set of supported actions: Add, Update, Configure, Remove, and Trust Reset. It also distinguishes itself from the apply sibling by explicitly stating that planning never writes configuration or snapshots.
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 when to use this tool ('Planning never writes configuration or snapshots'), which suggests a preview-before-apply workflow. However, it never explicitly names an alternative such as apply_provider_source_change or states when to use this tool instead of that one.
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?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavior: it resolves exactly one reachable release, and it surfaces included/excluded assets, rights declarations, public metadata conflicts, render traces, and the target. This gives the agent useful expectations for selection strictness and output content.
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, dense sentence with no filler. It front-loads the core action and resource, then lists the key outputs, ending with the critical no-write guarantee. Every phrase adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with eight parameters, nested objects, seven required fields, and no output schema, the description is too brief. It does not explain how to construct the required inputs, what 'exact reachable' means operationally, how metadata conflicts are resolved, or what the return payload will look like beyond a high-level list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of the eight parameters. While parameter names are somewhat self-explanatory, the description only mentions 'target' in passing and does not compensate for the low schema coverage or clarify complex parameters like exactSelector, assetDeclarations, rightsAttestation, or publicMetadata.
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 and resource: it resolves one exact reachable Local Published Release and shows all included/excluded assets, rights declarations, metadata conflicts, render traces, and target. This clearly distinguishes the planning view from sibling tools like apply_publication_export by explicitly noting it writes no files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without writing files' makes it clear this is the planning/preview step, which distinguishes it from apply_publication_export and similar mutation tools. It provides clear context but does not explicitly name alternative tools or state when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds 'operation-id idempotency' and 'stale-plan checks', explaining the idempotency mechanism and safety check. It doesn't contradict the idempotentHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with action, no filler.
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 immediate action but lacks context on prerequisites (e.g., need for a reviewed plan from plan_bind_global) and what a successful application returns. Given the plan/apply pair and lack of output schema, it's adequate but not fully complete.
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 has 0% coverage. Description explains operationId's role via 'operation-id idempotency' but doesn't explain planDigest's meaning or how to obtain it. The pattern for planDigest (SHA-64 hex) is visible but no semantic clue.
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: 'Apply the exact reviewed binding plan' with 'binding' naming it as the global library binding. It distinguishes from siblings like plan_bind_global and other apply_* tools by specifying 'binding plan' and idempotency details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage after a review and planning step, and the idempotency/stale-plan checks give invocation context. However, it doesn't explicitly name alternatives or when not to use, but the siblings and name make the plan/apply pattern clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a destructive, non-read-only, idempotent operation; the description adds meaningful context by disclosing stale-state validation, replay protection, and the rejection of direct key/endpoint overrides. No contradiction with the annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the core operation front-loaded and the key input restriction immediately after. Every clause adds information and there is no filler.
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 plan, stale-state checks, replay protection, and input restrictions, which is solid for a destructive apply operation. It lacks explicit guidance on how to obtain/provide planDigest and operationId, what expectedAction should match, and what the caller should expect back, so it is not fully complete for a 4-required-parameter tool with no output schema.
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 low (25%), so the prose needed to define the four required parameters, but it only indirectly maps 'plan' and 'operation-id' to planDigest/operationId. expectedAction and expectedProviderId are left to the schema, and expectedProviderId alone has a schema description, leaving the agent under-informed about the required values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Apply'), a specific resource ('exact cached provider-source plan'), and key constraints (stale-state checks, operation-id replay protection). This clearly distinguishes it from the plan_provider_source_change sibling and from other 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?
The phrase 'exact cached provider-source plan' clearly implies this is the commit step after a plan exists, and 'never accepts a raw public key or endpoint override' tells the agent to use it only for pre-confirmed signed changes. It does not explicitly name the planner tool or say when to use an alternative, so it stops short of a full when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate those. It does add the behavioral constraint that a bare templateId is deliberately insufficient, but it doesn't describe errors, output shape, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core constraint ('bare templateId is deliberately insufficient') is front-loaded and directly actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only describe operation, the description covers the key selection constraint and template categories. The main omission is the exactSelector object schema, but the tool has no output schema and the annotation suite already covers the operational safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It partially compensates by explaining that providerId plus an exactSelector are required and by listing what kinds of exact selectors are valid. However, the internal structure of exactSelector is left unspecified, which is a meaningful gap.
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 tool describes an exact provider-qualified template, and enumerates the accepted template categories: Local Published release, bundled/personal public template, or commit-pinned FigureYa module. This differentiates it from generic open/search tools by emphasizing exactness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: only exact, provider-qualified selectors are acceptable, and a bare templateId is explicitly insufficient. It doesn't name sibling alternatives, but it effectively rules out the wrong way to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint. The description adds meaningful context about excluding rebuildable indexes/runtime locks and requiring an 'exact reachable Published Release', which enhances understanding beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the core function and a critical behavior (writes nothing) with no wasted words. Information is front-loaded and efficient.
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 purpose and safety profile are clear, but the description omits any parameter semantics and the nature of the produced plan (e.g., format, content). Given the tool complexity (5 parameters, 2 required) and no output schema, this is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters (kind, releaseId, targetName, templateId, destination). It gives a high-level overview but fails to compensate for the lack of schema details, leaving the agent without guidance on how to fill required fields.
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 inventories a library or published release and produces a directory-bundle plan, explicitly noting it writes nothing. This distinguishes it from apply_bundle_export and other plan/apply sibling pairs.
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 this is the planning step for bundle export, but it does not explicitly mention when to use it versus other planning tools or when not to use alternatives. The context of sibling plan/apply pairs makes the usage clear, but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the one-time receipt requirement and the destination-checking behavior, providing context beyond the structured fields. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the essential workflow and key constraint, so it is concise. However, it is somewhat dense and starts with a prerequisite action ('require') rather than the primary operation, making it slightly less immediately parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (plan vs apply, receipt flow, exact selector, no output schema), and the description does not explain return values, what 'check the destination' entails, or the relationship with confirm_selection tools. The sibling list provides context, but the description alone leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover only exactSelector and previewReceipt (33%). The description reinforces these two parameter roles ('provider-qualified selector' and 'one-time confirmed exact preview receipt') but does not explain providerId, destination, allowNetwork, or sourcePackDir. Given the low schema coverage, some compensation exists but remains incomplete.
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 a planning/materialization check operation: it requires a preview receipt, resolves a provider-qualified selector, and checks the destination without writing files. This distinguishes it from the sibling apply_materialize by explicitly stating 'without writing files.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: after obtaining a confirmed preview receipt and before actual materialization, since it does not write files. It doesn't name the apply counterpart explicitly, but the sibling list includes figure_library_apply_materialize, and the phrase 'without writing files' signals this is the planning alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful context about verifying exactness, handling immutable assets, and not inheriting source approval. It does not contradict the annotations, and it goes beyond what the annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action sequence, no filler. The second sentence adds a critical non-inheritance rule. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a planning tool: it states the purpose and key rule. But with no output schema and no parameter explanations, the agent must infer mode semantics and expected result behavior. It could be more complete about what the plan contains or how it differs from apply_template_bundle_import.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for explaining parameters. It implies 'Published-template bundle' maps to bundleDirectory and 'Working Revision' relates to mode, but it does not explain the three parameters explicitly, especially the mode enum values (create, update_published, update_working) or the roles of targetTemplateId. This is a significant gap for a 3-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific action verbs ('Verify', 'copy', 'plan') and clearly identifies the resource ('Published-template bundle') and the deliverable ('Working Revision'). It distinguishes this planning tool from the paired apply tool and other plan siblings by stating it plans an import, not applying it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for verifying an exact Published-template bundle and planning a Working Revision, not for applying changes. The rule 'Source approval is provenance only and is never inherited' is an important usage constraint. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds useful behavioral context by enumerating the exact domains inspected and by flagging the intentional absence of capture/project-pin status, preventing false expectations. It does not describe output shape in detail, but for a read-only status tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the primary action and scope, followed by a deliberate exclusion. Every clause carries useful information and there is no redundancy or filler.
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 read-only status tool, the description covers the main scope well and annotations cover safety. However, there is no output schema, and the description only vaguely promises 'complete text and structured status' without detailing the structured shape. The missing parameter semantics also leave a modest gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, sourcePackDir, is not mentioned in the description, and the schema provides no description for it either (0% coverage). The word 'global' weakly suggests the tool can be called without parameters, but the agent has no real guidance on what sourcePackDir means or how it scopes the status output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Return') and a precise resource: the global portable Library's status, immutable lifecycle, write lock, and every registered Provider. It also explicitly states what is excluded (capture/project-pin status), which helps distinguish it from sibling tools like figure_library_list_provider_sources or figure_library_describe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when global Library and Provider status is needed. It also states an exclusion ('Capture/project-pin status is intentionally absent'), but it does not name an alternative tool for that excluded use case, so the guidance stops short of being fully explicit.
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?
Annotations already indicate this is not read-only, is idempotent, and is not destructive. The description adds valuable behavioral specifics: it verifies every byte (integrity check), writes an immutable receipt (side effect), and never changes the active locator automatically (a non-obvious nuance). These details go beyond the structured annotations and clarify the tool's side effects and constraints, aligning with the idempotent and non-read-only hints without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, followed by a critical behavioral caveat. Every phrase adds value—'absent target', 'verify every byte', 'immutable operation receipt', and the locator behavior—with no redundant or filler content. It is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the main behavior and side effects well. However, it does not mention that this is an 'apply' step requiring a prior confirmed plan (though implied by the name and sibling plan_full_restore), nor does it explain the parameters or potential error conditions. The absence of explicit prerequisites or invocation context makes it slightly incomplete for an agent that might not infer the plan/apply workflow from the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (planDigest, operationId) but zero description coverage. The tool description does not mention these parameters at all, leaving the agent without guidance on what values to provide or how they relate to the restore/fork operation. Since the schema provides no descriptions and the tool description offers no compensation, parameter semantics are severely lacking.
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 ('Restore/fork'), specifies the target condition ('into an absent target'), and lists concrete steps ('verify every byte, write an immutable operation receipt'). It also distinguishes this apply tool from siblings by noting the locator behavior and the absence of automatic changes. This goes beyond the title to provide a precise verb+resource+scope definition.
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: it is the apply step for a full restore/fork into an absent target, and it notes a key behavioral constraint (never changes active locator automatically). However, it does not explicitly state when to use this tool versus alternatives, such as 'use after plan_full_restore' or 'do not use if target already exists'. The 'absent target' and 'confirmed' in the title hint at prerequisites, but the description lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it never uses the network, never signs content, never creates a PR, is atomic, and produces a deterministic submission. These are non-obvious side-effect disclosures that help an agent understand the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action is front-loaded, and the important exclusions are stated compactly in the second sentence.
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?
With no output schema and no parameter descriptions, the tool needs richer context. The description omits the meaning of planDigest and operationId, the expected format of expectedTarget, prerequisites such as a prior plan/confirmation step, and what the return value indicates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain planDigest, operationId, and expectedTarget. It only loosely implies 'new target' for expectedTarget and mentions revalidating Local Published Release and asset bytes, but never maps these concepts to the actual 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 states a specific operation: revalidate the exact Local Published Release and selected asset bytes, then atomically create one deterministic sanitized submission at a new target. It also explicitly distinguishes this from PR creation, which is a key sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The title and description indicate this is the apply stage for a confirmed sanitized publication export, and the 'never creates a PR' clause signals when not to choose this tool. However, it does not explicitly name alternative tools or state a clear when-to-use versus when-not-to-use rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail by specifying that the comparison covers complete revision fields and asset inventories, reinforcing the non-mutating scope beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and clearly states the non-destructive behavior. Every word adds value, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple three-parameter interface and strong annotations, the description is largely complete for selecting and invoking the tool. It could be slightly more complete by noting the shape of the comparison result or explicitly contrasting with template_history, but the core use case is sufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-specific meaning. The parameter names templateId, fromRevisionId, and toRevisionId are fairly self-explanatory, but the description does not compensate for the missing schema descriptions or clarify expected formats or relationships between 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 a specific operation: compare complete revision fields and asset inventories between two revisions. It distinguishes itself from sibling tools by explicitly calling out that it does not modify either revision, making its read-only comparison role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for read-only comparison of revisions, which helps an agent select it over planning/apply or preview tools. It does not explicitly name alternatives or state when not to use it, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations: it states read-only while annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. It adds useful behavioral context beyond annotations by explaining the tool will ask the user for input before searching and that it opens a candidate, not a review, workbench.
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 crisp sentences communicate the resource, the mode, and the expected user interaction. No filler or repetition; the key message is front-loaded in the first sentence.
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 no-parameter, read-only opening tool, this description covers the core action and the immediate next step. It lacks explicit information about return values or what the workbench state offers, but given no output schema and zero parameters, the description is sufficient for this simple tool within a large sibling family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline is high. The description adds no parameter specifics because none exist; it effectively communicates that the tool operates on conversational context rather than structured inputs.
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 opens the "read-only candidate workbench" and frames its role as an entry point before searching. It is specific about the resource and action, and the "candidate" wording helps distinguish it from sibling review/open tools, though not explicitly named.
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?
'Before searching' gives clear sequencing guidance, and the tool instructs the user to ask for an uploaded reference, data profile, or plotting goal. It does not explicitly exclude alternative open tools such as review_open, but the candidate-workbench context provides strong situational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds value by disclosing the non-destructive flat-v1 copy in migration staging and the implicit project-directory guard. Reinforces rather than contradicts the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary validation action and directly followed by the key non-destructive caveat. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a planning tool paired with figure_library_apply_bind_global and backed by rich annotations, the description covers validation, staging behavior, and scope constraints. It doesn't describe the plan's output shape, but the plan/apply convention and sibling naming make the contract clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover libraryDirectory and legacySourceDirectory (67% coverage), and the description adds 'flat-v1' and 'migration staging' terminology that aids interpretation. However, migrationMode remains undocumented in both the schema and description, and the description provides no parameter-level semantics beyond that.
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?
Uses specific verbs 'Validate' and 'stage' tied to the resource (global Library directory), and scopes itself as a read-only plan for binding a global Library. The phrase 'never chooses a project directory implicitly' differentiates it from sibling tools that might target project directories.
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?
Clearly describes when the plan runs: validating the user-selected global directory and optionally staging a copy. The 'never chooses a project directory implicitly' gives a when-not-to-use signal, though no alternative tools are named explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds crucial context that the tool is not automatic: 'locks are never auto-stolen' and that the user must stop other writers. This goes beyond the annotations by clarifying the required user intervention and the non-automatic nature of recovery, adding value to the behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose. The first sentence states what the tool does, and the second adds the essential safety precondition. There is no fluff or repetition; every word earns its place. It is concise and well-structured for quick parsing.
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 role in a planning workflow, the description does not explain what the tool returns or what a 'plan' entails. It mentions inspecting the lock and requiring user action, but not the output or how the result feeds into the recovery process. With no output schema, the agent is left without expectations about the return value. This is a notable omission, though the safety guidance is solid. The description is not fully complete for a tool that likely returns a plan or status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'reason' (string, 1-2000 chars) with 0% schema description coverage. The description does not mention this parameter at all, leaving the agent to infer its purpose. While 'reason' is intuitively a justification for the recovery plan, the description provides no guidance on what to enter or how it will be used, forcing reliance on naming. This is a significant gap for a required parameter.
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 'Inspect one exact Library write lock,' clearly stating the action (inspect) and resource (write lock). It also distinguishes itself from the sibling apply tool by focusing on planning and requiring user action before recovery. The verb 'Inspect' plus the specific resource and mention of recovery make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a precondition: 'The user must stop every Wisp, Codex, Claude, and other writer before approving recovery.' It also provides a behavioral rule: 'locks are never auto-stolen,' which guides the agent on when to use this planning tool versus the apply counterpart. This is clear, actionable guidance on how and when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important behavioral context: it opens the candidate App and then stops to wait for user choice, which is a side effect beyond typical read-only search. It also explicitly states exclusions (Working, Capture, flat-v1 entries), which is valuable filtering behavior. The description does not disclose all ranking details, but it discloses the key interactive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence delivers the core behavior with specificity, and the second sentence adds the exclusion filter. Every word earns its place, and the key action (search, open, wait) is 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?
The tool has 10 parameters but only 1 required; the description gives the high-level workflow (search, open, wait). There is no output schema, so return values are not documented, but the description states it opens a candidate App and waits, which implies the result is user-selected. Ranking details and exact response format are not described, but for an interactive search tool with read-only annotations and clear exclusions, the description is reasonably complete. A 4 because it goes beyond annotations to state the open-and-wait behavior and exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description focuses on the overall behavior (search, open, wait) and does not explain individual parameters like query, limit, language, assetKind, codeStatus, etc. The parameter names themselves are somewhat self-explanatory, and enums provide guidance, but the description adds no semantic meaning about how filters interact with the Provider match set. Baseline 3 is appropriate; it doesn't go beyond the schema for 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 performs a search across multiple Provider sources, returns a ranked match set, opens the candidate App, and stops for user choice. It distinguishes itself from sibling tools like figure_library_search_page by mentioning it opens the app and waits, while listing exclusions. This is specific verb+resource+behavior, and the resource (Provider match set) is clearly defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when a complete search across all Providers is needed before opening the candidate. It explicitly states Working, Capture, and flat-v1 entries remain excluded, giving exclusion context. It does not explicitly name an alternative tool for when one wants only search results without opening the app, but the sibling list contains figure_library_search_page which likely serves that purpose. The context is clear but not fully explicit about 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?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds a meaningful non-obvious behavioral trait: it never launches a browser or login process. This goes beyond the annotations by informing the agent that the tool has no interactive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words, and the key behavioral constraint ('never launches a browser or login process') is front-loaded in the second sentence. 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?
For a zero-parameter tool with annotations covering its safety profile, the description is complete: it tells the agent what the tool returns and what it does not do. No output schema exists, but the tool's simple nature means no further detail is required.
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 schema description coverage is 100%, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description appropriately avoids irrelevant parameter detail.
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 and resource: 'Return a terminal command for the user to run,' and the title/tool name clarify it concerns official GitHub CLI authentication instructions. This clearly distinguishes it from sibling tools like figure_library_github_auth_status, which checks authentication status rather than providing instructions.
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 its use case—when a terminal command for authentication instructions is needed—and notes it never launches a browser or login process, which hints at when not to use it. However, it does not explicitly name alternatives or state conditions for choosing this tool over sibling tools, so usage guidance remains implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint, and destructiveHint already annotated, the description adds non-obvious behavior: this validation happens only on first-time machine confirmation, later starts reuse the saved locator, and the tool never infers the current project folder. This advances an agent's understanding beyond the annotated safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, all informative: purpose, lifecycle constraint, and an explicit non-behavior. No redundant filler; the most important verb-resource statement is front-loaded.
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 single-parameter validation tool with rich annotations and no output schema, the description covers purpose, when it may be invoked, the no-inference constraint, and the meaning of the parameter. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents workspaceDirectory as an absolute native path, so the baseline is 3. The description adds meaningful context by requiring the value to be user-selected and warning that the tool never infers the current project folder, clarifying why the parameter must be explicitly supplied.
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 specific verb ('Validate') and a specific resource ('user-selected Local workspace directory'), clearly identifying the tool's job. The 'Local workspace' wording and 'Validate' action distinguish it from sibling plan/apply and global variants without needing to inspect them.
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 restricts use to first-time machine confirmation ('First-time machine confirmation only') and rules out later starts by noting they reuse the saved locator. It does not name an alternative tool such as apply_bind_workspace or plan_bind_global, so it falls short of full alternative 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds valuable behavior beyond them: it guarantees no network request is made and explicitly states that the raw trusted public key is never exposed. This is useful security-relevant context that cannot be inferred from annotations alone.
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, each earning its place. The primary function is stated first, followed by the two most important behavioral boundaries. There is no redundant or filler content.
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 zero-parameter read-only tool, the description is complete: it states what is read, that no network request occurs, that snapshot identities are included, and that sensitive key material is not returned. Even without an output schema, an agent has enough to invoke the tool correctly and interpret the result.
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 and the schema coverage is effectively 100%, so there is no parameter meaning left undocumented. A baseline of 4 is appropriate because the description has nothing to add, and nothing is missing.
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 a specific verb ('Read'), a specific resource ('configured personal provider sources'), and the key output ('last-known-good snapshot identities'). It distinguishes itself from other figure_library tools by explicitly noting the operation makes no network request and never returns the raw trusted public key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: to inspect the current offline snapshot of personal provider sources without network activity. It does not explicitly name alternative tools or state when not to use it, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ScientificFigureLibrary MCP server](https://glama.ai/mcp/servers/xuzhougeng/ScientificFigureLibrary/badges/card.svg)](https://glama.ai/mcp/servers/xuzhougeng/ScientificFigureLibrary)

Score Badge

Copy to your README.md:

[![ScientificFigureLibrary MCP server](https://glama.ai/mcp/servers/xuzhougeng/ScientificFigureLibrary/badges/score.svg)](https://glama.ai/mcp/servers/xuzhougeng/ScientificFigureLibrary)

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/xuzhougeng/ScientificFigureLibrary'

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