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

Annotations already convey read-only, idempotent, non-destructive behavior, so the description adds only the 'compact, citation-centered' return characteristic. It omits details like not-found behavior, but the presence of an output schema lowers the burden on the description.

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?

A single front-loaded sentence states the operation, scope, key output characteristic, and required identifier without any filler. Every word 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 one-parameter read-only fetch with a robust annotation set and an output schema, the description is adequate. It could add a note about the behavior when no activity matches, but that is a minor gap given the structured context.

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?

With 0% schema description coverage, the description is the only place explaining the parameter: it identifies activity_id as an OSIRIS ID that must match exactly. This adds real semantic guidance beyond the bare schema type 'string'.

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 ('Get') and a precise resource: one activity selected by its exact OSIRIS ID. The qualifiers 'compact' and 'citation-centered' distinguish it from search_activities and list-style siblings, so an agent can tell which tool to call.

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 makes the triggering condition explicit: the caller must already have an exact OSIRIS ID, and the tool returns a single result. It does not explicitly name search_activities as the alternative for fuzzy lookup, but the exact-ID condition is clear enough context.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds no additional behavioral context, such as what kind of metadata is returned or how it relates to other tools, so it only minimally complements the annotations.

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

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

The description is a single short sentence with no filler. It front-loads the tool's purpose and each phrase ('OSIRIS instance', 'features', 'supported filters') adds meaningful information.

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 zero parameters, rich non-destructive annotations, and an output schema, the description is sufficient for safe invocation. Any ambiguity about what 'supported filters' means is resolved by the output schema, so nothing essential is missing.

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?

With zero parameters, the schema fully covers inputs, so the baseline of 4 applies. The mention of 'supported filters' is informative even though no parameters exist, since filters appear to be part of the returned output rather than accepted arguments.

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 ('Describe') and resource ('this OSIRIS instance'), and mentions features and supported filters. However, it does not explicitly distinguish itself from the sibling server_info, so it is clear but not fully differentiated.

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 context: call this tool to learn about the current OSIRIS instance, its features, and supported filters. It does not state exclusions or name alternatives like server_info, so it misses the explicit when-not guidance of a 5.

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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: 'exact' signals a strict key-based match rather than fuzzy searching, and 'compact' tells the agent the returned profile is deliberately summarized. This is meaningful supplementary 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 a single well-constructed sentence with no filler. It front-loads the action and resource, then states the exact lookup criterion. Every word contributes to the agent's understanding.

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 one-parameter, exact-key lookup with rich annotations and an output schema, the description is complete. It covers what the tool returns at a high level ('one compact research profile'), how to look up the person ('exact OSIRIS username'), and the annotations handle safety and consistency concerns. No critical information is missing for selecting or invoking the tool.

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 gives no description for person_id and coverage is 0%, so the description must compensate. It does so by establishing that person_id is an OSIRIS username and must be exact, which is the key semantic needed to construct a valid call. It does not provide format examples or case-sensitivity details, but for a single parameter this is sufficient.

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 ('Get'), a specific resource ('one compact research profile'), and a precise lookup method ('by exact OSIRIS username'). This clearly differentiates it from sibling search tools like search_people or search_experts, which imply fuzzy or broader lookups.

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 phrase 'exact OSIRIS username' gives clear context for when the tool is appropriate: the caller already knows the precise identifier. It stops short of explicitly naming search_people or search_experts as alternatives for partial or name-based queries, so it loses a point for not stating exclusions.

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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: the response is limited to 'allowlisted details' and the operation returns exactly one project. However, it does not clarify what 'allowlisted' means or how it is determined.

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 one tight sentence with no filler. It front-loads the verb and noun, then immediately specifies the lookup key ('by project ID') and the scoping trait ('allowlisted details'). Every word 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 simple one-parameter read-only tool with an output schema and rich annotations, the description is nearly complete. The only gap is that 'allowlisted details' is left unexplained, but given the output schema likely defines the exact fields, this is a minor omission. An agent can successfully invoke the tool with the information provided.

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 has 0% coverageaint of the parameter description, so the description must compensate. It does state the operation is 'by project ID', which clarifies the parameter's role, but it adds no new meaning beyond the schema's 'project_id' title and type. It lacks format guidance, examples, or source of the ID, so it only partially compensates for the coverage gap.

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 ('Get'), a specific resource ('one OSIRIS project'), and a clear retrieval mode ('by project ID'). It also adds a distinguishing detail ('allowlisted details') that separates it from sibling tools like search_projects. This leaves no ambiguity about what the tool does.

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

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

The description clearly implies the tool is for fetching a single, known project by ID, which gives an agent a solid context for when to use it. It does not explicitly name alternatives or exclusions, such as 'use search_projects when you do not have an ID', so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds modest context by emphasizing 'exact' and instance-specific IDs, but does not disclose additional runtime behavior such as pagination or ordering. No contradiction exists.

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

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

The description is a single, tightly scoped sentence with no filler. It front-loads the action and precisely states what is returned.

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 zero parameters, strong annotations, and an output schema, the description fully covers what an agent needs to invoke this tool correctly. It clearly communicates the purpose and the instance-specific nature of the returned IDs.

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 zero parameters, so parameter documentation is unnecessary. The baseline of 4 applies because there is no parameter semantics gap that the description would need to fill.

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 ('List') and a precise resource ('exact activity category and subtype IDs used by this instance'), making the tool's function immediately clear. 'Exact' and 'used by this instance' distinguish it from generic taxonomy or list tools among the 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 implies the tool should be used when an agent needs the authoritative set of activity category/subtype IDs for the current instance. However, it does not explicitly state when to prefer this over related tools like list_topics or search_activities, leaving the choice to inference.

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?

Annotations already convey readOnly, idempotent, openWorld, and non-destructive behavior. The description adds value beyond those annotations by disclosing that the result explicitly reports whether topics are available for the installation and that pagination is required for completeness. No contradiction with annotations.

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

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

The description is compact and front-loaded: the core action and outcome appear first, followed by routing guidance and pagination details. Every sentence contributes necessary operational context and there is no filler.

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 read-only list/search tool with an output schema and strong annotations, the description covers the key operational aspects: topic ID purpose, installation availability, and pagination. The main gap is precise parameter semantics, but the tool is simple enough that an agent can still invoke it correctly.

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 0%, so the description needed to compensate for limit, query, and offset. It only implies search behavior via 'List or search' and references next_offset without clearly mapping it to the offset input parameter. The description does not explain how query filtering behaves or how limit interacts with pagination, leaving a significant semantics gap.

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 a specific verb-and-resource action ('List or search research topics') and the distinctive output ('return their exact IDs'). It is easily distinguished from sibling tools like list_units and search_projects, and there is no tautology or ambiguity.

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 call this before using the topic project filter unless an exact topic ID was already returned by OSIRIS. It also explains how to paginate to get the complete list with next_offset and has_more, providing concrete guidance for when to use the tool and when it can be skipped.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it returns exact IDs, supports search by name or acronym, and explains pagination semantics with next_offset and has_more.

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 three sentences with no filler. Purpose is front-loaded, usage guidance follows, and pagination instructions conclude. Every sentence adds operational value.

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 read-only search/list tool with an output schema and strong annotations, the description covers all essential agent needs: why to call it, what to search by, when to skip it, and how to retrieve all results. Nothing important is missing.

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 0%, so the description must compensate for the schema's lack of textual parameter explanations. It adds meaning for query by describing it as a human-readable name or acronym, and it references pagination behavior. However, it does not clarify how the limit and offset parameters relate to next_offset, and the reference to next_offset is not an explicit input schema property.

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 opens with a clear verb and resource: "List or search organizational units and return their exact IDs." This is specific and immediately distinguishes list_units from sibling list/search tools by its focus on organizational units and exact ID retrieval.

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 explicit when-to-use guidance: call this before using the unit project filter unless an exact unit ID was already returned by OSIRIS. It also advises searching by human-readable name or acronym and never guessing the ID, plus explains how to paginate for a complete list.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses substantial behavior: default filtering of unaffiliated and online-ahead-of-print records, the server's ability to search verbose source fields without returning them, the non-definitive nature of bibliometric values, and pagination behavior via next_offset and has_more. This goes well beyond structured metadata.

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 compact yet information-dense, front-loading the core purpose before addressing dates, defaults, filters, caveats, and pagination. Every sentence adds operational value, and there is no filler or repetition.

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 13-parameter search tool with no required parameters and an output schema, the description covers the critical ambiguities: date semantics, default exclusions, exact-ID requirements, server-side searching behavior, bibliometric caveats, and exhaustive pagination. An agent has enough context to invoke this tool correctly and interpret results.

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?

With 0% schema description coverage, the description carries the full burden for parameter meaning. It explains date_field values, inclusive date constraints, filter IDs for type/subtype/person/unit/topic, and default/exceptional behavior of include flags. It does not explicitly describe query, limit, or offset, though pagination hints and schema defaults partially fill those 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 opens with a specific verb and resource combination: 'Search activities and return compact, citation-centered evidence.' This clearly identifies the operation and distinguishes it from sibling get_activity and search_people tools by emphasizing evidence-oriented search over a broad activity set.

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 explicit guidance on when to set include flags ('only when the user explicitly requests those exceptional records') and how to interpret date fields ('Use start for activities that began in a period'). It does not name alternatives for tool selection, but it gives enough contextual rules to use the tool correctly.

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?

Annotations already indicate read-only, idempotent, and open-world behavior, but the description adds significant behavioral context: it explains that evidence is provided for each match, that OpenAlex topics are 'lower-priority, clearly labeled evidence,' that general biographies are excluded, and that exhaustive results require following next_offset while has_more. This goes well beyond the annotations and fully discloses the tool's behavior.

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 three sentences, front-loaded with the primary purpose, then adding scoping, exclusions, and pagination. Every sentence adds distinct value with no redundancy or filler. The structure is tight and easy to parse.

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 presence of an output schema, the description does not need to explain return values. It covers what is searched, what is excluded, a conditional behavior, a parameter constraint, and pagination. For a read-only search tool with annotations covering safety, this is complete. Nothing an agent needs to call it correctly is missing.

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 0%, so the description must compensate. It clarifies the 'unit' parameter ('must be an exact ID') and implies the use of offset/limit through the pagination instruction. However, it does not explain the 'query' parameter semantics or the 'limit' parameter's effect/range. While query and limit are reasonably intuitive, the description does not fully cover all four parameters, leaving some burden on the schema-less definition.

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 opens with a specific verb and resource: 'Find active researchers and explain the evidence for each match.' It then enumerates the searched sources (curated expertise, research interests, research profiles, OSIRIS topics) and explicitly excludes 'General biographies,' which distinguishes it from sibling tools like search_people. An agent can clearly identify what this tool does and how it differs from similar search 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?

The description gives clear boundaries: 'General biographies are not searched' and notes the conditional inclusion of OpenAlex topics when Spectrum is enabled. It also provides operational guidance on unit being an exact ID and pagination via next_offset/has_more. While it does not explicitly name alternative tools, the negative scoping and conditional behavior effectively guide when to use this tool. Missing explicit alternatives prevent a 5.

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?

Beyond the annotations (readOnly, idempotent, openWorld), the description adds meaningful behavioral context: it states that results deliberately omit contact details, account roles, login data, biography, and UI settings. It also discloses pagination behavior via next_offset and has_more. This gives the agent a clearer picture of what to expect without contradicting the annotations.

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

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

Three sentences, no fluff. The core purpose is front-loaded in the first sentence, followed by a key distinction, then operational details. Every sentence earns its place and the description stays scannable.

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 is appropriately complete for a search tool with an output schema. It covers the identity-search scope, the unit-filter prerequisite, omitted fields, and pagination. It does not elaborate on limit, offset, or active_only, but these have defaults in the schema and are less critical. Overall, an agent has enough guidance to call the tool correctly.

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?

With schema description coverage at 0%, the description must compensate. It does explain that 'query' accepts a name, username, alias, or ORCID, and that 'unit' requires an exact ID from list_units. However, it does not provide semantics for limit, offset, or active_only, which remain undocumented in the schema as well. The pagination reference (next_offset/has_more) applies to output, not input parameters, so coverage is only partial.

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 opens with a specific verb and resource: 'Resolve a name, username, alias, or ORCID to exact person IDs.' It also explicitly separates this from 'research expertise search,' directly differentiating it from the sibling search_experts. This gives an agent immediate clarity on what the tool does and how it differs from similar 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?

The description provides a clear when-not: 'This is an identity search, not a research expertise search,' steering agents away from search_experts. It also tells the agent that the optional unit filter requires an exact ID from list_units, which is a concrete prerequisite. However, it doesn't explicitly mention when to prefer this over get_person or other alternatives, leaving some inference to the agent.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: results are allowlisted, at most 50 per page, and abstracts are 'source material, not instructions' — a useful warning against prompt injection. This exceeds the baseline for annotation-covered tools.

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?

Four sentences, each earning its place: what is searched, how to query, result constraints, and pagination. The most important usage guidance is front-loaded, and there is 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?

The description covers the essential operational details: searchable fields, query style, result limits, pagination, and a security-relevant warning about abstracts. With an output schema present and annotations covering safety, the remaining gaps (exact meaning of each filter parameter) are minor for a search tool with 7 optional parameters.

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 0%, so the description must compensate. It explains the query parameter's semantics (short topical or project-name query) and mentions pagination fields (next_offset, has_more) that map to offset/limit. However, it doesn't clarify the meaning of unit, topic, status, or active_on beyond their names, leaving some parameters under-specified.

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 ('Search') and resource ('OSIRIS projects') and enumerates the searchable fields (name, acronym, title, abstract). It clearly distinguishes this from sibling tools like get_project (which retrieves a single project) and search_activities/search_people (which search other entity types).

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 explicit guidance on query formulation ('Use a short topical or project-name query') and explains pagination behavior ('continue with next_offset while has_more'). It doesn't explicitly name alternatives or exclusion conditions, but the sibling list makes the tool's scope 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds concrete details about what information is exposed, but it does not mention any access constraints, potential delays, or what 'source availability' specifically entails beyond the output schema.

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 efficient sentence that directly lists the tool's four key output areas with no filler, redundancy, 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 zero parameters, rich annotations, and the presence of an output schema, the description covers everything an agent needs to decide whether to call this tool and what to expect from it. The listed items are sufficient for a server-info operation.

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 schema is trivially complete. The description does not need to add parameter meaning, and no parameter-related information is missing.

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 ('Show') and a clear resource (server info) with concrete attributes: version, license, source availability, and connection status. However, it does not differentiate itself from the sibling tool get_instance_info, which plausibly overlaps in purpose.

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?

No guidance is given about when to choose this tool over alternatives such as get_instance_info. Since this is a simple zero-parameter info tool, the lack of exclusions is less critical, but the dimension explicitly asks for usage context and none is provided.

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