DataCite Librarian MCP

by kaysiz

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources (search, QA, compliance, corpus status). However, get_doi and check_doi_qa both report QA issues (summary vs full breakdown), and export_* tools wrap their base operations, which could cause confusion. Overall, the descriptions are detailed enough to differentiate most tools.
Naming Consistency3/5
Tool names mix verb-first (search_dois, list_clients, export_search_results) with noun-first (facets, repository_health, corpus_status) and some ambiguous names like index_client and diff_partitions_summary. The patterns are inconsistent but readable.
Tool Count3/5
21 tools is on the heavy side for a specialized librarian server. Many tools are variations of reporting/exporting (export_health_issues, export_funder_issues, export_search_results) and status (corpus_status, corpus_inventory, server_info), but the breadth of DataCite functionality justifies most tools.
Completeness4/5
The server covers core analysis needs: search, lookup, QA, compliance, aggregations, and exports. However, there is no direct tool to fetch the full raw metadata for a DOI (only summaries and QA), and no create/update/delete operations, which might be outside scope but could be a gap for some use cases.
Average 3/5 across 21 of 21 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It hints at an output of 'actionable issues' and implies a compliance checking function, but does not explain side effects, permissions, whether it is read-only, or the nature of the output format. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It lacks structure and does not earn its place because it leaves out essential information. The single phrase provides no actionable detail for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters, no annotations, and a minimal description, the tool is grossly incomplete. It does not explain return values (despite an output schema existing), how parameters interact, or what the tool accomplishes in a way an agent can rely on. The description is far too sparse for a tool with this complexity.
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 compensate for five parameters. It only lists domain terms (IDs, awards, licenses, ORCID) without mapping them to any specific parameter or explaining their meaning. No parameter name appears in the description, leaving all parameter semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase rather than a clear verb+resource statement. It indicates the tool relates to funder/award compliance and mentions topics like IDs, awards, licenses, and ORCID, but does not specify what action it performs (e.g., retrieve, validate, check). It also fails to distinguish itself from the sibling tool 'export_funder_issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or situations where another tool (like export_funder_issues) would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose safety and behavioral traits. It only mentions 'streamed metadata,' which hints at a potentially expensive scan, but does not state whether this is read-only, whether it has rate limits, or what side effects (if any) exist. The max_scan parameter's effect is also undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which might seem concise, but it is under-specified rather than efficient. A single fragmentary phrase omits essential details and fails to use the available space to clarify purpose or usage.
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 an output schema exists, the description is incomplete for proper tool selection and invocation. It lacks an explanation of max_scan, does not specify what the returned counts represent, and provides no context about data freshness or operational constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter max_scan with no description, and schema description coverage is 0%. The tool description does not mention max_scan at all, leaving the agent without any semantic understanding of how to set it or what it controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Repository client_id counts from streamed metadata' identifies a resource (client_id counts) and source, but lacks a verb and reads as a noun phrase rather than an action. It vaguely distinguishes from sibling list_funders by mentioning client_id, but does not clarify whether it lists clients, counts them, or both.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_funders or index_client. There are no exclusions, prerequisites, or contextual hints to help an agent choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the output's high-level nature, omitting how counts are computed, whether it scans all records, how top_n affects results, or the response format. This is a significant 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is efficient but under-specified. It lacks a proper sentence structure and essential context, making it more under-specified than concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a tool with no annotations and two parameters. It provides no context about when to use it, its relationship to sibling tools, or behavioral nuances. The output schema exists but does not compensate for this lack of contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter. It adds no meaning about top_n or max_records, failing to compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output: most common subject/keyword strings in metadata. It names a specific resource and implies aggregation, but lacks an explicit verb and does not differentiate from the sibling 'facets' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool over alternatives like 'facets' or how parameters such as top_n and max_records should be configured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Full QA issue breakdown' without clarifying whether the tool performs scanning, what side effects or costs exist, or whether it is read-only. The max_scan parameter hints at scan behavior, but the description does not explain it.
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 description is a single sentence with no fluff, making it concise and front-loaded. However, it is too sparse: it omits crucial details such as parameter semantics and behavioral context, so the conciseness comes at the cost of usefulness.
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 an output schema exists, the description is incomplete overall. It does not explain the tool's operation, the role of max_scan, or when to use it instead of related tools. For a tool with 2 parameters and no annotations, this level of description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameters. It mentions 'one DOI' but does not explain the doi parameter's expected format or the meaning/default of max_scan. This is a significant gap given the optional parameter is wholly undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool provides a 'Full QA issue breakdown for one DOI', which clearly identifies the resource type (DOI) and scope (single DOI). It is more specific than a mere tautology, but it lacks an explicit verb and does not distinguish itself from sibling tools like get_doi or export_health_issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as get_doi, search_dois, or export_health_issues. It only implies usage for a specific DOI's QA issues, with no mention of exclusions, prerequisites, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions exporting to exports/, implying a file-writing side effect, but does not disclose potential file overwrites, authentication requirements, or execution duration. With no annotations provided, the description carries the full burden of behavioral disclosure and falls short.
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 single sentence is compact and well-structured, with no wasted words. While extremely brief, it is not verbose and gets to the point quickly, though the terseness edges toward under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, zero documentation, and no annotations, the description is severely under-specified. The correct output schema exists but does not compensate for missing parameter semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the four parameters (fmt, award_query, max_records, funder_query). Schema description coverage is 0%, so the description was expected to compensate but does not mention any parameter names or meanings.
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: run funder_compliance and export issues to exports/. It distinguishes from sibling export tools by explicitly referencing funder_compliance. However, 'issues' is vague and no scope details are provided, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like export_health_issues or export_search_results. The description only states the action without any contextual cues or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the output. It does not mention whether the operation is read-only, how limit/max_scan affect the scan, or any potential performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, with no wasted words. However, its brevity comes at the cost of omitting essential context, so it earns high marks for conciseness but not a perfect score.
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 two parameters, no annotations, and only a one-line description, the tool is under-specified. The output schema exists, but the description still fails to clarify semantics like what counts as a frequency or how scanning limits apply, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not mention limit or max_scan at all. The parameter names are suggestive, but their effect on the returned frequencies is unexplained, leaving the agent without enough information to set them correctly.
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 that the tool provides funder name/ID frequencies derived from fundingReferences in metadata, specifying a concrete resource and result type. However, it does not explicitly differentiate this from sibling tools like facets or funder_compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only states what it computes, with no mention of suitable contexts, exclusions, or relationships to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It usefully states that results come 'from the CSV index only' and that output includes 'sample rows,' implying the tool does not return all data. However, it does not mention error behavior, return envelope, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no filler; every word contributes. It is not a full sentence and packs little organizational structure, so it misses a top score, but it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, zero schema descriptions, and no annotations, yet the description is one line. It omits parameter semantics and alternative selection guidance, leaving an agent without enough context to invoke it confidently; output schema existence does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain client_id, month, or csv_path. 'One repository's' vaguely maps to client_id, but the optional parameters are completely unaddressed, so the description adds no parameter-level value.
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 names concrete outputs (DOI count, states, prefixes, sample rows) and explicitly scopes to 'One repository' and 'the CSV index only.' It lacks a verb like 'retrieves' but still clearly identifies what the tool provides and distinguishes it from list_clients or index_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over siblings or when not to use it. The phrase 'CSV index only' hints at a data-source limitation, but there is no explicit use case, prerequisite, or alternative mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'streamed' but does not explain what that means for the caller (e.g., streaming results, partial scans, or memory implications). There is no mention of side effects, rate limits, or result format. For a search tool with no safety hints, this is a significant 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 a single, concise sentence with no wasted words. It front-loads the primary verb and resource, then lists filter categories. It is easy to scan and quickly understand the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 optional parameters, no annotations, and an output schema, the description is far too minimal. It does not provide enough context to use the tool effectively without additional exploration. The output schema covers return values, but the description lacks guidance on parameter semantics, usage scenarios, and behavioral nuances.
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 does mention some filters (funder, subject, year, geo) but does not cover important parameters like 'max_scan', 'max_results', 'client_id', 'has_orcid', 'has_funder', 'has_license', and 'resource_type_general'. The mapping of 'title/DOI/description' to the 'query' parameter is implied but not explicit. Many parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching streamed JSONL with filters. It names several filter dimensions (title/DOI/description, funder, subject, year, geo), making the operation concrete. It does not explicitly distinguish itself from siblings like 'get_doi', but the 'streamed JSONL' context and the search verb give reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or comparison with sibling tools like 'export_search_results' or 'facets'. The description implies a search use case but provides no decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description only mentions 'Compare' without disclosing side effects, prerequisites, or whether it affects data. It does not explain what 'loaded JSONL' means or whether the tool is read-only, so the agent is left guessing about behavioral 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?
The description is a single, well-front-loaded sentence with no unnecessary words. It immediately conveys the core purpose in a compact manner.
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 an output schema, the description lacks parameter explanations, usage context, and behavioral details. For a tool with four opaque parameters and no annotations, this one-line description is insufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters (month, csv_path, max_index_rows, max_metadata_scan) are completely undocumented, and the description does not mention any of them. With 0% schema description coverage, the description fails to provide any parameter semantics, making it impossible to know how to set the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares CSV index DOIs to DOIs in loaded JSONL and identifies the output as a coverage gap / what to download next. The verb 'compare' and specific resource distinction make it easy to understand and differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like index_summary or corpus_status. The description implies a use case but does not explicitly state when it is appropriate or when to avoid 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?
With no annotations, the description carries full behavioral burden. It does disclose the specific facets and rates computed, which is useful. However, it omits any details about how counts are aggregated, whether the tool is read-only, performance characteristics, or the meaning of 'rates'. The description adds some context beyond the name but is far from 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 a single, compact sentence that front-loads the core purpose and enumerates key facet dimensions. There is no filler or redundant phrasing. It is concise and well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (which may explain return values), the description remains incomplete for a tool with four optional parameters and no annotations. It covers what the tool computes but not how to control the computation via parameters, when to use it, or what contexts it serves. The gap in parameter semantics alone makes this insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters with zero description coverage, and the tool description does not mention any of them. There is no explanation of top_n, prefix, client_id, or max_records. For a tool with no required parameters and an otherwise generic schema, the description fails to compensate, leaving the agent without clues about how to constrain the facet results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing facet counts for types, years, publishers, languages, and clients, plus ORCID/funder/license rates. This is a specific resource and set of outputs, though it lacks a verb like 'returns' and does not explicitly differentiate from sibling tools like top_subjects or index_summary beyond the listed dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description merely lists outputs, with no mention of conflicting tools, prerequisites, or exclusion scenarios. There is no indication of what types of queries or analysis would benefit from facet counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Regenerate' implies data mutation, but the description does not state whether it is destructive, whether it resets existing data, if it requires special permissions, or what side effects might occur. This is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no wasted words, but it is arguably under-specified for a tool that likely performs a mutating operation. It is front-loaded and efficient, but the brevity borders on terseness, earning a mid-range score.
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 that this is a write/regeneration tool with no annotations, the description is incomplete. It does not explain the impact on existing data, whether the operation is reversible, or what the output represents. The existence of an output schema helps, but the lack of behavioral context leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object with 100% coverage. Per the rubric, 0 params yields a baseline of 4. The description adds no parameter information, but none 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 uses a specific verb 'Regenerate' and identifies the exact resource: 'bundled/demo mock corpus.' It clearly distinguishes this tool from the sibling tools, which are all read/export/query operations. This is a clear action on a well-defined resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or typical scenarios. It is a single imperative sentence with no contextual framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the aggregation behavior but does not mention whether it is read-only, potential performance costs, permissions, or what the output includes beyond the bare hints. This is minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (19 words) and front-loaded with the key verb and resource. It is efficient with no filler, though brevity contributes to under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are defined, but the description remains incomplete for a 4-parameter aggregation tool. It does not cover the meaning of max_records, the scope of aggregation (whole repo vs client), or any operational caveats. The description is too sparse to answer basic usage questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning to client_id and prefix as scope selectors, and 'samples' loosely maps to max_sample_issues. However, max_records is not explained, and max_sample_issues default is not mentioned. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Aggregate') and a resource ('repository QA'), with sub-aspects 'completeness, issues, samples'. This is clear and distinguishes it somewhat from siblings like export_health_issues (export vs aggregate) and coverage_report, but it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only gives a scoping note ('Scope by client_id or prefix'), which is a parameter usage hint, not guidance on when to choose this tool over alternatives. No exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists the scope of output contents but does not state whether the operation is read-only, requires special permissions, or has any side effects. This is minimal transparency for a tool that appears to be a read-only diagnostic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line that front-loads the primary purpose ('Full inventory') and then enumerates the specific aspects covered. Every phrase adds informational value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is not required to detail return values. However, the presence of many sibling tools (corpus_status, coverage_report, etc.) creates a need for usage context that is missing. The description is minimally viable for a simple inventory tool but lacks guidance on when to choose this over other status/summary tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description correctly omits any parameter details, and the empty input schema confirms no parameters need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a full inventory of corpus characteristics (layout type, partitions, CSV/JSONL, capabilities, gaps). The verb is implied via the noun 'inventory' but the colon effectively indicates the tool returns this information. It does not explicitly differentiate from sibling tools like corpus_status or coverage_report, which offer similar summary functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'Full inventory' hints at a comprehensive overview, but there is no mention of conditions, exclusions, or when a more targeted tool would be appropriate. Given the large set of siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Summarize' implies a read-only operation, and 'metadata side' hints that it does not touch data content. However, it does not explicitly state whether this is safe, reversible, or what side effects exist, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is appropriately brief for a zero-parameter tool. It avoids verbosity but could be slightly more structured by adding a clear scope statement. Still, it is compact and focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description does not need to explain return values. However, it lacks context about the intended use case, what 'metadata side' precisely includes, and how it differs from related tools. This makes it minimally complete but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. The description does not need to explain parameter formats or meanings, and the schema already confirms an empty input. The description adds no parameter-specific information, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Summarize') and names the resources ('partitions and part files'), making the core function clear. The qualifier '(metadata side)' adds scope but is somewhat ambiguous and does not explicitly differentiate it from sibling tools like index_summary or corpus_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios, leaving the agent without context on how it fits among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core side effects (running repository_health, writing files to exports/) and the return value, but omits details like file overwriting, performance impact, or prerequisites. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or extraneous words. It efficiently communicates the primary action and output.
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 an output schema, the description is under-specified for a tool with four optional parameters and a filesystem side effect. It lacks parameter meaning, when-to-use guidance, and important behavioral context such as overwrite behavior or prerequisites, making it insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for any of the four parameters (fmt, prefix, client_id, max_records). The phrase 'csv or json' hints at fmt, but the description does not explicitly map this to the parameter, nor does it compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run repository_health'), the resource ('health issues'), and the output ('write to exports/… Returns path'), while distinguishing the tool from sibling export tools by specifying health-issue export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage, but does not explicitly state when to use this tool versus alternatives like export_funder_issues or export_search_results. There are no exclusions or direct comparisons, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention read-only nature, auth requirements, potential side effects, or any limitations. For an info tool, one would expect at least a statement that it is a safe, non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, ultra-compact sentence. Every word is relevant and there is no redundancy. It is front-loaded and immediately understandable.
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 absence of parameters and the presence of an output schema, the description provides adequate context for a simple informational tool. It covers the main content areas (version, paths, env vars, export dir, documentation links), though it does not elaborate on the structure or purpose beyond that. This is 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, giving a baseline of 4. The description adds value by enumerating the categories of information returned, which indirectly explains why no input is needed. This helps the agent anticipate the output scope.
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 is a noun-phrase list: 'Version, paths, env vars, export dir, DataCite documentation links.' While it lacks a verb, it clearly indicates the tool returns server-related configuration and documentation information. It is specific enough to distinguish from sibling tools like 'corpus_status' or 'repository_health', which focus on data or repository state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or exclusions. The description simply lists content areas without explaining the context in which a user would 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does hint at read-only behavior via 'status' and lists what output fields to expect, which is helpful. However, it does not clarify whether it accesses external systems, whether there are any side effects, or how fresh the data is. It also introduces 'capability notes' without explaining what that means. This is some value but not rich 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 a single sentence with a clear, front-loaded subject ('Quick status') followed by a colon and a compact list. Every word contributes meaning, and there is no wasted text. It is appropriately sized for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists (which presumably defines the fields like path and mode), and a status check is a low-complexity operation, the description is mostly complete. It names the distinct output components, though 'capability notes' is left open-ended. The existence of an output schema reduces the need to explain return values, so this is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema coverage burden. The baseline for no parameters is 4, and the description adds no parameter-related details that would be needed. The description's enumeration of output fields is irrelevant to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Quick status' to signal a lightweight overview and explicitly lists the output components (path, mode, partitions, part count, capability notes). It clearly identifies the resource as 'corpus' and distinguishes this as a status tool rather than a detailed inventory or search tool. However, it does not explicitly differentiate it from sibling tools like corpus_inventory or index_summary, which may also provide structural information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when a quick status is preferred over corpus_inventory or server_info, nor does it state exclusions or prerequisites. Usage context is only implied by the word 'quick' but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a key behavioral trait: results are exported to a CSV file under the exports/ directory. However, it omits important details such as whether the file is overwritten, how the output path is named, whether any special permissions are required, and what the function returns (though an output schema exists). This is partially transparent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the action, target, and output. It is front-loaded with the primary verb and contains no extraneous words. This is appropriately concise for a tool with moderate complexity.
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 an output schema, the description leaves significant gaps: parameter meanings are unexplained, the relationship between query/max_scan/max_results is unclear, and there is no mention of file overwriting behavior, what 'summaries' includes, or potential side effects. Given four optional parameters and no schema descriptions, the description is too minimal to be considered complete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (query, max_scan, client_id, max_results). While 'query' and 'max_results' are somewhat self-explanatory, 'max_scan' and 'client_id' remain ambiguous, and the description does not even hint at how they relate to the search/export behavior. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action: 'Search DOIs and export matching summaries to CSV under exports/.' It names the resource (DOIs), the verb (search and export), and the output format/location (CSV under exports/). This clearly distinguishes it from sibling tools like search_dois (which likely does not export) and export_funder_issues/export_health_issues (which export specific issue types).
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 a clear context: use this when you want to search DOIs and produce a CSV export of summaries. It implies this is the tool for file-export tasks rather than in-memory search results, but it does not explicitly state when not to use it or name alternative tools. The context is clear, but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds the 'Default full-corpus scan' trait, which is useful, but it does not discuss permissions, mutability, or performance implications beyond the scan. It provides moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and result. No wasted words; each clause adds information about behavior or output.
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 lookup tool with an output schema, the description covers the core function and a key behavioral default (full-corpus scan). It lacks details on max_scan's precise impact and does not mention any return format, but the output schema covers that. Overall, it is fairly 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 0%, so the description must compensate. It adds meaning to max_scan by stating 'Default full-corpus scan', clarifying the null default. However, the doi parameter is left to the schema, and no explicit parameter details are given. It partially compensates, but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Lookup one DOI') and resource ('in local JSONL'), and mentions it returns summary + QA issues, distinguishing it from search tools like search_dois. It also notes the default full-corpus scan, adding scope specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single DOI lookup, but it does not explicitly state when to use this tool versus alternatives like check_doi_qa or search_dois. No exclusions or alternative references are provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The word 'guide' implies a non-mutating, informational tool, but the description does not explicitly state that it only returns guidance, nor does it mention any side effects, permissions, or limitations. 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 a single, front-loaded sentence that immediately identifies the tool as a guide and lists all relevant audiences. It contains no filler words and is highly 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, zero-parameter informational tool with an output schema, the description is complete. It covers the tool's purpose and the full range of personas it addresses, and the output schema can explain the return structure. No further context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema confirms this. With no parameters, the baseline is 4, and the description correctly focuses on the tool's purpose rather than parameter details. No additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a persona-oriented guide and specifies the target audiences (librarians, RDM, funders, ops, research, teaching). It is distinct from the sibling tools, which are operational actions like exports and searches. However, it lacks a strong action verb, reading more as a noun phrase than a clear verb+resource statement.
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 'which tools for librarians, RDM, funders, ops, research, teaching' directly implies when to use this tool: when the user identifies with one of those roles and needs tool recommendations. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for a guide with no comparable siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description self-discloses return content ('Returns totals, states, top clients/prefixes'), input schema ('doi/state/client_id/updated'), and date format. It does not mention edge cases or parameter limits, but for a read-only summarization tool this is adequate behavior 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 four sentences, front-loaded with the verb and resource, and every sentence adds practical value. There is 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?
An output schema exists, so return values need no description. The description covers input selection, invocation formats, and ideal use cases. Missing parameter semantics for two fields is the only gap, but overall the tool is well specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully specifies month format ('YYYY-MM (e.g. 2026-06)') and csv_path ('relative/absolute'), but omits top_n and max_rows semantics, leaving half the parameters undocumented.
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 'Summarize a monthly CSV index,' giving a specific verb and resource. It further lists the exact outputs ('totals, states, top clients/prefixes') and differentiates from siblings with 'Works without JSONL,' making the tool's role unmistakable.
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 clear when-to-use context: 'Works without JSONL — ideal for large months when you only have the index.' It also gives two alternative input methods ('Pass month as YYYY-MM or csv_path'). It stops short of explicitly naming alternatives or when-not-to-use scenarios, so not a 5.
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:

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

Score Badge

Copy to your README.md:

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

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/kaysiz/mcp-test'

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