Thisispaper

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

Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds ordering (newest first) and filtering behavior, but does not disclose details like pagination, result format, or behavior when no projects match. This is acceptable 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?

The description is a single, front-loaded sentence with no filler. It conveys the essential purpose and filtering option efficiently.

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

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

For a simple read-only browse tool with two optional parameters and no output schema, the description provides the key ordering and filter behavior. It lacks explicit return value details, but the annotations and schema cover safety and parameter constraints, making it sufficient for basic use.

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 repeats the category values already present in the schema and adds 'newest first' context, but does not introduce new parameter meaning beyond what the schema provides.

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: lists newest projects in the archive, optionally filtered by category. The verb is implicit but the resource (archive projects) and scope (newest first, category filter) are specific, distinguishing it from sibling tools like search or discover.

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

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

The description implies usage for browsing the archive by newest first with an optional category filter, but it does not explicitly compare against alternatives like search or discover. There is no when-not-to-use guidance or mention of alternative tools for different needs.

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 and openWorldHint, which cover safety. The description adds the key behavioral detail of randomness ('at random') and the scope ('from the archive'), which is not present in annotations. No contradiction exists, and the added context is useful.

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 first sentence is crisp and functional. The second sentence is a poetic metaphor that is non-essential but adds a hint of intent. It is not wasteful enough to lower the score significantly, but it could be omitted for tighter structure.

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 absence of parameters and output schema, the description covers the core behavior: random selection from the archive. It does not specify the return format, but for a simple random picker this is acceptable. The context from sibling tools reinforces its niche.

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

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

There are zero parameters, so schema coverage is 100% by default. The description provides no parameter details, but none are needed. The baseline of 4 applies because the tool is parameterless and the description clearly conveys the selection mechanism.

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 action: 'One project chosen at random from the archive.' This clearly distinguishes the tool from siblings like get_project (targeted lookup) and search (query-based), which require parameters. The verb 'chosen' and resource 'project from the archive' are explicit.

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

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

The description implies usage for serendipitous discovery ('Editorial serendipity') but never explicitly states when to use this tool versus alternatives, nor does it exclude scenarios like needing a specific project. The guidance is implied rather than spelled out.

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 and idempotentHint, covering the safe read nature. The description adds that the response includes title, text, and public url, but does not disclose error behavior or open-world implications. It adds some value beyond annotations but not rich behavioral detail.

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, front-loaded sentence that directly states the action, input, and output. Every phrase earns its place with no 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 simple parameter set and no output schema, the description covers the core purpose and return fields. However, it does not clarify how this differs from get_project, nor does it mention error cases or the meaning of 'full record' beyond the three listed fields, leaving some gaps.

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% and the description essentially repeats the schema's hint that id comes from search. It adds no new meaning beyond what the schema already provides, so 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 uses the specific verb "Retrieve" and identifies the resource as "full record for one Thisispaper project by id," which is clear. However, it does not differentiate from the sibling tool get_project, so it misses the top score for sibling distinction.

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

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

The description gives explicit context that the id must come from a prior search result, which guides when to use this tool. It does not mention alternatives or exclusions, but the context 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?

The description discloses important behaviors beyond the annotations: the key is shown only once, implying it cannot be retrieved later. It also states the max of 3 keys per email and the free 200 calls/month quota, giving the agent a clear picture of side effects and limitations. This adds significant value beyond the annotations.

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

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

The description is two sentences, with the main action front-loaded. Every sentence adds critical information: what the tool does, how to use the key, and the quota/limit. 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?

For a simple one-parameter tool with no output schema, the description fully covers the purpose, usage, and constraints. It explains the key's format, how to authenticate with it, and the per-email limit, leaving no significant gaps for an agent to be misled.

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 already covers the 'email' parameter with a description. The tool description adds meaning by explaining that the key is tied to the email and that there is a max of 3 keys per email, which clarifies the relationship between the parameter and the tool's behavior. This goes beyond a simple restatement of 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 uses a specific verb 'Mint' and clearly identifies the resource: a free Thisispaper Intelligence API key. It also specifies the purpose (for an email address) and the rate limit, making it distinct from the sibling tools which are all about searching or fetching content.

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

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

The description provides concrete usage guidance: the key is used as 'Authorization: Bearer tip_live_...' and is limited to 3 per email. It implies this is the tool to obtain an API key, but it doesn't explicitly state when not to use it or mention alternatives. Still, the context is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by enumerating what the metadata includes (machine-written description, design language, details/dimensions, public URL), which is useful context beyond the schema. No contradictions with annotations.

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

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

The description is a single, information-dense sentence that front-loads the core action and follows with specific metadata fields. Every word contributes, with no redundancy or filler.

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

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

For a simple single-parameter retrieval tool with strong annotations, the description is sufficiently complete. It clearly lists the return contents, and the absence of an output schema is compensated by this enumeration, making the tool fully understandable.

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 fully describes the sole parameter 'slug' with an example, achieving 100% schema description coverage. The description does not add additional parameter semantics beyond implying the slug identifies the project, so it meets the baseline but does not exceed it.

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: 'Full metadata for one project', clearly indicating a retrieval operation for a single project. It distinguishes from siblings like search_projects and similar_projects by emphasizing 'one project' and enumerating the metadata contents.

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

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

The phrase 'Full metadata for one project' implies use when a single project's complete metadata is needed, likely by slug. It provides clear context but does not explicitly mention alternatives or exclusionary cases, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so safety is clear. The description adds value by explaining the return fields (title, type, description, cover image, public URL) and the restriction that full guides/editions are for members, which is useful for agent decision-making.

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 well-structured and front-loaded with the main purpose, followed by content examples, return fields, and access caveat. Although it includes several examples, each sentence is informative and not wasted, though a slight trim could improve brevity.

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?

Without an output schema, the description adequately covers return fields, filtering, and access restrictions. It also enriches the context by explaining the difference between guides and editions, making the tool fully understandable in a single read alongside the annotations.

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 parameters are fully documented structurally. The description adds minimal extra meaning by mentioning 'Filter by city or by type' and clarifying that city applies to guides, but this does not significantly exceed what the schema already states.

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 'Lists' guides and editions, specifies the exact content (places like Tokyo, themes like Jutaku), and differentiates from siblings by focusing on a curated catalog. It names the resource and the action, making the purpose unambiguous.

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

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

The description implies when to use this tool: to fetch a list of all guides/editions with optional filters, and notes a membership restriction for full content. It does not explicitly contrast with sibling tools like 'discover' or 'search', but the intent is clear from the context.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds the return format (list with id, title, url) which is useful, but does not disclose other behavioral traits such as result limits or pagination. No contradiction with annotations.

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

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

The description is two sentences, front-loaded with the action, and contains no filler. Every word adds value, making it highly concise and 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 simplicity of the tool (one parameter, no output schema), the description is complete enough: it specifies what the tool does, the domain, and the return format. Annotations cover safety and side effects. Minor missing details like filtering or limits do not degrade utility.

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% and includes examples for the query parameter. The tool description does not add any additional meaning about parameters, so a baseline of 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 clearly states the tool searches a curated collection of projects from Thisispaper and returns a list with id, title, and url. It is specific about the resource and action, though it does not explicitly differentiate from sibling tools like search_projects.

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

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

The description implies the tool is for searching within the Thisispaper curated collection, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention exclusions. Usage context is clear but not elaborated.

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 behavioral details beyond the annotations: results are 'ranked by how many dimensions match, then by recency.' It also explains the provenance of the tags ('written during human curation'), which is not present in the schema or annotations.

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

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

Two sentences, front-loaded with the main purpose, no redundant wording. The uniqueness note and ranking rule earn their place.

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

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

The description covers purpose, constraints, ranking, and uniqueness. However, it does not explicitly state what kind of results are returned (e.g., projects, items), relying on context from the tool name and siblings.

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 description adds a global requirement ('Provide at least one dimension') and explains how multiple parameters interact ('ranked by how many dimensions match'). Since the schema already covers all 7 parameters at 100% with descriptive examples, the description provides useful supplemental context, but no per-parameter details.

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 'Search by taste metadata' and enumerates the specific dimensions (material, light, color, mood, composition, subject). It also distinguishes from generic search by highlighting 'Unique to Thisispaper: these tags were written during human curation.'

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 provides a clear usage constraint: 'Provide at least one dimension' and explains ranking behavior. It indicates uniqueness compared to other search tools but doesn't explicitly name alternatives or exclusion 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?

The description adds meaningful behavioral context beyond the annotations: the API key cap ('Without an API key, results are capped at 5'), the requirement to pass an Authorization header, and the specific output fields for ranked summaries. This informs the agent about potential limitations and authentication needs. Annotations already declare read-only, non-destructive, and idempotent behavior, and the description does not contradict these.

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 long and front-loaded. The first sentence states the purpose and scope, and the second sentence efficiently conveys return fields and the critical API key constraint. There is no redundant information or filler; every word contributes to understanding.

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

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

Given the lack of an output schema, the description compensates by listing the return fields. It also covers the API key requirement and scoping. However, it does not explain pagination, ordering (beyond 'ranked'), or how the limit parameter interacts with the API key cap, leaving minor gaps. Still, it is largely complete for a search tool with simple parameters.

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

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

Schema coverage is 100% with both parameters (query and limit) already described accurately in the schema. The description does not add additional parameter semantics; it merely mentions the overall result format. Given high schema coverage, the baseline of 3 applies, and the description provides no extra value for parameter understanding.

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's function: 'Search 2,500+ hand-curated architecture, design, photography and art projects from Thisispaper.' It specifies the resource (Thisispaper projects) and the action (search), and lists return fields. This distinguishes it from generic siblings like 'search' and 'browse' by clearly scoping to Thisispaper's curated project database.

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

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

The description implies when to use the tool: to search Thisispaper's curated project collection. It notes that without an API key results are capped at 5, and suggests providing Authorization for full results, which is practical guidance. However, it does not explicitly state when not to use it or mention alternatives like 'search_by_taste' or 'discover', so it lacks explicit 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?

The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful context by stating results are 'precomputed SigLIP neighbours', implying results may be static and not include very recent projects, and specifying the similarity dimensions.

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 fits in one sentence, front-loads the core purpose, and efficiently includes the algorithm and input source without any redundant text.

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

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

For a simple read-only retrieval tool with good annotations and full schema coverage, the description adequately covers what it does, how to get the slug, and the nature of the results. It doesn't describe return format, but the absence of an output schema and the simplicity of the tool make 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 fully describes both parameters (slug and limit), so the baseline is 3. The description adds value by telling the agent to take the slug from search_projects results, which is a crucial semantic hint 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 identifies the resource ('projects') and the method ('visual + semantic similarity'), and differentiates the tool from siblings by referring to the slug from search_projects. However, it lacks an explicit verb like 'retrieve' or 'list', relying on the title and context to imply the action.

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 to use slugs from search_projects results, which gives clear context for when this tool is appropriate. There is no explicit comparison to alternatives or 'when not to use', but the input requirement narrows the use case sufficiently.

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