EAD Factory MCP Server

Official

by g-digital-by-Garrigues

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.3.1
Disambiguation2/5
Many tools overlap functionally: evidence_group_evidence_register vs generate_evidence, evidence_download_url_create vs evidence_group_evidence_download_url_create, and several delete variants. Even with detailed descriptions, the presence of legacy and composite alternatives creates real confusion about which tool to invoke.
Naming Consistency3/5
Naming mixes verb-first (generate_evidence, create_signature_request), noun-first (evidence_group_create, notification_request_create), and inconsistent suffix patterns like _full, _status_update, and _url_get. It's not chaotic, but the conventions are not uniform across domains.
Tool Count2/5
With 64 tools, the server is far beyond the typical 15-25 range. Many are near-duplicates or legacy entries that inflate the surface without adding distinct capabilities, making the toolset heavy and harder to navigate.
Completeness4/5
Core workflows for evidence, signature, and notification appear fully covered: create/update/delete/search, upload/download URLs, report generation, composite flows, and status checks. The only notable gap is chat tools mentioned in help but not present, plus a few missing edge operations.
Average 4.3/5 across 64 of 64 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on May 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows it's a non-read-only, non-destructive write. However, the description does not disclose bulk operation behavior such as atomicity, partial failure handling, or error semantics. The statement 'each entry carries its own evidenceGroupId and changes' conflicts with the actual schema (flat ids array), adding confusion rather than clarity.
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 short and front-loaded with the core action and scope. However, the sentence 'each entry carries its own evidenceGroupId and changes' is misleading and inaccurate given the schema, occupying space that could be better used for clarifying the request structure.
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 bulk update tool with patch semantics and no output schema, the description is incomplete. It omits how to structure the patch array, the relationship between ids and patch, error handling, and partial-failure behavior. The mismatch between the described 'per entry' model and the actual schema further undermines completeness.
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%, so the description must fully explain parameters, but it barely does. It mentions 'evidenceGroupIds' and 'changes' without mapping to the actual schema properties 'ids' and 'patch'. It never explains the patch operations (REPLACE, REMOVE), path/value structure, or how patch applies to the multiple ids, and the 'each entry' phrasing actively misleads.
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 updates editable metadata of several evidence groups in one call, using a specific verb and resource. It also explicitly differentiates from the sibling tool evidence_group_update by advising to prefer that for a single group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'Prefer evidence_group_update for a single group' and notes the prerequisite to find evidenceGroupIds via evidence_group_search. This clearly indicates when to use the bulk tool versus the single-update 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?
The description adds critical behavioral context beyond annotations: the OPEN-only constraint and immutability of sealed groups. It also clarifies the ID acquisition flow. Annotations only provide readOnlyHint=false and destructiveHint=false, which align with the description (updating metadata is non-destructive but write-oriented). No contradiction detected.
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 and then constraints. Every clause adds value: the action, the OPEN-state caveat, and the prerequisite chain. There is no redundant fluff or repetition of 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 tool with 7 parameters, a nested object, and an output schema, the description covers the essential purpose and key constraints but leaves ambiguity about which fields are editable and how metadata should be structured. The output schema exists, but since it's not shown, the description should better clarify parameter roles, especially for optional fields like createdBy and metadata. Overall, it's adequate for selection but not for full invocation without additional inference.
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 only 29%, so the description must compensate, but it only mentions 'e.g. name, description' and doesn't explain the semantics of code, metadata, or createdBy. It also fails to clarify whether createdBy is actually editable, given the description says 'editable metadata' while schema lists createdBy as a property. The required IDs are described in the schema, but the description adds little beyond a dependency hint.
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: 'Updates an evidence group's editable metadata' with specific examples (name, description). It identifies the resource (evidence group) and scope (editable metadata), distinguishing it from sealing or discarding operations, though it doesn't explicitly differentiate from the bulk update sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear when-to-use condition: 'Only meaningful while the group is OPEN — sealed groups are immutable,' which also serves as a when-not-to-use. It also gives a prerequisite chain: 'Requires: caseFileId + evidence_group_create → evidenceGroupId,' helping the agent understand dependencies, but it does not mention alternative tools like evidence_group_update_bulk.
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 valuable behavioral context beyond annotations by stating there is no separate receiverId and that receivers are tracked via returned notificationIds. However, it lists provider values like SMTP and NOTICEMAN_AND_WHATSAPP that do not match the schema's actual provider const values (e.g., 'Notification_AddReceiverEmailNotificationRequestModel'), which could mislead an agent. This is not a contradiction with annotations but an internal inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The first two sentences are front-loaded and high-value, explaining the core purpose and workflow. However, the long pipe-delimited provider list at the end is verbose and not directly aligned with the schema's provider values, making the description longer and less focused than necessary.
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?
Although the description covers workflow and the absence of receiverId, the provider value mismatch is a significant gap. An agent could attempt to use 'SMTP' as the provider and fail because the schema requires a model string. The description does not reconcile the human-readable provider names with the schema's const values, so the overall context is insufficient 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?
The schema already describes requestId and provides detailed oneOf structures for receivers, but the description's provider guidance is confusing: it mentions 'provider (SMTP/SMS/NOTICEMAN/WFB)' while the schema expects const model names. This actively undermines parameter understanding. With 50% schema description coverage, the description fails to compensate and may lead agents to set invalid provider 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 opens with a clear, specific verb and resource: 'Adds one or more receivers to a draft notification request.' It also distinguishes this tool from siblings by explaining that each receiver becomes a per-channel notification under the shared requestId, making it clearly different from notification_request_create or notification_request_send.
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 the workflow position: 'Use once per batch of receivers before calling notification_request_send' and the prerequisite 'Requires: notification_request_create → requestId.' This gives an agent unambiguous guidance on when and how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint:false) and non-destructive. The description adds useful context about the dependency on evidence_case_file_create and the traceability purpose. It does not disclose behavior like idempotency, overwrite semantics, or failure modes, but annotations lower the bar for this dimension.
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 plus a short prerequisite line. It is front-loaded with the action and resource, then provides usage context, with no filler or redundant 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?
There is no output schema and the parameter descriptions are sparse, but the description provides workflow context and a clear prerequisite. It lacks detail on itemType/itemValue semantics and what happens after the relationship is assigned, leaving gaps for a mutation tool with three required parameters.
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 only 33% (caseFileId is described), and the description compensates only partially. It explains where to get caseFileId and hints that itemValue relates to a matter/client/system record, but it does not clarify the itemType enum (CHAT_CONVERSATION) or the expected format of itemValue. With low schema coverage, more parameter guidance is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assigns a relationship on a case file' and explains it links the case file to an external/related entity reference for traceability. This specific verb+resource+scope distinguishes it from sibling case_file tools like evidence_case_file_update or evidence_case_file_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use after creating the case file when your workflow tracks which matter, client, or system record it belongs to.' It also names the prerequisite step (evidence_case_file_create → caseFileId). However, it does not mention when not to use the tool or provide alternatives, 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 indicate readOnly and nondestructive behavior; the description adds meaningful behavioral context: the URL is temporary, it is for thumbnails only, and it avoids downloading the original. This goes beyond the structured safety hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose in the first sentence, followed by requirements. However, the naming error ('evidenceGroupId' vs 'groupId') slightly undermines its otherwise efficient structure.
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?
While a simple read tool with output schema and safety annotations, the description is not fully complete: the parameter naming inconsistency could cause invocation errors, and thumbnailSize semantics are unexplained. These are material gaps for correct usage.
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 only 50%, and the description must compensate but fails to do so adequately. It lists 'caseFileId + evidenceGroupId + evidenceId', but the actual schema parameter is 'groupId', creating a naming mismatch. It adds no meaningful detail for 'thumbnailSize' (e.g., accepted values), leaving two parameters under-described.
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 retrieves a temporary thumbnail URL for image evidence, specifying the exact verb and resource. It distinguishes itself from sibling download URL tools by emphasizing 'thumbnail' and 'without downloading the original file', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'use for quick visual verification without downloading the original file', providing clear context. It also notes 'image-type evidence only', which sets a boundary, though it does not name alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds meaningful context about the closeCondition filter semantics, explaining what ALL_REQUIRED and PARTIAL_ALLOWED mean. It does not contradict annotations and provides useful behavioral nuance beyond the structured fields.
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 compact and front-loaded with the core purpose. The closeCondition definitions are a bit lengthy but add necessary meaning. No fluff; each sentence has a function. It could be slightly tighter, but it is 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?
Given the tool's complexity (18 parameters), the description is incomplete. It gives one detailed parameter and mentions two others, but does not explain filter interactions, pagination defaults, or sorting behavior. An output schema exists, which mitigates some return-value concerns, but the operational context for using this list tool with many filters is lacking.
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 of explaining parameters. It details closeCondition in depth and names 'name or status' as example filters, but 18 parameters exist and the remaining ones are only referenced as 'among other criteria'. This is insufficient for a tool with this many filtering options.
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 starts with 'List signature requests', a specific verb+resource combination. It also explicitly contrasts with lookup by id: 'Use to find a request when you don't have its id', distinguishing it from the get_signature_request sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: when you lack the request id and need to find by name or status. It implies an alternative (get by id) but does not name it explicitly, nor does it discuss when not to use it. This is clear, practical guidance without thorough exclusions.
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 all false, offering no safety profile, so the description carries the burden. It discloses that the report is SIGNED/certified and that a reportId is returned, plus the need for later download calls. However, it does not discuss side effects, permission requirements, or idempotency, leaving behavioral depth incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, beginning with the primary purpose, then return value and next steps, then prerequisites. Every sentence contributes information without redundancy or excessive length.
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 a complex 9-parameter schema with nested objects and low schema coverage, the description is sparse. It omits parameter meanings and the structure of the data object, leaving an agent without enough information to correctly construct inputs. The high-level workflow is present, but not the detail needed for successful 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 only 22% (caseFileId and reportId have descriptions), and the description itself only references caseFileId and reportId. It fails to explain template, languageCode, data, filename, metadata, deletionDate, or additionalData. There is also ambiguity about reportId being both a required input and a return value, confusing parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating the signed evidentiary report of a case file. It distinguishes itself from sibling tools by specifying the return of a reportId and the subsequent download steps via PDF/zip URL tools, and by referencing the preview tool as a prerequisite.
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 provides explicit workflow guidance: it requires a caseFileId from evidence_case_file_create, recommends previewing with evidence_case_file_report_preview first, and directs the user to follow-up download tools. This gives clear when-to-use and when-not-to-use context relative to 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 readOnlyHint=false and destructiveHint=false, so the description is not required to state mutation. The description adds context that the file is 'not yet registered as evidence' and that the URL is 'presigned' (implying temporary). However, it does not disclose side effects like URL expiration, whether the upload URL is one-time-use, or what happens after upload. This is a moderate gap given the tool's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences. The first sentence front-loads the core purpose, and the second provides usage alternatives without redundancy. Every sentence earns its place, and there is zero 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?
The tool is complex (10 parameters, nested objects, no output schema), yet the description does not explain what the response contains (e.g., the presigned URL format or how to use it for upload). It also omits any mention of required prerequisites beyond the schema descriptions. The description covers the staging context but is incomplete for a developer to successfully invoke and process the result.
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 only 30%, with only caseFileId, evidenceId, and evidenceGroupId having descriptions in the schema. The tool description does not explain the remaining parameters (title, fileName, metadata, testimony, requiredTestimonyProviders, etc.) beyond the overall staging purpose. With low coverage, the description should compensate but does not, leaving parameter semantics ambiguous.
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 starts with a specific verb+resource: 'Creates a presigned upload URL for a TEMPORARY file not yet registered as evidence.' This clearly distinguishes the tool from siblings like evidence_upload_url_create by emphasizing the 'temporary' and 'not yet registered' scope. It also explicitly names alternative flows, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use for staging content that another operation will reference.' It also provides clear exclusions and alternatives: 'for real evidence prefer the register-then-upload flow (evidence_group_evidence_register) or the evidence_create_sealed composite, which handle registration and upload together.' This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) and not idempotent or destructive. The description adds the important timing constraint (before activation) and prerequisite steps, but does not disclose whether duplicates are allowed or what happens if called after activation. 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?
The description is three sentences, front-loaded with the action and definition, and every sentence provides useful context. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, prerequisites, and timing, and an output schema exists for return values. It does not mention error conditions (e.g., after activation), but for a moderate-complexity add-operation this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40%, and the description adds provenance for the ID parameters (create_signature_request → signatureRequestId, add_document_to_signature_request → documentId). However, name, email, and surnames are not explained beyond their schema types, leaving some gaps for a low-coverage situation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Adds' and the resource 'observer to a signature request's document,' and it defines the observer's role as read-only without signing. This distinguishes it from sibling tools like add_signatory_to_document and add_validator_to_signatory.
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 explicitly says to add observers BEFORE activate_signature_request and supplies the required prerequisite flow (create_signature_request → signatureRequestId, add_document_to_signature_request → documentId). It does not explicitly name alternatives, but the 'without signing' clause differentiates from signatory-related 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 annotations (which only mark non-read-only, non-idempotent, non-destructive), the description adds key constraints: signatories cannot be added after activation and each call adds one signatory per person. This is valuable behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler, leading with the action and including the most important usage constraints in a compact form.
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 workflow prerequisites and post-activation restriction are covered, but optional parameters remain unclear and sibling relationships are not explained. Given the low schema coverage and 9 properties, the description is 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 includes 9 properties but only 2 have descriptions (22% coverage). The description mentions signatory name and email and the two IDs from prior steps, but does not explain optional parameters like phone, sequence, surnames, coordinates, or uniqueValidator. This leaves most parameters underspecified.
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 action (Adds) and identifies the resource (signatory) and containment (document within a signature request). It also distinguishes from sibling tools like add_validator_to_signatory and add_observer_to_document by specifying 'who needs to sign'.
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 provides a clear workflow: requires signatureRequestId from create_signature_request and documentId from add_document_to_signature_request, and warns to add all signatories before activation. It states 'Use once per person', giving practical usage, but does not explicitly name alternative tools for non-signatory roles.
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 this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds important context: the tool returns an id that must be used as signatureRequestId in subsequent calls, and it's the entry point for a multi-step flow. This goes beyond basic annotation info and helps the agent understand the side-effect/workflow implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, followed by sequencing, a prerequisites statement, and a concrete example. Every element earns its place 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?
The description gives essential high-level context (top-level container, use-first) and points to the return id handoff. However, given the tool's complexity (12 params, nested objects, many sibling tools), it lacks guidance on key optional parameters and their interplay. The output schema covers return values, but the description leaves significant gaps for a complex creation 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?
Schema description coverage is 0%, and with 12 parameters, the description must compensate. It only illustrates 'name' and 'createdBy' via an example and ignores the other 10 parameters (e.g., provider, closeConfig, notifications, signatureRequestBody). The schema provides names and types but not meanings, so the description does not adequately guide parameter usage.
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 'Creates a new signature request — the top-level container for documents and signatories in a signing flow.' This specific verb+resource+role distinguishes it from sibling tools like add_document_to_signature_request and add_signatory_to_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit instruction 'Use this first, before add_document_to_signature_request' provides clear sequencing guidance with a named alternative. 'No prerequisites' adds practical context. However, it doesn't mention situations where this tool should not be used, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no useful safety hints (all false), so the description bears the burden. It adds context by emphasizing 'UNSIGNED preview' and the check-before-signing purpose, but it does not disclose potential side effects, permissions, or whether any persistent data is created. This is a moderate transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes necessary workflow context without any redundant or vague 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?
Given the high complexity (nested objects, 6 parameters) and unhelpful annotations, the description covers purpose and workflow but leaves parameter semantics for required inputs like `template` and `languageCode` unexplained. The presence of an output schema reduces the need to describe return values, but the invocation details remain incomplete.
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 very low (17%); only `caseFileId` has a schema description. The description mentions `caseFileId` and sealed evidence groups but does not explain the required `template` and `languageCode` parameters or the structure of the nested `data` object. The description fails to compensate for the low 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 uses a specific verb ('Generates'), identifies the resource ('case file's evidentiary report'), and distinguishes this tool from the signed-version sibling by explicitly naming 'UNSIGNED preview' and the alternative tool `evidence_case_file_report_generate`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the intended use ('check content before producing the signed version'), names the alternative tool, and provides a prerequisite workflow ('evidence_case_file_create → caseFileId, with sealed evidence groups inside'). This gives the agent explicit guidance on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that it updates 'editable metadata' and operates on multiple files, but does not disclose failure semantics, partial success behavior, or any side effects beyond what annotations imply.
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 short sentences, front-loaded with the primary purpose. Every sentence provides useful information without redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description gives some usage context, but it lacks explanation of the relationship between ids and patch, and does not address bulk operation caveats like atomicity or partial failures. Given the complexity of a bulk update, the description is incomplete.
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, and the description does not compensate. It claims 'each entry carries its own caseFileId and changes,' which does not match the actual schema structure of separate 'ids' and 'patch' arrays, potentially misleading the agent about how parameters relate.
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 updates editable metadata of several case files in one call, using a specific verb and resource. It also distinguishes itself from evidence_case_file_update, which is for a single case file, making 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 instructs to prefer evidence_case_file_update for single case files, providing an alternative. It also tells the user they need caseFileIds and points to evidence_case_file_search to find them, giving clear when-to-use and prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds 'temporary' (expiring URL) and 'after upload' workflow, but does not detail expiration duration or response format. This is useful but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence earns its place. The requirement chain is compact and useful without being verbose.
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, 3 UUID parameters, and good annotations, the description is adequate. It states the output (download URL), the use case, and prerequisites. It lacks expiration details or error conditions, but these are not essential for basic invocation with strong schema support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter includes provenance guidance (e.g., 'Obtain from evidence_case_file_create'). The description restates the required chain but adds no new parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a temporary download URL for an evidence file in a group, distinguishing it from similar tools like evidence_download_url_create. The verb and resource are specific, and the parenthetical '(INTERNAL custody)' adds 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 description gives clear context: use it to retrieve original bytes after upload, and it lists the required ID chain (caseFileId + evidenceGroupId + evidence_group_evidence_register → evidenceId). It does not explicitly name alternatives or exclusions, but the context implies when to use it versus non-group downloads.
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 annotations (which only indicate non-read-only, non-idempotent, non-destructive), the description discloses that file content and hash are immutable and that changed files require re-registration. It also specifies that an evidenceId must come from prior registration or generation. This adds meaningful behavioral context, though it does not go into partial-update semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with two sentences that front-load the core purpose, then state the key constraint and prerequisite. Every sentence provides essential information with 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 core operational context (single evidence, editable metadata, immutable content, evidenceId provenance) but lacks explanations for the nested deletion fields, metadata structure, and return behavior. Given no output schema and only 14% parameter coverage, the description is adequate but not fully complete for a 7-parameter 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?
Schema description coverage is only 14% (only evidenceId is described), so the description must compensate for the other six parameters. It broadly says 'editable metadata' and gives examples, but does not explain the semantics of deletionDate, deletionType, createdBy, custody, or metadata structure. This leaves substantial gaps for the agent to infer parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Updates'), a specific resource ('a single evidence's editable metadata'), and a specific identifier ('by evidenceId'). It clearly differentiates from sibling tools like evidence_update_bulk by emphasizing 'single' and clarifies what is immutable (file content and hash), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool (updating editable metadata) and when not to use it (when file content changes, re-register a new evidence). It also states a prerequisite for obtaining the evidenceId. It stops short of explicitly naming a sibling alternative for bulk updates, but the 'single' qualifier and sibling name make that implicit.
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 are all false/default and offer no meaningful safety or mutation hints. The description carries the burden and reveals a key trait: the tool only creates a pre-signed URL, it does not upload the file; the caller must PUT bytes to that URL. It does not mention expiration or auth requirements, but the essential non-obvious behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, followed by concise flow and pairing context. No filler or redundant details; 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 flow, prerequisite, and PUT action are well explained, and the description adds useful pairing context. However, with no output schema and sparse annotations, it still leaves gaps: no return format, no URL expiry, no explanation of how fileName is used, and no distinction from analogous upload-URL siblings.
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 describes evidenceId, but fileName has only a minLength and no semantic description. The description completely omits fileName, even though it is a required parameter, and only contextualizes evidenceId via the flow. With 50% schema coverage, the description fails to compensate for the missing parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific action: 'Creates a fresh presigned upload URL for an already-registered evidence by evidenceId', and clearly positions it as step 2 of a flow. It distinguishes from generate_evidence and similar sibling tools by specifying the register-then-upload order and referencing evidenceId rather than creating the evidence itself.
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?
Provides clear context: requires generate_evidence → evidenceId, instructs the agent to PUT file bytes to the returned URL, and names a parallel pairing. It does not explicitly exclude alternatives like evidence_temp_file_upload_url_create or evidence_multipart_upload_start, so it stops short of a full when-to-use vs when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
All annotations are false, so the description carries the full burden. It adds the useful trait that the URL is presigned and specifies dependencies, but it doesn't disclose expiration behavior, authentication requirements, or whether the operation has side effects. This is a moderate gap for a tool that creates a time-limited resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The main purpose is front-loaded and the prerequisite chain is compressed into a clear arrow notation. 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 two-parameter tool with full schema coverage and no output schema, the description adequately covers the tool's purpose and usage context. It omits the return format and expiration details, but the tool's simplicity makes the description sufficient for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already explains its origin ('Obtain from notification_request_create' and 'Obtain from notification_document_add'). The description's 'Requires' line essentially repeats this, adding no new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and resource ('presigned download URL for a document attachment on a notification request'), making the tool's function immediately clear. It also distinguishes itself from the sibling upload tool by emphasizing 'download'.
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 states the required prior calls ('notification_request_create → requestId, notification_document_add → attachmentId'), giving actionable workflow context. It doesn't explicitly exclude alternatives, but the prerequisite chain and download-specific wording are sufficient for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds valuable context about the fan-out into per-receiver notifications with state history, which is not evident 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?
The description is concise, front-loaded with the action, and uses a clear analogy to 'checking a request's status'. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 7 parameters, the description covers the core use case well but omits guidance on pagination, sorting, and the nested filters object. The output schema partially compensates for return value documentation.
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 only 14%, so the description must compensate, but it only explains requestId and delivery state. Other parameters (ids, page, size, sort, filters) are not mentioned, leaving much of the schema 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 clearly states the tool searches notifications with optional filters for requestId and delivery state, and explicitly links it to checking a request's status. It distinguishes itself from sibling notification tools by explaining the fan-out concept.
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 provides context for when to use (checking request status) and explains that omitting requestId searches across all requests, but does not explicitly name alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the agent knows this is a mutating operation. The description adds the context that this is for explicit placement versus auto-positioning and the required preceding steps. However, it does not disclose whether repeated calls overwrite prior coordinates, the coordinate system/units, or what the response contains. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first gives the core function, the second gives the usage condition, and the third lists prerequisites in a compact arrow format. Every sentence carries necessary information, with no fluff or repetition.
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?
There is no output schema, so the description should convey what the tool returns or accomplishes beyond the mutation. It does not mention whether coordinates is required (schema marks it optional, which is confusing given the tool's purpose), how the coordinate array is structured, or whether the operation returns a success indicator. This ambiguity could lead an agent to invoke the tool incorrectly.
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 75%: the three ID parameters each have descriptions in the schema, and the description restates their source tools in the prerequisites. For the coordinates parameter, the schema only provides its array/object structure; the description says 'on-page (x, y, page) coordinates' but does not explain units, origin, or pagination semantics. With high schema coverage, the baseline is 3, and the slight added context for coordinates does not elevate it.
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: 'Sets the on-page (x, y, page) coordinates where a signatory's signature appears on a document.' It uses a specific verb ('sets'), names the resource (coordinates for a signatory's signature), and distinguishes itself from sibling tools like add_signatory_to_document by focusing on explicit placement rather than adding a signatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use after add_signatory_to_document if the signature placement needs to be explicit rather than auto-positioned.' It also lists the exact prerequisite chain (create_signature_request → signatureRequestId, add_document_to_signature_request → documentId, add_signatory_to_document → signatoryId), which helps the agent sequence the call correctly.
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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds behavioral context beyond annotations by indicating that the tool is meant for discovering caseFileIds and inventorying existing files, which helps the agent understand its role in a workflow.
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 redundant content. It front-loads the action ('Searches case files') and then immediately provides usage guidance. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and usage scenario, and the output schema fills in the return value details. However, the incomplete filter parameter list and the name/title mismatch create a potential gap in understanding the full range of search capabilities. Moderate complexity warrants a slightly more detailed parameter mention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'name' (which maps to 'title' in the schema), status, dates, and pagination, but omits many other schema properties like id, code, owner, category, metadata, and sort. The term 'name' is inconsistent with the schema's actual property name, and the list of examples is incomplete for the full filter object.
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 searches case files and lists specific filter types. It distinguishes itself from sibling tools like evidence_case_file_get and evidence_case_file_create by framing its role as a search/find operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: use to find a caseFileId when you don't have it, or to list existing files before creating a new one with evidence_case_file_create. This clearly indicates when to use the tool and names an alternative, though it doesn't explicitly state the 'when-not' case (e.g., if you already have the ID).
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, destructiveHint=false, and idempotentHint=true. The description adds a general sense of non-mutating behavior (via 'Gets') and lists the fields returned, but does not disclose error conditions, pagination, or other behavioral nuances. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence front-loads the main purpose; the second provides terse, high-value prerequisite guidance. There is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward get tool with three required UUIDs and an output schema present, the description supplies all necessary context: what it returns, the group scope, and how to obtain each ID. The presence of an output schema means return-value details do not need to be in the description. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, each with a description and a source tool. The description's 'Requires' chain partially echoes the schema, but adds no new semantic meaning about parameter values or format. Baseline of 3 is appropriate given high 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 explicitly states the action ('Gets'), the resource ('one evidence's details'), and the scope ('inside a specific evidence group'). It also lists the specific data returned (metadata, hash, custody, upload state), which clearly distinguishes it from sibling tools like evidence_group_get or get_evidence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite chain ('Requires: evidence_case_file_create → caseFileId, evidence_group_create → evidenceGroupId, evidence_group_evidence_register → evidenceId'), telling the agent which upstream tools to call to obtain each required parameter. However, it does not explicitly contrast with alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, covering the safety profile. Description adds that it retrieves a download URL for the complete ZIP package and mentions the prerequisite, but no additional behavioral traits such as rate limits or response details. 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?
Description is two sentences. First sentence states purpose and differentiator. Second sentence provides prerequisite. Both are essential with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and annotations covering read-only behavior, the description is sufficient for a 1-parameter tool. It specifies the package returned, the precondition, and the input source. No major gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with reportId described as 'MANDATORY. UUID of the report.' The description adds context by explaining that the reportId is obtained from evidence_case_file_report_generate, which is useful workflow information. However, since the schema already fully documents the parameter, the description's added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieves' and clearly identifies the resource: 'a report's complete ZIP package' with access condition 'when you only hold the reportId'. It explicitly references sibling tool evidence_case_file_report_zip_url_get, clarifying it returns the same package, which distinguishes it from other evidence/report 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 'when you only hold the reportId' provides a clear usage context, implying this tool is for reportId-based access rather than case-file-based access. It also states the prerequisite 'Requires: evidence_case_file_report_generate → reportId', which tells the user the required prior step. However, it doesn't explicitly list alternative tools to use in other situations.
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 context beyond the neutral annotations by specifying it operates on 'editable metadata' (excluding lifecycle state) and targets a single file. It does not mention partial-update semantics or return values, but the key behavioral boundaries are clear.
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: the first states the core action with examples, the second covers prerequisite and alternative. Every word earns its place, and the most important information is front-loaded.
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 lack of output schema and presence of a nested metadata object, the description could explain whether omitted fields are preserved and which fields are considered editable. It provides a solid scope but leaves some behavioral details unstated.
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 (14%), and the description's examples ('name, description') are partially misleading because 'name' is not a property (likely 'title'), and it does not explain the metadata object or other fields. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates a single case file's editable metadata with examples, and explicitly differentiates from sibling tools like evidence_case_file_update_bulk (single vs bulk) and evidence_case_file_status_update (lifecycle vs metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides a prerequisite (obtain caseFileId from evidence_case_file_create or evidence_case_file_search) and directs the agent to use evidence_case_file_status_update for lifecycle changes, offering a clear alternative and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, and the description reinforces this with 'Destructive' and 'deletes... registered evidences'. It adds useful context beyond annotations by specifying that only OPEN groups are discardable and that CLOSED/sealed groups are immutable, which helps the agent understand state constraints.
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 action and use-case, followed by a concise destructive warning and prerequisite note. Every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive tool with full schema descriptions and strong annotations, the description covers the action, state constraints, destructive consequence, and dependency chain. It does not describe return/error behavior, but no output schema exists and delete operations commonly return a simple success status, so this is an acceptable omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters fully described, including their UUID format and provenance ('Obtain from evidence_case_file_create' and 'Obtain from evidence_group_create'). The description's 'Requires' line adds a compact dependency hint but does not meaningfully extend the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Discards (deletes)') naming the resource ('OPEN evidence group and its registered evidences') and the intended use ('abandon a group you no longer intend to seal'). It also distinguishes the operation from handling sealed/CLOSED groups, which separates it from related evidence_group actions.
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 clearly states when to use the tool ('use to abandon a group you no longer intend to seal') and when not to ('sealed (CLOSED) groups are immutable evidence and should not be discarded'). It also gives a prerequisite chain ('Requires: caseFileId + evidence_group_create → evidenceGroupId'), but does not explicitly name alternatives like evidence_group_delete_bulk.
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 destructiveHint=true and idempotentHint=true, but the description adds 'Permanently deletes' (reinforcing irreversibility) and the critical constraint that sealed groups are immutable. This goes beyond the structured annotations by explaining the operational precondition (group must be OPEN). It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. The core purpose is front-loaded, the open-group constraint follows logically, and the parameter chain is stated compactly. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description covers the action, the prerequisite (open group), and the parameter dependency chain. Combined with 100% schema coverage and strong annotations (destructive, idempotent), it is largely complete. A minor ambiguity remains about whether it deletes the evidence record itself or just the group membership, but the tool naming and sibling context mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a description with provenance (e.g., 'Obtain from evidence_group_evidence_register'). The description's 'Requires: caseFileId + evidenceGroupId + evidence_group_evidence_register → evidenceId' is a concise restatement of the relationships already detailed in the schema, adding no additional semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently deletes one evidence from an evidence group.' It uses a specific verb ('deletes') and resource ('one evidence from an evidence group'), which distinguishes it from siblings like evidence_group_delete_bulk (deletes entire group) and evidence_delete (deletes evidence globally). The scope is explicit.
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: 'Only makes sense while the group is still OPEN (sealed groups are immutable).' This tells the agent when to use the tool and when not to. It also mentions the required parameter chain (caseFileId + evidenceGroupId + evidence_group_evidence_register → evidenceId), which implies the evidence must have been registered via that flow. However, it does not explicitly name alternative tools or contrast with them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating that the tool returns upload coordinates and requires a pre-registered evidence. While annotations already indicate mutation (readOnlyHint=false), the description clarifies the session-starting nature and prerequisites without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and return value, followed by usage condition and prerequisites. No wasted words, every sentence contributes to understanding the tool's role.
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 tool with 10 parameters and no output schema, this description is minimal but covers the essential purpose, when-to-use, and prerequisites. However, it lacks details on the structure of returned 'upload coordinates', how to proceed after starting, and what the many parameters mean, making it adequate but with clear gaps for a complex operation.
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 only 30%, the description should compensate for the seven undocumented parameters. It only explicitly mentions evidenceId and fileName, and evidenceId's meaning is already covered in the schema. Most other parameters (e.g., title, createdBy, testimony, requiredTestimonyProviders) remain unexplained, leaving the agent without sufficient semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a MULTIPART upload session for large evidence files, using a specific verb and resource. It distinguishes itself from alternatives by explicitly mentioning when a single presigned PUT is insufficient, which differentiates it from sibling upload tools like evidence_upload_url_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance ('Use when a single presigned PUT is not enough for the file size') and lists prerequisites (already-registered evidence and file name), naming specific sibling functions for obtaining the evidenceId. This effectively directs the agent on when to choose this tool over 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 indicate readOnlyHint=false and destructiveHint=false, so the mutation is already known. The description adds context by specifying 'editable metadata' and that each entry carries its own evidenceId and changes, giving behavioral insight beyond the schema. 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?
The description is three concise sentences with no fluff. It front-loads the verb and scope, includes usage alternatives, and provides a prerequisite—all relevant information without unnecessary detail.
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 covers purpose, alternatives, and prerequisite, it fails to explain the critical relationship between the 'ids' array and the 'patch' array, and does not mention return values or error behavior. Given no output schema and a bulk mutation tool, this gap leaves the description minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It vaguely mentions 'each entry carries its own evidenceId and changes' but does not explain the structure of the 'patch' array (operation/path/value) or how 'ids' relates to 'patch'. This leaves significant ambiguity for correctly invoking the 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 clearly states the tool updates editable metadata of several evidences in one call, using a specific verb and resource. It also distinguishes itself from the sibling tool evidence_update for single evidence, making its purpose and scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer evidence_update for a single evidence and requires evidence_search to find the evidenceIds. This provides clear when-to-use and alternative tool guidance, exceeding basic usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the exact status values (IN_PROCESS, COMPLETED, ERROR) and the registration prerequisite, which enriches the behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and followed by use case and requirement. Every sentence earns its place with no redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema present), the description is nearly complete. It covers purpose, usage context, and prerequisites. The only slight gap is not explicitly stating 'top-level evidence only' or contrasting with group-level alternatives, but the 'legacy top-level name' hint mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for evidenceId (MANDATORY, UUID, obtain from evidence_group_evidence_register or generate_evidence), and coverage is 100%. The description repeats this requirement but does not add new semantic detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an evidence record's details and status by ID, with the specific use of checking timestamping status. The phrase 'legacy top-level name' distinguishes this from group-level evidence tools like evidence_group_evidence_get, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use: after registration, to check status (IN_PROCESS / COMPLETED / ERROR). It also specifies the prerequisite chain (generate_evidence or evidence_group_evidence_register → evidenceId). It lacks explicit alternatives or when-not-to-use guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the dependency on create_signature_request and the 'legacy top-level name' note, which are useful behavioral cues. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action. Both sentences carry essential information: what it does and when to use it with a prerequisite. No redundant or filler content.
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 read-only tool with one parameter, a well-documented schema, and an output schema present, the description adequately covers the purpose, usage context, and prerequisite. It could mention potential errors or return format details, but those are standard for such tools and are largely inferred from the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description for signatureRequestId, including that it is a mandatory UUID and where to obtain it. The description repeats this dependency without adding new syntax or format details. With 100% schema coverage, the baseline is 3, and the description does not exceed 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?
The description clearly states the action: "Retrieves a signature request's details and status by id." It specifies the resource and the identifier method, and the note "legacy top-level name" helps distinguish it from potential newer variants. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context: "Use to check signing progress after activation." It also states a prerequisite: "Requires: create_signature_request → signatureRequestId." However, it does not explicitly mention when not to use it or name alternative tools like signature_request_list or signature_request_full, so it falls short of full 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 indicate readOnlyHint=false, but the description adds valuable behavioral context: the tool only generates a URL and does not upload the file, and the caller must 'PUT the file bytes to the returned URL'. This goes beyond the annotations by explaining the subsequent action. 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 sentences, front-loaded with the action and the PUT instruction. The dependency chain is compactly expressed with arrows. Every phrase serves a purpose, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so no return-value explanation is needed. The description covers the workflow context (what must happen before and after calling this). It does not mention the optional fileSize, but this is a minor gap given the tool's simplicity and the provided workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes requestId and attachmentId with 'Obtain from' guidance, and the description repeats this. The optional fileSize parameter lacks a schema description, and the description does not explain its meaning or relevance. Schema coverage is 67%, so the description adds marginal value over the schema but does not fully compensate for fileSize.
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: 'Creates a presigned upload URL for a document attachment already registered via notification_document_add'. It distinguishes itself from sibling tools like notification_document_download_url_create by specifying upload and using the verb 'creates' with a specific resource.
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 provides the required prior steps: 'Requires: notification_request_create → requestId, notification_document_add → attachmentId'. It implies when to use the tool (after registering a document, before uploading bytes) and even explains how to use the result (PUT to the URL). However, it does not explicitly state when not to use it or mention alternatives beyond the implied workflow.
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 carry no behavioral hints (all false), so the description bears the full burden. It discloses the two-step upload behavior, the need to PUT file bytes to a returned URL, and explains signature type semantics in detail. However, it does not address idempotency, failure modes, or side effects beyond the workflow, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but well-structured with clear progression: purpose, workflow, prerequisites, and signature type definitions. Each sentence contributes value without fluff. It could be slightly more scannable with bullets, but overall it is concise for the complexity it covers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, nested objects) and 13% schema coverage, the description covers the critical workflow and key parameters but omits many optional ones. It also references related tools (create_signature_request, add_signatory_to_document, signature_request_full), giving it enough context for an agent to operate. Missing optional parameter explanations prevent a 5.
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 only 13%, so the description must compensate. It adds meaning for signatureType (explains the three enum values) and hash (specifies SHA-256), and clarifies signatureRequestId's origin. However, many parameters (detached, fileSize, metadata, provider, sequence, evidenceId, description, convertToPdf, certificateFiles, signatureDeadline) remain undocumented, leaving significant semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Adds a document to a signature request.' It also distinguishes the tool by framing it as the first step of a 2-step upload process, which separates it from sibling tools like notification_document_add or evidence_upload_url_create. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it names prerequisites (create_signature_request, SHA-256 hash), describes the sequential workflow (add document, PUT bytes, add signatories, activate), and mentions an alternative composite tool (signature_request_full). It also states 'Use once per document that needs signing,' offering clear when-to-use direction.
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 explains the validator's function (approve identity/document) and sequencing constraints, adding context beyond the annotations. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). However, it omits potential edge cases such as adding after activation or any idempotency 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 three sentences, each serving a distinct purpose: definition, timing, prerequisites/alternative. It is front-loaded with the core action and contains no redundant wording.
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 moderate complexity, the description covers the concept, ordering, prerequisites, and an alternative integration path. An output schema exists, so return values are not required. It could mention any limits on validator count or post-activation behavior, but overall it is sufficient for selecting and invoking the 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?
Schema description coverage is only 33% (documentId and signatoryId have descriptions). The description reinforces the provenance of these IDs but adds little for name/email/phone/surnames, which are left to the schema's basic types. It does not compensate for the missing parameter explanations.
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 'Adds a validator to a document's signatory' and defines the validator's role. It distinguishes from sibling tools like add_signatory_to_document and add_observer_to_document by specifying the approval/validation purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Add validators BEFORE activate_signature_request' and lists required prior calls (add_document_to_signature_request → documentId, add_signatory_to_document → signatoryId). It also mentions the alternative of using signature_request_full, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the dependency on evidence_case_file_create for the caseFileId and the purpose of checking status before subsequent operations, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence adds value: the first defines the function, the second provides use cases and a prerequisite. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, full schema coverage, output schema present, and safety annotations already provided, this description is complete. It explains when to use the tool and the prerequisite relationship, making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter fully with a detailed description including the UUID format and source from evidence_case_file_create. The tool description adds little beyond restating 'by id', so the schema does the heavy lifting, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieves a case file's details by id', specifying the verb, resource, and identifier. This distinguishes it from sibling tools like evidence_case_file_search (searching) and evidence_case_file_create (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use it 'to confirm a case file exists, or to check its status before creating evidence groups or reports under it', providing clear use cases. It does not explicitly name alternative tools for scenarios like searching without an ID, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the dependency on prior generation and the packaged contents, providing useful context beyond the 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 concise sentences: first states the purpose, second states the prerequisite. No redundant or vague wording.
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 simple read-only URL getter with output schema present, the description covers purpose, prerequisite, and the package contents. Sibling differentiation is clear enough given the tool name and description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters already have descriptive text (mandatory UUIDs, source for caseFileId). The description only references the same parameters without adding additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a download URL for a complete ZIP package of a case-file report, specifying the contents (signed PDF plus evidence files and verification material). This distinguishes it from sibling tools like evidence_case_file_report_pdf_url_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite call (evidence_case_file_report_generate) and required identifiers (reportId, caseFileId). However, it doesn't explicitly contrast with alternatives like pdf_url_get or evidence_report_zip_url_get, though the 'complete ZIP' phrasing implies when to use 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds value by emphasizing 'Permanently deletes' and adding a specific risk caution about sealed groups backing issued reports. This goes beyond the annotation flags and gives actionable context, though it doesn't elaborate on idempotency behavior or 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?
Three sentences, each with meaningful content: scope, alternative, and required parameters. No redundancy or fluff. It is front-loaded with the core purpose and immediately flags destructiveness.
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 tool's purpose, alternative, and a critical caveat, but its 'Requires' list omits requestId, which is a required parameter. While the schema supplies this detail, the description is the primary guidance and should at least mention it. No output schema exists, but the description doesn't explain expected return behavior, leaving a minor gap for a destructive bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (descriptions for requestId and caseFileId, but not ids). The description adds meaning by calling ids 'the evidenceGroupIds to delete' and suggesting evidence_group_search to find them. However, it omits mention of the required requestId, so it does not fully compensate for the coverage 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 states a specific verb ('permanently deletes'), resource ('evidence groups'), scope ('SEVERAL evidence groups of one case file in one call'), and distinguishes from the sibling tool evidence_group_discard. It clearly differentiates this bulk destructive operation from a single-group alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('SEVERAL evidence groups of one case file in one call') and when not to ('prefer evidence_group_discard for a single group'). It also provides a direct warning ('never delete sealed groups that back issued reports') and a pointer to evidence_group_search to find target groups. This is exemplary usage 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, so safety is covered. The description adds scope ('across case files') and implies result granularity by contrasting with evidence_group_get, but doesn't disclose response format or pagination 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 that front-load the action and include an explicit pointer to a sibling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations present, the description covers purpose, filters, and alternatives. It could mention that results are paginated summaries, but it's adequate for a search tool with a sibling detail 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?
Schema description coverage is 0%, so description must compensate. It only mentions status, dates, and pagination generically, leaving many parameters (id, code, name, type, metadata, etc.) unexplained. Parameter names are self-explanatory, but the description adds little semantic value beyond them.
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 'Searches evidence groups across case files with optional filters' with a specific verb+resource+scope. It distinguishes from sibling evidence_group_get by noting that tool is for 'one group's full detail', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use to find an evidenceGroupId or list groups pending sealing' and names evidence_group_get as the alternative for full detail. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a write operation (readOnlyHint=false) without destructive or idempotent hints. The description adds valuable behavioral context by explaining the SHA-256 hash requirement and detailing the semantics of custody types (INTERNAL vs EXTERNAL) and testimony providers (TSP vs DLT), which go beyond the annotations. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then systematically covers usage, requirements, and enum semantics. It is longer than some descriptions but every sentence provides useful information. The structure is clear and scannable, with the custody and testimony explanations separated by vertical bars.
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 complex tool with 14 parameters and an output schema, the description covers the primary purpose, usage alternatives, key requirements, and important enum values. The presence of an output schema means return values are documented elsewhere. It does not explain every parameter, but the most critical ones are addressed, making it reasonably complete for a context-heavy tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 7%, so the description must compensate. It adds meaning for key parameters: 'Requires the file's SHA-256 hash' clarifies the hash parameter, and it thoroughly explains custodyType and testimony enums. However, it does not explain other parameters like evidenceId, capturedAt, or requiredTestimonyProviders, leaving gaps. The added semantics are helpful but 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 states 'Register a new evidence' with a specific verb and resource, and explicitly distinguishes it from evidence_group_evidence_register by noting it is not scoped to a group. It also mentions the legacy top-level nature, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use for standalone evidence outside the group-based flow, or for continuity with the legacy EAD-Factory-MCP integration.' It also gives an explicit alternative: 'Prefer evidence_create_sealed for a new, complete evidence group + evidence + seal flow.' This clearly states when to use this tool versus related 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?
The description discloses irreversibility ('Cannot be undone') and the 'active' state restriction, which are not fully captured by annotations. The annotations state readOnlyHint=false and destructiveHint=false, which are consistent with the description. The added context about no further signing and irreversibility goes beyond the structured data 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 four short sentences, each delivering distinct information: action, consequence, use case, prerequisite, and irreversibility. There is no redundancy or filler; every sentence earns its place and the front-loaded action makes it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, an output schema, and annotations, the description is complete. It covers purpose, usage context, prerequisite, and irreversibility, which is sufficient for an agent to select and invoke the tool correctly without needing further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete parameter documentation with 100% coverage: the signatureRequestId is described as 'MANDATORY. UUID of the signature request. Obtain from create_signature_request.' The tool description's 'Requires: create_signature_request → signatureRequestId' merely echoes the schema description, adding no new semantic detail. This aligns with the baseline score of 3 for high 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 'Cancels an active signature request' with the consequence 'no further signing can occur.' This distinguishes it from sibling tools like activate_signature_request and get_signature_request, and the verb 'cancel' + resource 'signature request' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides the use case: 'Use when a request was activated in error or is no longer needed.' It also gives a prerequisite chain ('Requires: create_signature_request → signatureRequestId'). However, it does not mention alternatives or when not to use, so it misses the full 'when/when-not/alternatives' bar for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the multi-step behavior (create, add documents/signatories, activate), the draft-mode behavior with activate:false, and the return payload (request id, document ids, signatory ids). This goes beyond the schema and clearly communicates side effects and outputs.
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 four sentences long, front-loaded with the core purpose. Each sentence contributes essential information: the main flow, the file contract, the draft option, and return/alternatives. It is slightly dense but efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested documents/signatories and no output schema, the description is complete: it explains the overall workflow, the activate flag, the file input contract, return values, and when to use alternatives. It does not detail every nested parameter, but the schema provides that, so the description is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the baseline is 3. The description adds value by clarifying the shared FileInput contract ('local path, base64, https URL, or n8n binary item — never a bespoke file field') and by explaining the activate parameter's purpose for draft creation. This is meaningful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Creates a signature request, adds one or more documents (each with its own signatories), and activates it.' It explicitly differentiates from the atomic siblings by naming the alternative sequence (create_signature_request + add_document... + add_signatory... + activate_signature_request), making the tool's scope and distinctiveness 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 gives explicit guidance: 'Use the atomic tools instead when you need to inspect or react to each intermediate step, or need validators/observers before activation.' It also explains the activate:false draft option for adding validators/observers. However, the 'need validators/observers before activation' clause is slightly contradictory given the activate:false path, so it's not perfectly 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 indicate readOnlyHint=false and destructiveHint=false. The description adds meaningful behavioral context beyond annotations: it clarifies the tool only updates metadata and does not re-generate report content. This helps the agent set expectations about side effects. It does not detail behaviors like partial updates or return values, but the annotations lower the burden.
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 the purpose front-loaded in the first sentence. The second sentence covers prerequisite and exclusion without wasted words. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisite, and a key exclusion. It lacks a note about the return value (though no output schema exists) and does not explain the deletionDate parameter, but given the tool's simplicity and the provided prerequisite context, it is largely complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%: reportId and caseFileId have descriptive text, but deletionDate has no description in the schema. The description adds meaning by framing these as metadata and requiring the prerequisite relationship, but it does not explain deletionDate's semantics or that it is optional. This leaves a gap for the parameter, so the description only partially compensates for the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Updates a previously generated case-file report's metadata.' This clearly distinguishes it from siblings like evidence_case_file_report_generate (which generates content), evidence_case_file_report_preview, and evidence_report_delete. The scope is precisely defined.
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 prerequisite: 'Requires: evidence_case_file_report_generate → reportId (and the caseFileId it belongs to).' It also gives an exclusion and alternative: 'Does not re-generate the report content — generate a new report for updated evidence.' This tells the agent when to use this tool versus when to use the generate 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 do not provide meaningful safety hints (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds context beyond annotations by framing this as step 2 of a flow, requiring PUT to the returned URL, and noting the URL may expire ('fresh' URL, 'expired or was lost'). It also discloses that evidence_create_sealed covers this automatically. 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?
Three sentences, each earning its place: purpose, when-to-use, requirements, and alternative. The information is front-loaded and free of fluff. The description is highly compact while packing flow context, usage guidance, and a cross-reference to an alternative 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?
No output schema exists, but the description implicitly states the return value by saying 'PUT the file bytes to the returned URL.' It also covers the flow context, prerequisites, and alternative. It does not go into URL expiry details or invalidation of previous URLs, but 'fresh' implies this. For a focused URL-generation tool, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with the three UUID parameters having rich descriptions ('Obtain from...'). The description repeats these three as 'Requires: caseFileId + evidenceGroupId + evidenceId' but omits the nested requestModel object and its required fileName. Since the schema itself already documents the UUIDs well, the description adds little new semantic value and leaves the requestModel parameter 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 and resource: 'Creates a fresh presigned upload URL for an ALREADY-REGISTERED evidence in a group'. It clearly differentiates from siblings by specifying step 2 of the register-then-upload flow, noting that evidence_create_sealed automates the whole flow. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use: 'Use when the URL from evidence_group_evidence_register expired or was lost.' It also mentions an alternative: 'evidence_create_sealed does all of this automatically,' which effectively tells the agent when not to use this tool and choose a higher-level wrapper instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about tenant-wide scope and intended use cases without contradicting annotations. It does not detail pagination behavior or output format, but annotations cover 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-load the primary action and scope, then follow with usage intent and an alternative. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested filter schema and the presence of an output schema, the description covers the essential context: what it searches, scope, use cases, and alternative. It omits detailed parameter explanations, but for a search tool this is adequate.
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 mentions 'state, dates, pagination' as optional filters, but the filter object includes many more fields (id, hash, groupId, status, etc.) that are not described. This provides some semantic hints but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches evidences across the tenant with optional filters, and explicitly distinguishes it from group-scoped searches by noting 'not scoped to one group' and referencing evidence_group_get. This provides a specific verb plus resource and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use to find an evidenceId or audit what exists') and when not to, naming the alternative tool ('for one group's content use evidence_group_get instead'). This is strong practical 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 only provide readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description carries the burden of explaining behavior. It discloses the 2-step nature of the report flow, the prerequisite state of notifications, and that the tool returns a reportId. This is useful behavioral context, though it does not mention side effects like duplicate report creation or whether generation is asynchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. Each sentence contributes meaning: what it does, when to use it, what prerequisites are needed, and what to do with the result. No filler or redundant content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers purpose, prerequisites, parameter provenance, and the follow-up step, while an output schema exists for return values. It is not fully complete because some parameters and edge behaviors are unaddressed, but it provides enough context for an agent to invoke the tool correctly in the intended workflow.
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 only 29%, so the description must compensate. It explains the source and purpose of requestId and notificationIds, and notes that notificationIds can be one or more. However, it does not clarify template, languageCode, additionalData, or embedAttachmentsEnabled, which remain unexplained despite being required or optional 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 'generates a delivery-certificate report for one or more notifications on a request', identifying the specific verb, resource, and scope. It also distinguishes itself from the sibling notification_certificate_pdf_url_get by framing the output as a reportId used for a later URL retrieval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing ('Use once notification_request_status shows the relevant notifications have left their in-flight state') and names the prerequisite tools. It also directs the agent to the next step (call notification_certificate_pdf_url_get with the returned reportId), providing clear workflow guidance versus alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this 'triggers generation and returns the result in the same call,' which is a key synchronous behavior beyond the annotations. However, it doesn't detail side effects like whether repeated calls create duplicates or if any state is marked, though annotations already indicate non-idempotent and non-read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage timing/prerequisite, and differentiation from an alternative. Each sentence earns its place, no fluff, with the key information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 1-param schema with an output schema and all-false annotations, the description covers the essential context: when to use it, what it returns, and how it differs from another approach. It doesn't explain domain-specific 'well-signed' or failure modes, but that's minor for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter signatureRequestId is 100% covered by the schema description ('MANDATORY. UUID... Obtain from create_signature_request'). The tool description repeats the prerequisite but adds no new semantic detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Generates the well-signed appearance certificate document for a signature request.' It clearly identifies the action and object, and the final sentence contrasts this tool with EAD Enterprise's GET-based equivalent, distinguishing it from related generation/polling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use once every signatory has signed (check with get_signature_request).' It names the prerequisite chain 'create_signature_request → signatureRequestId' and provides an alternative comparison, giving clear context for when this tool is appropriate.
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 destructiveHint=true, but the description adds 'Permanently deletes' and 'not reversible', reinforcing finality. It also adds a practical warning to confirm IDs first, which goes beyond the structured annotations. 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 sentences, front-loaded with purpose, then critical warnings and alternatives. Every sentence provides necessary information with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully addresses the tool's use case: what it does, its irreversibility, how to confirm inputs, and a safer alternative. It is complete for a destructive bulk-delete operation with two 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 covers requestId with description and ids with format and constraints; description maps 'ids' to 'caseFileIds' adding semantic context. However, it doesn't explain parameter behavior beyond what the schema already provides (e.g., max 100 items, UUID format). Coverage is 50%, and description partially compensates.
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 ('deletes') and resource ('case files') with a clear scope ('SEVERAL... in one call'). It explicitly distinguishes from siblings by emphasizing bulk deletion and permanence, and names the alternative tool for closing case files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (permanently delete several case files), when-not-to-use (prefer status update for ending work), and a prerequisite (confirm IDs via evidence_case_file_search). This is model guidance for tool selection.
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 destructiveHint=true and readOnlyHint=false, and the description reinforces 'Permanently deletes' and 'Destructive.' It adds behavioral context about sealed content and the 'no group path needed' distinction, going beyond 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 sentences, front-loaded with purpose, then caution and prerequisite. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with strong annotations, the description covers purpose, usage constraints, prerequisites, and destructive nature. No output schema exists but none is needed for a delete operation; the description is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description of the evidenceId parameter, so the baseline is 3. The description repeats how to obtain the ID and adds 'no group path needed' context, but does not add substantial new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+scope: 'Permanently deletes one evidence by evidenceId (no group path needed).' It distinguishes from siblings like evidence_group_evidence_delete by explicitly noting no group path is required, and from bulk operations by saying 'one evidence.'
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?
Clear when-to-use and when-not-to-use guidance: 'sealed content should not be deleted — use only for drafts or mis-registered evidence.' Also specifies prerequisite: 'Requires: evidence_group_evidence_register or generate_evidence → evidenceId.'
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 carry little weight (all false), so the description must disclose behavior. It does so by noting the caller-supplied id (non-idempotent), the returned status 'OPEN', and the sequencing with other tools. However, it omits details like error conditions or side effects, but the provided operational flow is valuable.
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 somewhat long but each sentence adds value, including a concrete example and workflow steps. It is front-loaded with the core purpose and then provides operational details, though it could be slightly more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (not shown but indicated), the description gives sufficient context: creation context, prerequisite, example, and next steps. It doesn't fully explain all return values, but the essential lifecycle is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 13%, and the description compensates by explaining the required parameters: id ('generate a fresh UUID v4 yourself'), caseFileId (from evidence_case_file_create), and type (example 'FILE'). It doesn't explain optional parameters like name or metadata, but the mandatory ones are clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates an evidence group inside a case file,' using a specific verb and resource. It distinguishes from siblings by referencing the legacy generate_evidence tool and mentioning evidence_group_evidence_register and evidence_group_close for the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when starting a new batch of related evidence (e.g. all files for one incident).' It also gives prerequisites (evidence_case_file_create → caseFileId) and a sequential workflow with evidence_group_evidence_register and evidence_group_close, effectively explaining alternatives and 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 and destructiveHint=false, so the safety profile is covered. The description adds valuable context by enumerating the returned elements (status, seal, upload states) and the dependency chain, which is useful beyond the annotations. It doesn't contradict 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 concise sentences front-load the primary action and then provide usage guidance and prerequisites. Every word adds value, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read operation with a rich output schema and complete annotations, the description covers the purpose, content, and usage timing. It also gives the lifecycle context (before/after close) and requires dependencies, making it fully self-contained for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter already describing its purpose and origin. The description's 'Requires' line is mostly redundant with the schema's 'Obtain from' instructions, providing only marginal added meaning about the relationship between the two 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 'Gets one evidence group's details' and specifies the exact content (status, seal information, evidences with upload states). The verb 'Gets' plus the resource scope ('one evidence group') clearly distinguishes this from sibling tools like evidence_group_search or evidence_group_evidence_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides two concrete use cases: verifying all files uploaded before evidence_group_close, and checking the seal after closing. It also gives a prerequisite chain ('Requires: caseFileId + evidence_group_create → evidenceGroupId') that clarifies the expected workflow.
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 a safe read-only, idempotent operation. The description adds the behavioral requirement that the certificate must have been previously generated, providing useful context beyond the annotations, though it does not describe error cases or URL expiry.
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: two sentences, front-loaded with the purpose, followed by the prerequisite. No redundant information, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with a single parameter, strong annotations, and an output schema, the description covers purpose and dependency effectively. It is complete enough for an agent to understand when and how to use it without additional explanation.
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 fully documents reportId as a mandatory UUID, so the baseline is 3. The description adds the semantic provenance of the reportId from notification_certificate_generate, which clarifies where to obtain the value and adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a download URL for a previously generated notification delivery certificate. It uses a specific verb and resource, and distinguishes itself from sibling tools like notification_certificate_generate and evidence_report_pdf_url_get.
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 mentions the prerequisite chain 'notification_certificate_generate → reportId', giving clear context that this tool should be called after generating a certificate. However, it does not explicitly mention alternatives or when not to use it, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false/absent, so the description carries the full burden. It discloses that activation sends notifications and permanently prevents adding documents or signatories, which is critical behavioral context beyond the annotations. It also implies the mutation side effects (irreversible lock).
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 dense but not bloated; it front-loads the core action and then adds necessary workflow context. Every sentence contributes value, though it could be slightly more concise given the density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full operational context: required prior steps, the effect of activation (notifications sent, lock on additions), and a recommended alternative (signature_request_full). With an output schema present, not explaining return values is acceptable, and the description is complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (signatureRequestId), and the schema already explains it is a mandatory UUID obtained from create_signature_request. The description repeats this requirement but does not add new parameter-level semantics beyond the schema, so it meets the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activates a signature request, sending signing notifications to every added signatory') and the resource. It distinguishes from siblings by noting the post-activation lock (no more documents or signatories can be added) and by referencing alternative tools for adding roles before activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: prerequisites (create_signature_request → signatureRequestId, documents with bytes uploaded, signatories per document) and alternatives (add_validator_to_signatory / add_observer_to_document before activating; prefer signature_request_full for a new request). This clearly differentiates when to use this tool vs siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to supplement. It adds the temporary-URL nature and equivalence to the sibling endpoint, which is useful, though it omits expiration details.
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 contain the action, scope, prerequisite, and alternative without filler. The sentence structure front-loads the core purpose and places supporting details afterward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with strong annotations and no output schema, the description covers purpose, prerequisites, and sibling differentiation. A minor gap is the lack of URL expiration or response format, but this is not essential for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents evidenceId, and the description adds practical context: it is the sole identifier required (no group path) and can be obtained from generate_evidence or evidence_group_evidence_register. This complements the schema rather than repeating it.
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-resource pair: 'Creates a temporary download URL for an evidence's stored file.' It also clearly distinguishes itself from the sibling evidence_group_evidence_download_url_create by noting 'no group path needed' and 'same bytes.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('when you only hold the evidenceId'), names the alternative for the group-path case, and provides the prerequisite evidence-generation flow. This gives the agent clear decision boundaries.
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 are all false, so the description carries the burden. It discloses key behavioral traits: this tool only registers metadata, not the file bytes, and should be used before activating. It also reveals the two-step sequence (register then get upload URL). However, it does not discuss error handling, whether registrations are additive, or idempotency behavior (consistent with the false idempotentHint).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each with a distinct purpose: first defines the operation, second states when to use it, third clarifies what it does not do and directs to the complementary tool. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the what, when, and sequencing. The output schema likely covers return values (not shown). It lacks explicit mention that the request must be in draft state, though 'before activating' suggests it. Overall, an agent can correctly select and invoke the tool with this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only requestId has a description). The description adds meaning by specifying that requestId comes from notification_request_create and identifies the hash as SHA-256. It also frames attachments as 'fileName + hash'. It does not explain optional fields like fileId or fileSize, but the schema provides their types and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'registers' and identifies the resource as 'document attachments (metadata only — fileName + SHA-256 hash) on a draft notification request'. It clearly distinguishes itself from the upload tool by stating 'metadata only' and referencing notification_document_upload_url_create for actual byte uploads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit timing ('Use once per batch of documents before activating'), a prerequisite ('Requires: notification_request_create → requestId'), and an alternative/exclusion ('call notification_document_upload_url_create for each registered attachment to get a URL to PUT the actual file bytes to').
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?
Beyond the annotations (which only say it's a non-read, non-idempotent write), the description discloses that it creates a draft rather than an active request, and explains the activation behavior tied to autosend. It also tells the caller what the response returns (requestId plus per-receiver notificationIds), adding return-value context not present in structured fields.
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?
Four focused sentences, front-loaded with purpose, and every sentence adds workflow or return-value information. No filler or repetition of schema details.
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 high-complexity tool with a large nested schema and minimal schema descriptions, the description gives the essential workflow context (first call, no prerequisites, autosend choice, response shape). However, it omits details about the required `language` and provider/`data` structure, so it's not fully complete on its own.
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 only 17%, and the large nested `data` object is not described. The description does add useful semantics for `autosend` (immediate send on first batch activation or add receivers/documents before sending) and mentions inline receivers, but it does not compensate for the many undocumented parameters like `language`, `content`, `metadata`, or the provider-specific objects.
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 ('Creates') and resource ('notification request (draft)'), framing it as the top-level container in the certified-notification flow. It explicitly positions the tool as the first step, distinguishing it from sibling tools like notification_receiver_add, notification_document_add, and notification_request_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'Use this first, before any other Notification-manager tool' and 'No prerequisites,' giving explicit temporal placement. The autosend guidance explains when to set true vs false and directs the agent to call notification_request_send for the manual path, which contrasts with the sibling send 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 and destructiveHint=false, so the safety profile is covered. The description adds that 'no credentials needed' and that it serves as a discovery/guidance tool, which is useful contextual information beyond the structured fields.
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 ('Returns an overview'), and every phrase earns its place. It covers contents, usage, and access requirements without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no params and no output schema, the description is the sole source of guidance. It fully explains what the tool returns (managers and key tools), when to use it (first if unsure), the key decision guidance (composite vs. atomic), and access requirements (no credentials). This is complete for a help tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which is the baseline for a score of 4. The description does not need to explain parameter semantics because the schema has no properties, and the 100% schema coverage means there is nothing to add.
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 an overview of EAD Factory's managers' with specific verbs and resources, listing the manager types (Evidence, Signature, Notification, Chat) and the guidance it provides. This distinguishes it from the many sibling tools that perform domain actions rather than providing help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Call this first if you're unsure which tool to use' and mentions guidance on composite vs. atomic tool selection (e.g., evidence_create_sealed). This gives clear when-to-use direction and differentiates its purpose from the operational siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which are all false), the description discloses that the API does not auto-assign an id, requiring the caller to generate a UUID v4, and that 'title' is used instead of 'name.' It also reveals the relationship between the created case file id and subsequent evidence_group_create calls, adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that lead with the core purpose, then provide usage ordering and the unique id rule, ending with a practical example. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role as the top-level entry point, the description covers the essential context: what it creates, when to use it, its key parameter quirks, and how it connects to the next logical tool (evidence_group_create). The presence of an output schema means return value details are handled elsewhere.
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?
With schema description coverage at 0%, the description compensates by fully explaining the critical 'id' parameter (caller-generated) and the 'title' parameter (replaces name), and provides an example. Other optional parameters (code, owner, category, metadata, description) are not detailed, but their purposes are inferable from their names and the overall context.
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 'Creates a new case file — the top-level container for evidence groups, evidence, and reports,' clearly stating the verb and resource. It also distinguishes this from sibling tools by noting it is the entry point to the Evidence-manager toolset and highlighting the caller-supplied id quirk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Use this first, before any other Evidence-manager tool' and states 'No prerequisites.' The description also clarifies when not to expect typical create behavior (id is caller-supplied, no name field) and gives a concrete example that ties into evidence_group_create.
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 beyond annotations: it mentions the signed document nature, the required prior generation step, and the scope of what is returned. 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 tightly packed sentences: the first states the purpose, the second covers prerequisites and alternative. No redundant words, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (2 required params, read-only, output schema present), the description covers all essential context: what it retrieves, the required sequence, and the alternative for broader needs. No gaps for the agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning by specifying that reportId is obtained from the generate step, complementing the schema's existing origin note for caseFileId. This provides the causal chain for parameter 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 clearly states the tool's function: retrieving a download URL for a signed PDF document of a case-file report. It distinguishes from the sibling tool evidence_case_file_report_zip_url_get by specifying it returns only the signed PDF, not the full evidence package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite chain: evidence_case_file_report_generate must be called to obtain the reportId. Also provides a clear alternative (use evidence_case_file_report_zip_url_get for the full package), guiding when not to use 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 indicate a non-read-only mutation. The description adds a key behavioral consequence: CLOSE means no longer accepting new evidence groups. It does not contradict annotations and enriches the state-change semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then usage guidance and prerequisite. Every sentence contributes meaningful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter status update with annotations and no output schema, the description covers purpose, usage, key behavioral effect, and parameter provenance. It is fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema documents caseFileId with a description and source, but status is a bare enum. The description explains the meaning of each status value ('CLOSE' vs 'OPEN'), adding semantic value that the schema lacks.
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 ('Changes') and resource ('case file's lifecycle status'), with explicit values (OPEN/CLOSE). This distinguishes it from sibling tools like evidence_case_file_update, which handle general updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context ('Use CLOSE when work is finished... reopen with OPEN') and a prerequisite chain ('Requires: evidence_case_file_create or evidence_case_file_search → caseFileId'). This clearly guides an agent on invocation and 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 readOnly/idempotent/non-destructive, and the description adds useful context: the resource is a signed PDF, the returned URL is the same as the sibling tool's, and prior generation is required. This goes beyond 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 do exactly what is needed: front-load the purpose, then provide conditions, sibling distinction, and prerequisite. No filler or redundant phrasing; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, full annotations, and an output schema, the description fully covers purpose, usage, and prerequisite. The tool is simple enough that no additional behavioral or return-value details are 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?
Input schema fully covers the parameter (reportId as required UUID). The description adds semantic meaning by clarifying that only reportId is needed and linking it to the generate step, which enriches understanding beyond the schema's format and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a download URL for a report's signed PDF using only reportId, and explicitly distinguishes it from the sibling evidence_case_file_report_pdf_url_get by noting that no caseFileId is needed and that it returns the same document. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage conditions: use when holding only reportId, with no caseFileId required. It names the alternative sibling and states the prerequisite chain evidence_case_file_report_generate → reportId, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnly, idempotent, etc.), so the description carries the disclosure burden. It explains the bounded-polling task behavior, the lack of upstream events, per-receiver failure reporting, and the requirement for MCP Tasks support—far beyond basic annotation info. No 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?
Though long, every sentence earns its place: main action, task mechanics, prerequisites, completion behavior, client requirement, alternatives, cross-reference. It's dense and well-structured with no fluff, front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (MCP task, failure handling, client constraints), this description covers all necessary context: what triggers, what it requires, what happens on completion, what to do without Tasks support, and which sibling to use for status. With no output schema, it even describes the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: requestId is fully described with format and provenance. The description reinforces it ('Requires: notification_request_create -> requestId') but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Activates a notification request, triggering delivery to every added receiver.' It clearly distinguishes from siblings like notification_request_create (creates), notification_request_status (checks status), and notification_receiver_add (adds receivers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit prerequisites are given (notification_request_create for requestId, notification_receiver_add for receivers). It also provides alternatives for clients without Tasks support (use autosend:true and poll status), and points to notification_request_status for progress checking. This is model usage 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it only returns the link 'once every signatory has signed' and requires confirmation of signing completion, which is a state precondition. This goes beyond the basic safety profile and clarifies the operation's dependency on signatory completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: purpose, prerequisites, and disambiguation. It is front-loaded with the core action and contains no fluff or redundant information, maximizing information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and that an output schema exists, the description sufficiently covers purpose, usage, preconditions, and differentiation from similar tools. It does not need to explain return values because the output schema handles that, and the provided context is complete for a download-link retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds further meaning by mapping each parameter to its source: 'create_signature_request → signatureRequestId, add_document_to_signature_request → documentId'. This explains provenance and prerequisite, which is more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieves the download link for the FINAL, well-signed version of a document'. It uses a specific verb ('Retrieves') and resource ('download link'), and distinguishes it from the sibling 'signature_certificate_generate' by explicitly noting the certificate is not the signed document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing: 'Requires: create_signature_request → signatureRequestId, add_document_to_signature_request → documentId' and instructs to 'Use get_signature_request first to confirm signing is complete before calling this'. It also clarifies when not to use it by contrasting with signature_certificate_generate, giving clear usage versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates non-read-only (readOnlyHint=false) but no destructive flag. The description goes beyond annotations by revealing the async state machine (OPEN → CLOSING → CLOSED), the need to poll evidence_group_get, and the irreversible consequence ('no more evidence can be added'). This adds valuable behavioral context not present 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 description is information-dense but every sentence earns its place: main action, precondition, required inputs, async behavior, and alternative tool. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (state transitions, prerequisites, async polling), the description covers all essential aspects: what happens, when to use, what to do after invocation (poll until CLOSED), and a simpler alternative. The presence of an output schema reduces the need to explain return values, so this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only caseFileId and evidenceGroupId have descriptions). The description adds meaning for evidencesCount as 'the current evidencesCount' and explains the provenance chain for the IDs. However, collectMetadata is not mentioned at all, leaving its semantics unexplained. Overall, the description partially compensates for the schema gaps.
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: 'Seals (closes) an evidence group, triggering qualified timestamping — after this, no more evidence can be added.' This is a specific verb+resource and distinguishes from siblings like evidence_group_discard or evidence_group_update by emphasizing the sealing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage conditions are given: 'Use only after every evidence registered in the group has had its file bytes uploaded to the presigned URL from evidence_group_evidence_register.' It also names an alternative ('Prefer the evidence_create_sealed composite tool') and lists required dependencies, providing clear when-to-use and when-to-avoid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds substantial context: the deletion is permanent, the signed document and package stop being downloadable, and the underlying case file/evidence are unaffected. This goes far beyond the structured safety hints and sets proper expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning their place: purpose, destruction consequence, prerequisite, and scope boundary. No filler or redundancy; critical information is front-loaded and clearly structured.
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 simple delete tool with one parameter, the description covers all essential context: what is deleted (report), what becomes unavailable (downloadable document and package), what is required (prior generation), and what is not affected (case file and evidence). Combined with the annotations (destructive, idempotent), the agent has full situational awareness.
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 provides 100% coverage with reportId described as 'MANDATORY. UUID of the report.' The description adds provenance by linking reportId to evidence_case_file_report_generate, telling the agent where to obtain a valid ID. This is a meaningful addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Permanently deletes a generated report by its reportId.' This clearly distinguishes it from sibling report tools like pdf_url_get or zip_url_get, and from case-file deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'Requires: evidence_case_file_report_generate → reportId.' It also declares a clear boundary: 'The underlying case file and its evidence are NOT touched.' This tells the agent when to use the tool and what it will not do, effectively guiding against misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers. It discloses the polling until CLOSED, the async Task for MCP clients vs synchronous result for others, the requirement for caseFileId, the file input contract variants, and the return shape (group id, CLOSED status, evidence ids + sha256). This goes well beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It opens with the primary purpose and flow, then gives key behaviors, requirements, and alternative use cases. No filler words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested file contracts and multiple parameters, but the description covers prerequisites, use modes, async behavior, return values, and when to choose alternatives. Since there is no output schema, explaining the return fields is essential and done well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds semantic value: it explains the shared FileInput contract (local path, base64, HTTPS URL, n8n binary item) and clarifies parameter interplay (evidenceGroupId to add to existing OPEN group, groupName/groupType only used when creating a new group). This helps the agent construct valid calls.
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 full action: creates/reuses an evidence group, registers and uploads files, then seals it. It explicitly distinguishes itself from the atomic sibling tools (evidence_group_create, evidence_group_evidence_register, evidence_group_close) by framing it as the 'full flagship evidence flow in one call.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: use the atomic tools when you need to inspect/react to intermediate steps, and this tool for the full flow. It also states the prerequisite (case_file_create -> caseFileId), the ability to add to an existing OPEN group, and explains the asynchronous vs synchronous behavior for different client types.
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?
Beyond the annotations (readOnlyHint=false, etc.), the description reveals the 2-step upload flow, defines custodyType INTERNAL/EXTERNAL, explains testimony providers TSP/DLT, and notes prerequisites for hash computation. This provides rich behavioral context the annotations do not capture.
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 dense yet organized, front-loading the core purpose and then using pipes and clear separators for enum semantics. Every sentence adds non-redundant, actionable information, making the length justified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and critical workflow interactions, the description covers prerequisites, the 2-step upload process, custody/proof semantics, and a warning about evidence_group_close. Combined with an output schema for return values, this is complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 19%, but the description compensates by defining the hash as SHA-256, explaining custodyType enum meanings, and detailing testimony provider options. It also clarifies how to obtain key IDs (evidenceGroupId, caseFileId, evidenceId), adding meaning beyond the spartan schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Register a new evidence in a group' with a specific verb and resource, and clarifies it is the first step of a 2-step upload. This clearly distinguishes it from siblings like evidence_group_evidence_get/delete and evidence_create_sealed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for each file you want to add to an OPEN evidence group' and names an alternative (evidence_create_sealed composite tool). Also warns not to call evidence_group_close until uploads complete, giving clear when-to-use and constraint information.
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:

[![EAD-Factory-MCP MCP server](https://glama.ai/mcp/servers/g-digital-by-Garrigues/EAD-Factory-MCP/badges/card.svg)](https://glama.ai/mcp/servers/g-digital-by-Garrigues/EAD-Factory-MCP)

Score Badge

Copy to your README.md:

[![EAD-Factory-MCP MCP server](https://glama.ai/mcp/servers/g-digital-by-Garrigues/EAD-Factory-MCP/badges/score.svg)](https://glama.ai/mcp/servers/g-digital-by-Garrigues/EAD-Factory-MCP)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/g-digital-by-Garrigues/EAD-Factory-MCP'

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