Moyne Ross

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and a closed-world scope, so the safety profile is covered. The description adds the useful fidelity instruction to use the returned text as given rather than retyping it, but says nothing about failure modes when a paper or section is not found.

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?

Two short sentences with no waste: the core action and its scope come first, followed by the practical instruction about handling the output. Nothing is repeated or padded.

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?

With an output schema present, the description need not explain the returned citation text, and it correctly covers the paper/page duality, the optional section scoping and the available styles. What remains thin is guidance on what happens for unmatched inputs or whether a section must be an exact heading.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the accepted paper identifiers and the style enum. The description repeats the style list and confirms section-level scoping but adds no accepted-format or matching detail beyond the schema.

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

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

The description gives a specific verb and resource (return an exact citation for a paper or Technical Library page) plus the output formats, which is clearly distinct from retrieval siblings like get_paper or get_technical_page. It does not explicitly name those siblings, so an agent must infer the distinction from the word 'citation'.

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?

Usage is implied rather than stated: the agent learns this is the tool for producing references and that section-level citations are possible. There is no explicit when-to-use/when-not guidance and no named alternative for adjacent tasks such as fetching the paper itself, so the routing must be inferred.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful provenance ("from the public methodology pages"), which tells the agent the content is public and static. It does not say what happens when a requested section heading is not found, which is the main behavioral unknown.

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?

Two sentences, front-loaded with the resource names and ending with the mode semantics, with no filler. The first sentence is dense with nested parentheticals, which costs a little readability but the information is all load-bearing.

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?

With an output schema present, return values need not be described, and the safety profile is fully covered by annotations. The remaining gap is the free-text section parameter: the description never explains how headings are resolved or what an unmatched heading yields, which matters for a tool whose whole point is partial retrieval.

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

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

Schema coverage is 100%, so the baseline would be 3; the description slightly exceeds it by tying the default behavior to the summary format and describing section as "one part" of the page. However, it largely restates the enum descriptions already present in the schema and does not explain how a section heading must be matched (exact string, case sensitivity).

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 names a specific verb ("Explain") and two concrete resources (the Capital Register and the MR Index), and even glosses what each is, so an agent knows exactly what content this returns. It stops short of explicitly contrasting itself with siblings like get_technical_page or get_paper, leaving the agent to infer that this is the methodology-definition tool.

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 gives mode-selection guidance (default summary vs. format=full vs. section) which is genuinely useful for choosing how much to fetch. It offers no guidance on when this tool is preferable to sibling tools such as get_technical_page, and no stated prerequisites or 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 cover safety and idempotency, so the description's real contribution is the default response composition (question, answer, summary, limitations, anchored sections) and the standing instruction to carry limitations through. It does not say what happens when a paper identifier does not resolve, which is the notable remaining gap.

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?

Front-loaded with the retrieval action and identifier forms, then the default response, then the format modes. Dense and mostly waste-free, though the mode sentence partly duplicates the schema's own format and section descriptions.

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?

With an output schema present, the description needn't enumerate return fields, yet it usefully characterizes the summary payload and the always-present citation. It leaves out error behavior for unknown slugs and any pointer to list_papers for discovering identifiers.

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

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

Schema description coverage is 100%, so the schema already documents the identifier forms and the format enum. The only added nuance is that selecting a section returns just that section, which is a small clarification of how format and section interact rather than new meaning.

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?

"Retrieve one Capital Made Physical paper by slug, CMP number or canonical URL" gives a specific verb, a specific resource, and the accepted identifiers. It is clearly singular-retrieval, which contrasts with the listing/search siblings without naming them.

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 explains what each mode returns but never says when to reach for this tool versus cite_paper, search_research or list_papers, nor how to obtain a valid slug. Usage is implied only by the existence of the format switch.

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 establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context about the default summary contents and how the register behaves with or without a section.

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 front-loaded with the main action and then efficiently explains the two part options. It is dense but not wasteful, though a bulleted structure would make the part distinctions even easier to scan.

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 tool has an output schema and rich annotations, and the description nonetheless supplies the key content distinctions an agent needs. For a two-parameter sample-retrieval tool, 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 coverage is 100%, so the baseline is 3. The description adds meaning by naming specific summary contents such as ten-year figures and the MR Index, and by describing the fields returned for a register section, including condition, action, timing, cost and cost basis.

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 and resource: reads the sample Moyne Ross Capital Strategy and explains that identifying details are changed. It clearly distinguishes this sample strategy content from sibling tools such as get_paper and get_technical_page.

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 gives a clear use case: read the sample to see what such a strategy contains. It does not explicitly exclude alternatives, but the scope is sufficiently clear that an agent can select it for sample strategy content.

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 read-only, idempotent, non-destructive and closed-world, so the safety bar is low; the description adds genuinely new behavior — that a ready citation is always included, that 'cost-shape' is never a price, and the important epistemic caveat that it describes general element behavior, not a specific building's condition, and that its limitations must be carried through.

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 core purpose is front-loaded, but the rest is one immense run-on sentence cramming a dozen content domains, format semantics and a disclaimer together, with the caveat buried at the end where it is easy to skim past.

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?

With a full output schema and complete parameter descriptions, the description only needs to cover scope and caveats, which it does: content coverage, citation inclusion, jurisdiction coverage and the general-vs-building-specific limitation. It is complete, just badly packaged.

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

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

Schema description coverage is 100%, so the baseline is 3; the description restates the two formats and enumerates section ids that the schema already lists, adding only the qualifier that cost-shape is a shape rather than a price.

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?

Opens with a specific verb and resource ('Retrieve one Technical Library page by slug, element name or canonical URL') and then enumerates the page's content domains, so an agent can distinguish it from list_technical_pages or the paper/method siblings without opening the schema.

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 explains the default/modified retrieval modes ('By default a summary...; section returns one section, format full the whole page'), which is useful usage guidance, but it never states when to prefer this over a sibling like list_technical_pages or search_research, nor any when-not conditions.

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 and that nothing is destroyed, so the safety profile is covered. The description adds genuinely new behavioral context: results come back a page at a time and the response includes nextCursor for continuing, which is the paging contract an agent needs. It stops short of stating the default page size or what nextCursor looks like when the list is exhausted.

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?

One dense, front-loaded sentence that leads with the action and resource before the paging caveat. The trailing enumeration of returned fields is somewhat redundant given an output schema exists, but it is compact and does not obscure the primary instruction.

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?

With an output schema present, the return-value list is optional garnish, and the essential facts — ordering by reading order, optional part scoping, cursor-based paging — are all present for a three-parameter read tool. The only real omission is guidance on the undocumented limit parameter and terminal-page behavior.

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

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

Two of three parameters are documented in the schema (part enumeration, cursor meaning), giving 67% coverage, and the description largely restates those same facts. The 'limit' parameter is undocumented in both schema and description, and no added guidance is given on sensible paging sizes or the 25 maximum.

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?

States a specific verb (List) plus a precise resource (the Capital Made Physical papers) with scope modifiers: 'in reading order, a page at a time, optionally for one of the seven parts (I to VII)'. This clearly separates it from get_paper (single record) and search_research (query-driven lookup) 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 conveys the browse/paging workflow by naming the part filter and the continuation cursor, which implies when to use it. But it never states when to prefer search_research or get_paper instead, nor any prerequisite for starting pagination without a cursor — the reader must infer that an absent cursor means page one.

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?

Read-only, idempotent, non-destructive, closed-world are already declared by annotations, so the bar is lower. The description goes beyond them by disclosing ordering (Building Check Framework, Substructure to Environmental), pagination semantics (nextCursor) and the shape of returned data, including side payloads like framework sections and the severity scale that an agent would not otherwise anticipate.

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 dense sentence that is front-loaded with the verb and resource, then layers ordering, pagination, filters and return fields. Packed but orderly; slightly list-heavy, and the long clause chain takes effort to parse, but no sentence is wasted.

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?

An output schema exists, yet the description usefully summarizes the fields (title, section, short answer, canonical URL) plus the framework sections and severity scale, and explains pagination via nextCursor. For a 4-parameter read tool with annotations, what remains missing is explicit routing to the sibling get_technical_page and the meaning of limit.

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 75%: limit has no description at all (only default 15 and max 50), while cursor, section and page_type are documented in the schema. The description adds the concept of one section or page type filtering and mentions nextCursor, but adds no new syntax, matching behavior, or default/cap detail for limit beyond the schema.

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

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

States a specific verb and resource (list the Moyne Ross Technical Library pages) and explains what the collection contains: one page per building element and functional space, ordered by the Building Check Framework. It distinguishes itself implicitly from get_technical_page (singular fetch) but never names that sibling or explains the split.

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?

Usage is implied by the description ('a page at a time', 'optionally for one section or page type'), which suggests browsing and narrowing. There is no explicit when-to-use/when-not guidance and no reference to get_technical_page or list_papers as alternatives, so an agent must infer that this is the enumeration tool and get_technical_page the single-page tool.

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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is lower, and the description still adds real behavior: ranked results with canonical URLs, a match strength showing matched and missing words, and the important caveat that weak matches are background only. It does not say whether snippets are full text or whether get_paper is needed to read a hit, which is the remaining gap.

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?

Front-loaded with the verb, resource and corpus inventory, then the use domains, then the scoping rule and the return behavior. The long domain list reads partly as retrieval keyword padding, but each item is a plausible user topic, so little is genuinely wasted.

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?

An output schema exists, so return shape need not be explained, and annotations carry the safety profile; the description covers purpose, routing, scope guidance and the weak-match caveat. The one missing piece is the handoff to siblings — it never says to use get_paper, get_technical_page or cite_paper after a hit, leaving the agent to infer the next step.

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 75% and both enum parameters are already described in the schema, so the baseline is high. The description still adds meaning beyond the schema by explaining the operational consequence of the scope value: a question about one element or system should be scoped to the technical library alone, which tells the agent how to set the parameter rather than just what its values are.

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?

States a specific verb (search) plus the exact resource (the public Moyne Ross corpus) and enumerates its constituent parts: 49 Capital Made Physical papers, the 103-page Technical Library, the Capital Register and MR Index methodology, and a sample Capital Strategy. An agent can tell this apart from get_paper, list_papers and get_technical_page, which fetch or enumerate rather than search.

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

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

Gives concrete when-to-use domains (capital planning, lifecycle and condition, obsolescence, refurbish or redevelop, energy and solar, leases and make good, due diligence, AU/UK/US markets) and an explicit narrowing rule: for a single element or system, scope technical searches to the library alone. It also states a boundary condition, 'General research: it does not assess a particular building,' which tells the agent when this tool is not the right answer.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds genuine context beyond that: 'Nothing is sent: the person opens the link, checks the form and sends it themselves,' which tells the agent the server performs no submission and the human must complete the handoff. Link expiry or reuse behavior is not covered, which keeps it off a 5.

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 short sentences, front-loaded with what is returned, then the usage condition, then the side-effect caveat. Every sentence carries distinct information and none repeats the title or the annotations verbatim.

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?

An output schema exists, so the link return value needn't be explained, and the annotations cover the safety profile. The remaining gap is the four undocumented parameters and the mild tension between 'commercial or multi-unit building' and enum values such as 'portfolio' and 'other'; otherwise an agent has what it needs to call this 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 coverage is 43% across seven parameters; only building, type and note carry descriptions in the schema. The description adds the unifying principle that every field is a prefill of 'the details the person has given,' which implies none should be guessed or invented, but it does not clarify the role enum (which includes 'home') or the organisation/email fields. Baseline 3 is appropriate here.

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 concrete verb and artifact — 'Returns a link to the Moyne Ross request form' — plus the scope ('one actual commercial or multi-unit building') and the prefill behavior ('with the details the person has given filled in'). No sibling tool produces a request link, so an agent can separate this from get_sample_strategy or working_with_moyne_ross without opening a schema.

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 gives an explicit trigger ('Use only when the person asks to request a Capital Strategy') and an explicit input constraint ('only with details they have provided'), which is exactly the guardrail needed against fabricated prefill values. It stops short of naming a sibling to use instead when the person merely wants information about Capital Strategy, so alternatives must be inferred.

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, non-destructive and closed-world, so safety and state behavior are fully covered by structured data. The description adds only a table of contents for the content returned (three stages, release terms, FAQs), with no note on authority, currency, or whether this is static marketing copy versus binding policy. With annotations carrying the behavioral burden, 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.

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

A single sentence, front-loaded with the resource and its contents, closing with the invocation condition. No filler, no repetition of the title, nothing that could be trimmed without losing meaning.

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

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

For a zero-argument, read-only informational tool with an output schema, the description covers everything needed to select and call it. The only residual gap is the absence of a boundary statement separating it from content-oriented siblings, which matters slightly because 'Capital Strategy' and 'technical page' overlap in vocabulary.

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 takes no parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline of 4 applies; no parameter discussion is needed.

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 scopes the resource: factual content on how Moyne Ross engagements work, enumerated as client/geography coverage (commercial and multi-unit property in Australia, the UK and the US), the three stages, Capital Strategy release terms, and common questions. That is far more specific than the name alone. It does not, however, explicitly contrast itself with siblings like get_sample_strategy or get_technical_page, which could plausibly be confused with 'terms on which a Capital Strategy is released'.

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?

'Use when the person asks about engaging Moyne Ross' gives an explicit trigger condition tied to the user's intent. There are no stated exclusions or pointers to alternative tools for adjacent questions (e.g., what a Capital Strategy contains vs. how to obtain one), so routing rests on the agent's own inference.

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