Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It transparently describes the input-to-output transformation, sorting, and pretty-printing. It does not mention overwriting an existing output file or error behavior, but the 'fresh snapshot' phrasing implies regeneration, making this a solid but not exhaustive disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with no filler. The core transformation is front-loaded, and the usage guidance is a natural second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two optional parameters and no output schema, the description covers the essential context: input format, output format, sorting, and when to run it. Minor details like return value and overwrite behavior are absent but not critical for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter names plus default-value descriptions make the meaning of jsonlFile and jsonFile clear enough. The description adds no further parameter-specific semantics, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation: read a JSONL file and write a sorted, pretty-printed JSON array. It adds meaningful details like 'one entry per line' and clearly differentiates this post-processing tool from the crawl/search siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear timing guidance: run after a crawl finishes or whenever a fresh snapshot is needed. It does not explicitly discuss alternatives or exclusions, but the tool's role is unambiguous enough that no direct sibling competes with it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the operation is read-only ('Reads... reports'), and notes it is independent of any in-memory job, which is a key behavioral trait. While it does not detail error handling or file-missing behavior, the read-only nature is clearly implied by the verb and the context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no waste. The core function and output are stated first, followed by a practical use case. It is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool returns (entry count and highest id), which effectively covers the output since there is no output schema. It also provides the primary use case and notes independence from in-memory state. Minor gaps like error conditions or file assumptions are not critical for a simple read tool with one optional parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100% for the only parameter (outFile), which already specifies its default. The tool description does not add any additional meaning about the parameter beyond what the schema provides. Since the schema fully covers it, the description adds no extra value here, matching the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a JSONL dataset file from disk and reports entry count and highest id fetched. It explicitly distinguishes itself from in-memory operations and names a specific use case (checking progress after server restart), which differentiates it from sibling tools like islamweb_crawl_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear context of when to use it ('after restarting the MCP server to see how far a previous crawl got'). It does not explicitly mention alternatives or when not to use it, but the stated scenario is specific enough for an agent to understand its primary purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return contents (done/total/failed) and the relationship to start_crawl, which is useful, but it does not explicitly say whether the call is read-only, how current the data is, or what happens for unknown or expired job IDs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It states the return value and the relevant source tool immediately, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter status tool with no output schema, the description is largely complete: it names the return fields and the origin of the jobId. It does not repeat the optional omit behavior from the schema, which is acceptable, but it could briefly mention that omitting jobId lists all jobs to be fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents the single jobId parameter, so the baseline is 3. The description adds value by linking the jobId to a crawl job started with islamweb_start_crawl, clarifying where the ID comes from and how it should be used beyond the schema's 'omit to list all known jobs' note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns progress counts (done/total/failed) for a crawl job tied to islamweb_start_crawl, giving a specific verb, resource, and scope. It does not explicitly distinguish itself from the sibling islamweb_crawl_stats, though the phrasing implies a job-specific status check rather than aggregate statistics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it: after starting a crawl with islamweb_start_crawl, to check that job's progress. This is clear contextual guidance, but it does not explicitly state when not to use it or point to an alternative like islamweb_crawl_stats for different needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must bear the full burden of behavioral disclosure. It states that the tool fetches and parses content, and lists the return fields, which conveys the core action. However, it does not explicitly confirm that the operation is read-only, describe error handling, mention rate limits, or note any authentication requirements. This is adequate for a simple fetch but lacks explicit safety and side-effect disclosures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with no redundant words. It front-loads the purpose ('Fetches a single content page'), includes the URL for clarity, and lists the output fields. Every element contributes to the agent's understanding, making it concise and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter fetch tool with no output schema, the description provides sufficient context: it identifies the resource, the input parameters' role, and the structure of the output (fields). It does not specify data types for the returned fields or cover error scenarios, but these are minor gaps for a straightforward retrieval operation. The description is complete enough for correct tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters (bookId and id) with examples. The description merely repeats the URL pattern that references these parameters, adding no new semantic meaning. This meets the baseline of 3 but does not enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Fetches') and a clear resource ('a single content page from islamweb.net's library') with a concrete URL template. It also enumerates the exact JSON fields returned, distinguishing it from siblings like islamweb_start_crawl (which initiates crawls) and islamweb_search (which searches). This makes the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no explicit guidance on when to use this tool versus any alternative. It does not mention that it should be used for retrieving a specific page by ID, nor does it contrast with sibling tools or state prerequisites. Usage context is only implied by the tool name and description, leaving an agent to infer applicability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that the tool returns known bookId, id range, and server paths, which is helpful. However, it doesn't describe whether this is a read-only operation, whether it performs any network calls, or what the exact response format looks like. The description is honest but lacks behavioral depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the key output (bookId and id range) and then adds the dataset paths. Every word earns its place, and it is appropriately sized for a zero-parameter metadata tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter metadata lookup, the description is nearly complete. It tells the agent what it will get back (bookId, id range, paths). The only gap is the lack of an explicit statement about the return format or whether this is a static/local lookup, but given the simplicity of the tool, this is a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, so the schema is trivially complete. The description adds value by explaining what the tool returns (bookId, id range, paths), which is the only meaningful semantic content. With no parameters, a baseline of 4 is appropriate, and the description does a good job of explaining the tool's output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the known bookId and id range for a specific dictionary on islamweb.net, plus the paths used for extracted JSON/JSONL datasets. It names the exact resource (لسان العرب لابن منظور) and the specific data returned, distinguishing it from sibling tools that fetch entries, list dictionaries, or manage crawls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this is a metadata/coordinate lookup tool for a specific dictionary, useful before starting a crawl or fetching entries. It doesn't explicitly state when to use it versus alternatives, but the context signals (0 params, no output schema) and sibling names make the use case reasonably clear. It could be improved by explicitly saying 'use this to get crawl coordinates before starting a crawl.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions the scope (subject 73) and the fact that it returns all dictionaries, which implies a read-only operation, but it does not explicitly state that, nor does it mention error conditions, rate limits, or any impacts. It adds some context but leaves room for improvement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the primary purpose and the returned fields, then adding a relevant usage context. There is no redundant phrasing or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description covers the essential information: the resource, the fields returned, and why it is used (as a registry for crawls). It does not mention pagination or error handling, but for a straightforward list operation this is likely sufficient and not a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the description has no need to explain parameter meanings. The schema is empty, and the description does not need to compensate for any coverage gaps. This is a perfect score per the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly names the resource (dictionaries under islamweb library subject 73) and the exact fields returned (bookId, key, title, author, id range), making it easy to distinguish from siblings like islamweb_fetch_entry (which fetches specific entries) or islamweb_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states that the list is the registry used by the crawl workflow and crawl-all-dictionaries command, implying it is the tool to call when you need to enumerate all available dictionaries. However, it does not explicitly differentiate when not to use it or compare with alternatives like islamweb_lisan_al_arab_info.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses that it performs substring matching (not exact match), searches lemma and text fields, and returns a snippet around the match. However, it doesn't mention case sensitivity, performance implications on large files, or whether the search is limited to a single file. These are useful behavioral details that are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action and return fields, and ends with a clear use case. Every sentence earns its place; 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 3 parameters and no output schema, the description covers the main purpose and return shape but omits details like limit default, case sensitivity, and how the snippet is generated. It's adequate for basic use but not fully complete for an agent that needs to know edge-case behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33% (only jsonlFile has a description). The description adds meaning by explaining that query is a substring and that results include a snippet, but it doesn't clarify the limit parameter's default or behavior, nor does it explain the format of the jsonlFile beyond the default path. The description partially compensates but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs substring searches on a JSONL dataset's lemma and text fields, and returns matching entries with specific fields (id, lemma, chapter, snippet). It also names the use case (spot-check a crawl or look up a word), which distinguishes it from sibling tools like islamweb_fetch_entry or islamweb_list_dictionaries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use it to spot-check a crawl or look up a word, giving clear context for when to use it. It doesn't explicitly name alternatives or say when not to use it, but the use-case framing plus sibling names (e.g., fetch_entry, list_dictionaries) makes the intended usage clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it delivers: it discloses that the call returns immediately with a jobId, that pages are appended as JSON lines to outFile, that it is resumable, and that re-running skips already-present ids. This gives an agent a clear model of side effects and asynchronous behavior without needing extra context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences front-load the core purpose and immediate return behavior, then explain file semantics and defaults. No filler or wasted words; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter tool with no output schema and no annotations, the description covers the essential flow: start, get jobId, poll status, write JSON lines, resume. It does not describe error behavior or the concurrency/delay tradeoffs, but those are secondary given the schema's parameter descriptions and the clear reference to the status sibling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds real value by explaining that bookId/startId/endId/outFile default to a specific dictionary (Lisan al-Arab, bookId 122, ids 1..9305) and that outFile has resumable append semantics. delayMs and concurrency are left to the schema, which already documents their defaults and bounds.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Starts crawling') and resource ('contiguous range of content ids from one islamweb library book'), and immediately distinguishes itself from siblings by noting it runs in the background and returns a jobId for polling via islamweb_crawl_status. This makes the tool's role unambiguous relative to the other crawl-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear context is provided: call this to start a background crawl of an id range, and poll islamweb_crawl_status with the returned jobId. It also explains resumability and defaults, which helps decide when to use it. However, it does not explicitly say when not to use it or name alternatives like islamweb_fetch_entry for single-entry fetches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.