法老在线 LawBotter

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

With no annotations, the description carries the full behavioral burden. It does disclose a meaningful dependency — the sessionId must originate from a prior query/consult call — which is real context beyond the schema. However, it says nothing about whether the session state is mutated, whether the session expires, or whether the sessionId is carried forward, leaving notable gaps for an unannotated tool.

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

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

Front-loads the purpose and the dependency before listing parameters, and the whole text is two compact sentences. The parameter recap is largely redundant with the schema, costing a little density but not readability.

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 two-parameter, no-annotation, no-output-schema tool, the description covers the purpose, prerequisite, and inputs adequately. It omits what the call returns (whether a new sessionId is issued, how the continued conversation is represented), which matters when no output schema exists to fill that gap.

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

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

Schema description coverage is 100%, so both parameters (sessionId, question) are already documented in the schema, including the note that sessionId comes from query/consult. The description merely restates this and marks both as 必填, adding no syntax, format, or validation detail. Baseline 3 applies when the schema does the heavy lifting.

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 action (追问/follow-up) on a specific resource (an existing session) and names the two sibling tools whose sessionId it depends on. An agent can distinguish this from lawbotter_law_query and lawbotter_legal_consult without opening any 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?

Explicitly says it is used on a sessionId returned by lawbotter_law_query or lawbotter_legal_consult, so the prerequisite and the trigger condition are clear. It does not state any exclusions (e.g. when a fresh query is preferable over a follow-up), so it stops 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that answers are generated from database retrieval, that empty/uncertain results should be reported honestly, that anonymous calls are quota-limited, and that usageStatus.remaining shows remaining calls—behavioral context beyond the 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?

Front-loads the purpose, then uses clear labels 参数/返回/注意 for parameters, return values, and caveats. No wasted sentences; every part adds useful 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 no output schema and no annotations, the description helpfully lists return fields (sessionId, content, usageStatus) and quota caveats. It stops short of distinguishing sibling tools or explaining error/quota-exhaustion behavior, so it is solid but not fully 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 description coverage is 100% for the single keyword parameter, and the description adds no meaning beyond the schema; it merely restates that keyword is required with the same example. Baseline 3 applies.

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

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

States a specific verb+resource: 发起法规查询, and explains it searches a self-built legal database and generates an answer with legal provisions. It is clear but does not distinguish itself from siblings such as lawbotter_legal_consult or lawbotter_regulations_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?

Mentions sessionId can be used with lawbotter_followup for follow-up questions and notes anonymous quota limits, but gives no explicit criteria for choosing this tool over the other legal-query siblings, nor any when-not-to-use 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?

With no annotations, the description carries the full behavioral burden. It does disclose the returned fields (sessionId, answer, usageStatus), hints at an anonymous quota via usageStatus, and adds a disclaimer that results are reference-only and not formal legal advice. It says nothing about authentication requirements, rate limits, cost, or latency.

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 text is organized into labeled segments (purpose, 参数, 返回, 注意), which makes it easy to scan, and each section carries information. It is slightly dense but has no redundant 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?

With no output schema and no annotations, the description usefully documents the return payload and the sessionId-to-followup workflow, plus the legal caveat. It is close to complete for a single-parameter tool, with only quota/auth specifics left unspecified.

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% for the single parameter, and the description merely repeats the same example question already in the schema. Baseline 3 is appropriate since the schema fully documents the parameter and the description adds no new syntax or format detail.

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 and resource: initiating a one-on-one legal consultation with the 法老在线 AI advisor, backed by a multi-model racing engine. It also implies differentiation from lawbotter_followup by noting the returned sessionId is used for follow-up questions. However, it never clarifies how this differs from the sibling lawbotter_law_query, leaving one boundary ambiguous.

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 (ask a legal question) and the description explicitly routes follow-up questions to lawbotter_followup via sessionId, which is useful. There is no explicit when-not guidance or comparison against law_query / regulations_search, so the agent must infer which sibling fits a given request.

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 must carry behavioral disclosure. It explains that the tool returns the database's original regulation text/details (including article content) and that the result is traceable, which clarifies output nature and read-only intent via 获取/get. It does not mention permissions, rate limits, or side effects, but for a simple lookup this is a minor 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?

The description is front-loaded with purpose, then usage context, then parameter details and a note. It is generally efficient, though the explicit parameter list (id 必填, 字符串) duplicates what the schema already states, costing a bit of space.

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 single-parameter detail fetch with no output schema, the description supplies everything needed: what it returns, how to get the ID, and how it differs from AI interpretation. No critical information 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 100%, so the schema already documents the single id parameter, its source from lawbotter_regulations_search results, its type, and required status. The description repeats this same information (必填, 字符串, source) without adding new semantic meaning, so the baseline 3 applies.

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

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

The description states a specific verb (获取/get) and resource (单部法规的详细信息/single regulation details) and further clarifies it includes article content. It distinguishes itself from siblings by naming lawbotter_regulations_search for ID lookup and lawbotter_law_query for AI interpretation, so an agent can identify its role without opening any 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 explicitly tells the agent how to obtain the required ID (via lawbotter_regulations_search) and when to prefer an alternative: if AI interpretation is needed, use lawbotter_law_query. This gives a clear routing rule and an alternative tool, satisfying the highest bar for usage 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?

With no annotations, the description carries the full burden and does useful work: it names the returned fields (law_name, law_category, issuing_body, effective_date, status), explains that status values look like 现行有效/已废止, and discloses the 20-item default with a 100 cap plus offset-based pagination. It stops short of permissions, rate limits, or result ordering.

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?

Purpose and return-shape statements are front-loaded and earn their place, but the five-parameter recap duplicates schema text that is already at 100% coverage, adding length without new information. Structure is clean; economy is only fair.

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?

There is no output schema, and the description compensates by listing the returned fields, the status vocabulary, and pagination behavior, which is enough for correct invocation. The only gap is the missing cross-reference to lawbotter_regulations_detail for per-regulation lookups.

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 five parameters are already documented in the schema; the description's parameter recap (defaults, max, mode meanings) largely restates that text. Baseline 3 applies since the description adds examples but no semantics 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+resource (检索法规) and scopes it to a named self-built database with four enumerated categories. It also names the sibling it is not, lawbotter_law_query, so an agent can distinguish it without inspecting either 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?

Explicitly says results are for confirming whether a regulation exists and its basic attributes, and routes article-level needs to lawbotter_law_query. However it never mentions the closest sibling, lawbotter_regulations_detail, which an agent would plausibly pick for the same detail need.

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