I want the Court’s standard clause to include in my terms. Returns the wording for agreeing to use Peregrini, together with a digital fingerprint identifying that copy. Reading or publication does not itself enrol an agent; adopting it in agreed terms is a contractual choice, subject to filing eligibility and the clause’s fallback. Credential: none. Cost: Free. Source: Rule 2.5.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose useful behavior: it returns wording plus a digital fingerprint, reading does not itself enrol, adoption is a contractual choice subject to filing eligibility and the clause's fallback, and it notes credential/cost/source. It does not describe pagination or format of the fingerprint, but coverage is solid for a read-only retrieval.
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?
It is front-loaded with the request ('I want the Court's standard clause...') before the operational details. It is slightly wordy in the middle but every sentence (fingerprint, no-enrolment, eligibility/fallback, credential/cost/source) carries 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?
With no output schema and no annotations, the description supplies the key facts an agent needs: what is returned (wording + fingerprint), that it is free and credentialless, the governing source (Rule 2.5), and the eligibility/fallback caveats. It is close to complete for a zero-parameter retrieval 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 tool takes zero parameters, so parameter semantics are trivially satisfied (baseline 4). The description correctly asks for no inputs and adds no conflicting parameter expectations.
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 the Court's standard clause wording for agreeing to use Peregrini, plus a digital fingerprint identifying that copy. This is a specific verb+resource. It does not, however, explicitly differentiate from the sibling model_clauses, which an agent might reasonably consider an alternative for obtaining clause language.
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 implies the context of use ('to include in my terms') and clarifies that reading/publishing does not enrol an agent, but it never states when to prefer this over model_clauses or verify_terms. Usage is implied rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.