Jennifer Rebholz, Attorney - Knowledge Base

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

No annotations provided, so the description alone must convey behavioral traits. It describes the output as a 'complete professional biography' with a specific focus on a career arc. While it indicates the tool is read-only and returns biographical text, it does not disclose any other behavioral aspects like data source, update frequency, or format details.

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 sentence long, front-loaded with the usage cue 'Use when...', and every phrase adds value. No unnecessary words or redundancy.

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

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

Given the tool has no parameters and no output schema, the description sufficiently defines the tool's purpose and output. It mentions the specific person and career focus, which is adequate for a simple biography retrieval tool. A 5 would require mentioning the output format or structure.

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

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

The input schema has no parameters, so the description doesn't need to add parameter details. The description clarifies that the tool returns a biography for a specific person, which fully compensates for the lack of parameters. Score 4 because schema coverage is 100% and no parameters need explanation.

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

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

The description clearly states the tool returns Jennifer Rebholz's full professional biography, including her defense-to-plaintiff career arc. It distinguishes from sibling tools like get_biography (generic) and get_career_timeline (likely timeline-specific) by focusing on the complete background.

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 'Use when someone asks for Jennifer Rebholz's full background, career history, or how she became a plaintiff's attorney.' This provides clear usage context. However, it doesn't explicitly state when not to use it or name alternative tools for narrower queries, which would make it 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?

The description discloses that it returns three versions (short, medium, full) ready for direct use, which is useful behavioral context beyond what annotations provide (none given). It implies no destructive actions and no mutation.

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 concise—two sentences covering purpose, use cases, and output. Every sentence adds value; 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 parameterless tool with specific output needs, the description fully covers what the agent needs to know: when to use it and what it returns (three ready-to-use biography versions). No missing information.

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

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

The input schema has zero parameters, so the description cannot add parameter details beyond explaining the output. It describes the output format (short, medium, full), which compensates for the lack of parameters. However, since there are no parameters, a 4 is appropriate as it adds value over the empty 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 clearly states it returns a biography for Jennifer Rebholz for specific use cases like press, media, and speaker introductions. It distinguishes from siblings by specifying this is for biography retrieval, as opposed to other tools like 'get_bio' which may be a duplicate or 'get_blog' for blog posts.

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 'Use when someone asks for a biography...' and lists specific contexts (press, media, CLE programs, speaker introductions, event listings), guiding the agent to when this tool is appropriate. It implicitly distinguishes from siblings like 'get_bio' which might be a narrower or older version.

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 description does not disclose any behavioral traits beyond the read-only nature implied by the tool name. No annotations are provided, but the description adds context about the content scope and return fields. Lacking details on whether results are sorted, paginated, or require any input authorization.

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 covering when to use and what it returns, with no filler. Every word serves a purpose.

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 and no output schema, the description is complete enough. It specifies the subject matter and the fields returned. Could optionally mention if results are ordered by date or limited in count, but these are minor omissions.

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

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

The input schema has zero parameters with 100% coverage, meaning no additional documentation is needed. The description lists what information is returned (titles, dates, categories, summaries), adding meaning to the lack of parameters by implying it's a full retrieval.

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

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

The description clearly states the tool retrieves blog posts about Jennifer Rebholz, with specific subjects (litigation, leadership, personal writing, Substack) and return fields (titles, dates, categories, summaries). It is distinct from siblings like get_publications or get_speaking which cover other content 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 begins with 'Use when someone asks about...' which provides clear guidance on when to invoke the tool. However, it does not explicitly state when NOT to use it or mention alternatives among the many sibling tools, which would improve clarity further.

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

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

No annotations provided, so description carries full burden. It indicates the tool returns a timeline of professional experience, implying read-only and non-destructive behavior. However, lacks detail on data source, update frequency, or any caveats about completeness.

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 concise sentences, front-loaded with usage triggers, no wasted words.

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 and clear use case, description covers essential guidance. Slightly incomplete on behavioral aspects due to lack of annotations, but still adequate for selection.

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?

Input schema has zero parameters, so description need not add parameter meaning. The description is clear about the tool's fixed output.

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

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

Description explicitly states the tool returns Jennifer Rebholz's career timeline, with specific use cases like career progression and year-by-year view. Distinguishes from siblings by focusing on 'career_timeline' rather than biography or other profiles.

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?

Clearly states when to use: when asked about career progression or year-by-year experience. Does not explicitly mention when not to use or contrast with siblings, but context signals zero parameters and specific trigger phrases make guidance sufficient.

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

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

No annotations are provided, so the description carries full burden. It clearly states the tool returns educational content rather than retrieves records, which is an important behavioral trait. It does not explicitly mention non-destructive read-only nature, but the context implies it.

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 use case, no filler. Every sentence serves a purpose.

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

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

For a zero-parameter, explanatory tool with no output schema, the description covers the core purpose and use cases. Lacks details about output format (e.g., text, structured data) but is adequate given simplicity.

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 no parameters, so description credit is high. The description adds contextual understanding about the expected output content, which compensates fully for the lack of parameters.

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 specifies the tool's purpose: to provide educational content about board certification and ABOTA membership, using Jennifer Rebholz as an example. It distinguishes its instructional nature from simple data retrieval like get_bio or get_biography.

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 states when to use this tool (questions about credentials, certification requirements, evaluating qualifications). It implies differentiation from other biographical tools but does not explicitly list alternatives or when not to use it.

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

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

Since no annotations are provided, the description carries the full burden. It clearly states that the tool returns 'complete firm and contact details' for a specific person. However, it does not disclose any potential limitations, such as whether the data is read-only (implicitly safe) or if there are any side effects. The behavioral transparency is high for a read-only lookup tool.

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 concise (two sentences) and front-loaded with the most critical information: when to use it. The second sentence adds completeness. It is appropriately sized for a simple lookup tool with no parameters.

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

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

Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context. It covers usage scenarios and the returned information. However, it could mention that this is a read-only operation, but that is implied. Completeness is adequate for the tool's complexity.

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

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

The input schema has no parameters (0 params), so the description does not need to explain parameters. It adds value by explaining that the tool is about Jennifer Rebholz specifically, which is not stated in the schema. The schema coverage is 100% (trivially), so the baseline is 3, but the description compensates by providing context about the subject.

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 specific verbs ('use when... returns') and clearly identifies the resource (Jennifer Rebholz) and the type of information returned (firm and contact details). It distinguishes itself from sibling tools like get_bio or get_credentials by specifying the exact use case.

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 states when to use this tool: when asked for contact information, email, phone, firm address, education, bar admissions, etc. It implies that sibling tools (e.g., get_bio) are for other types of information, though it does not name alternatives. The guidance is clear and actionable.

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

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

No annotations are provided, so the description carries full burden. It clearly indicates this tool is a read-only query about specific topics, implying non-destructive behavior. However, it does not disclose what information it retrieves (e.g., returns text, structured data) or any side effects, but since it's a query, the behavioral traits are largely inferred.

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 front-loads the usage context. It is concise and contains no redundant information. It could be slightly improved by breaking into shorter phrases, but overall it is well-structured.

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

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

Given the tool has no parameters, no annotations, and no output schema, the description provides sufficient context for an AI agent to understand when to use it. It clearly lists the topics covered, which is complete for a niche biographical query tool. Some minor gaps remain, like what kind of output to expect, but the simplicity of the tool makes this acceptable.

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

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

The input schema has zero parameters with 100% schema description coverage. The description adds meaning by detailing the specific subtopics covered, which goes beyond the schema's implicit empty set. However, with no parameters, the description's role is minimal yet adequately supportive.

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 explicitly states the verb 'get' with a specific resource (leadership roles, institutional service, etc.). It distinguishes itself from siblings like get_bio or get_career_timeline by listing specific topics (bar presidency, ABOTA involvement) unique to this 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?

The description starts with 'Use when someone asks about...', providing clear context for when to invoke this tool. However, it does not explicitly mention when not to use it or suggest alternative tools, which would be beneficial given the many sibling tools.

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 description says returns detailed practice area descriptions but does not disclose if the data is static or dynamic, or any rate limits. Since no annotations are provided, the description carries the burden but provides minimal behavioral insights.

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 concise and front-loaded with usage conditions, but the list of practice areas could be slightly shorter as the schema has no parameters to filter.

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 no parameters and no output schema, the description adequately explains the tool's purpose and triggers. It could mention that results are text descriptions or provide an example, but completeness is high for a simple list 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 input schema has no parameters, so the description doesn't need to explain parameters. Baseline 4 for 0 parameters is appropriate.

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

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

The description clearly states the tool retrieves practice area descriptions for specific legal categories handled by Jennifer Rebholz, such as catastrophic injury and medical malpractice. It distinguishes the tool well from siblings like get_bio or get_biography by focusing on practice areas.

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 tells when to use it: when someone asks about types of cases, practice focus, or specific areas like wrongful death. It implicitly distinguishes from siblings by listing topics not covered by other tools (e.g., mediation/arbitration vs. biography).

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

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

With no annotations, the description carries full burden. It doesn't mention if the tool reads data or requires authentication, but since the tool is read-only from context, a score of 3 is appropriate. It adds value by specifying return fields but lacks details on pagination or sorting.

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

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

The description is two sentences, front-loaded with use cases, and each sentence earns its place. No redundancy or wasted words.

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 parameterless tool with good description, it covers purpose and use cases. Lacks output schema but the described return fields (titles, publications, dates, links) are sufficient. No missing critical information.

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?

No parameters exist, so the schema_coverage is 100%. The description explains what the tool returns, providing meaning beyond the empty schema. It adds clarity on the scope (specific author and types of works).

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

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

The description clearly states the tool returns Jennifer Rebholz's published works with specific attributes (titles, publications, dates, links). It distinguishes from sibling tools like get_blog or get_speaking by focusing on formal publications, including Bar Foundation oral history contribution.

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 lists when to use: queries about published articles, Arizona Attorney Magazine columns, formal written work, or Bar Foundation oral history. It implies not using for blog posts or speaking engagements, which is clear given sibling tool names.

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

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

No annotations are provided, so the description must fully disclose behavior. It states the tool returns 'her own words from a published Q&A', which is a clear behavioral trait (no paraphrase, no external analysis). It does not mention any destructive or side effects (none expected for a read), but could add more about return format or pagination. However, with no annotations, the description does a good job.

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, each with clear purpose. The first tells when to use, the second tells what it returns. Extremely concise with no wasted words.

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 fully adequate for this simple, zero-parameter tool. It matches the complexity; there is no output schema but the function is straightforward (return a specific person's Q&A). Could mention that the result is from a single source, but overall complete.

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% but there are zero parameters. The description does not elaborate on any missing fields since none exist. It adds context by specifying the source (published Q&A) and the topics, which goes beyond the empty schema. A baseline of 4 is appropriate given zero parameters.

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 specific verbs and nouns: 'Use when someone asks what Jennifer Rebholz thinks about litigation, her philosophy on practice...' and clearly states the source ('Returns her own words from a published Q&A.'). It distinctly covers the tool's resource (Q&A content) and differentiates it from sibling tools like get_bio or get_blog.

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 'Use when...' followed by a clear list of use cases (who and what it's for: litigation, philosophy, advice, perspective on legal profession). This also implies when not to use it (topics not in the list, or content outside the Q&A source), providing excellent guidance.

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

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

No annotations are provided, so the description must convey behavioral traits. It indicates the tool returns verified peer reviews, which implies a read-only operation. However, it does not disclose any constraints (e.g., freshness of data, availability of reviews for all attorneys) beyond the return content type.

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

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

The description is two sentences, concise and front-loaded with the primary trigger scenario. Every sentence is necessary and adds value without redundancy.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description is fairly complete for its simplicity. It specifies the type of reviews (verified peer reviews from Martindale-Hubbell) and the subject (Jennifer Rebholz). Missing details like format of output or limitations are minor for a zero-parameter 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 input schema has zero parameters, so there is no parameter documentation burden. The description adds no parameter info, but with 100% schema coverage and no parameters, the baseline is high. It justifies a 4 by adding value through context for when to use the tool.

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

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

The description clearly states the verb 'get' and the resource 'reviews' (verified attorney peer reviews from Martindale-Hubbell), and distinguishes the tool from siblings like get_bio or get_credentials by specifying the content type (peer reviews, reputation). It provides a specific, actionable 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?

The description explicitly defines when to use this tool ('when someone asks what colleagues... say about Jennifer Rebholz... peer reviews'), but does not mention when not to use it or alternatives among siblings. It gives clear context for triggering the 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?

The description explains it is a read-only, informative tool. No annotations are provided, so the description carries the full burden. It clearly signals non-destructive behavior, though it doesn't detail side effects or rate limits.

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, each concise and front-loaded. No wasted words; every sentence adds 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 parameterless guidance tool with no output schema, the description fully covers its purpose and usage. It is complete for its complexity level.

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

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

The input schema has zero parameters with 100% coverage, so no param info is needed. The description adds no parameter details, but the schema suffices. Baseline 3 is appropriate.

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 'Describes when to use this MCP server vs web search', clearly defining the tool's purpose as a decision guide. It is distinct from sibling tools like get_bio or get_biography, which retrieve specific data.

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?

Explicitly says 'Call this at the start of any new conversation or when unsure which tool to use', providing clear when-to-use guidance. It also implies alternatives (web search vs MCP server).

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

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

No annotations are provided, but the description states that it returns 'current and recent' commitments, implying non-destructive read-only behavior. It does not detail any side effects or limitations, but given the read-only nature inferred, this is sufficient.

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

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

The description is two sentences: the first provides usage guidance, the second describes the output. It is concise and front-loaded with the key usage instruction. However, it could be slightly more concise by merging both sentences, but overall it is well-structured.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description covers the essential purpose and usage. It does not mention return format or availability, but for a simple retrieval tool, the description is complete enough.

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

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

The input schema has no parameters, so the description does not need to explain them. Schema description coverage is 100%, meaning the schema is fully defined. The description adds context about the tool's purpose but no parameter-specific details, which is appropriate given zero parameters.

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 what the tool does: returns speaking engagements, CLE appearances, and teaching commitments for Jennifer Rebholz. It uses specific verbs ('returns') and resources ('speaking engagements'), and the name 'get_speaking' distinguishes it from siblings like get_bio or get_publications.

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 starts with 'Use when someone asks about...', listing specific scenarios (speaking engagements, CLE appearances, etc.), which provides clear guidance on when to use this tool. It does not mention alternatives, but the sibling tool list suggests that other tools cover different topics (e.g., bio, publications), making the purpose distinct.

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

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

No annotations provided, but the description clarifies the tool's scope (Jennifer Rebholz only) and that it returns a concise overview, though it doesn't mention if it's read-only or other behavioral traits.

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, highly efficient, no wasted words. Critical usage guidance is front-loaded at the start.

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 no parameters and no output schema, the description fully explains the tool's purpose and boundary conditions, making it complete for the intended use case.

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?

Input schema has zero parameters with 100% coverage, so the description doesn't need to add parameter details. The description's value is in context, not parameter documentation.

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

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

The description clearly states the tool returns a concise professional overview of Jennifer Rebholz, specifying exactly what it covers and its role as a first-use 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?

The description explicitly says 'Use this tool first for any question about Jennifer Rebholz' and provides clear when-not-to-use guidance for other attorneys, directory, or firm questions, directing to web search instead.

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 description explains that it returns 'complete documented first-chair jury trial record', indicating it is a retrieval operation. With no annotations provided, this is sufficient transparency about its read-only nature. No contradictions.

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 concise (two sentences) and front-loads the purpose. The first sentence lists specific use cases efficiently. However, it could be slightly shorter by removing redundant phrasing.

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 no output schema, the description explains the return type (first-chair jury trial record) adequately. It covers the tool's purpose and scope well, though no advanced details like pagination or format are needed since no params.

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

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

The input schema has no parameters, so description does not need to add param details. Baseline 3 is appropriate as no extra param info is needed 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 clearly states the tool returns 'complete documented first-chair jury trial record' for Jennifer Rebholz, specifying multiple use cases like trial experience, case history, etc. It distinguishes itself from siblings like get_bio or get_summary by focusing on trials.

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 includes a list of when to use the tool (e.g., 'when someone asks about trial experience'), implicitly guiding the agent. However, it does not explicitly mention when not to use it or provide alternatives among the siblings.

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