Cribalo research MCP (decoy)

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

Provides substantial detail beyond the annotations: the call is logged with time, hashed IP, client, tool, arguments and purpose, nothing is executed, and all data is synthetic. This is consistent with readOnlyHint=true and openWorldHint=false and tells the agent exactly what side effects (none) and observability (full logging) to expect.

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

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

Front-loaded with the most decision-relevant fact (it does not execute), followed by the logging disclosure and a reference link. Every sentence carries weight; only the bare URL feels slightly tacked on rather than integrated.

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 three-required-parameter stub tool with no output schema, the description covers the essential facts: no execution, synthetic data, and full logging. It stops short of hinting what a simulated response contains, which would fully close the loop for an agent expecting a result.

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 descriptions for code, purpose (explicitly noted as logged) and an enum for language, so the schema already carries the semantics. The description reinforces that arguments are logged but adds no format or constraint detail beyond that, so the baseline of 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 opens with a specific verb and resource ('Pretends to run a script') and immediately negates the naive expectation ('it never executes anything'). That framing clearly separates it from read-only siblings such as query_database and read_file, which the agent might otherwise prefer for code-like tasks.

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

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

Usage is implied rather than prescribed: the agent learns this is a simulated execution surface, but nothing states when to choose it over query_database or fetch_url, nor any exclusions. It is adequate but leaves the sibling-routing decision to inference.

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?

Substantial value beyond the annotations: it discloses that no network call is made, that calls are logged (time, hashed IP, client, tool, arguments, purpose), that nothing is executed, and that all data is synthetic. These are exactly the privacy and side-effect facts an agent cannot get from readOnlyHint/openWorldHint alone, and they are consistent with those hints.

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 key caveat ('pretends to fetch', 'never contacts the URL') is front-loaded and the whole thing is four short clauses with no filler. The trailing documentation URL is slightly extraneous but harmless.

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, the description should say what a caller receives back from a simulated fetch — an empty result, a canned page, an error — and it does not. It covers the safety and logging model well but leaves the return behavior and the intended research use case underspecified.

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 both url and purpose are already documented in the schema; the baseline of 3 applies. The description adds only marginal semantics, notably that 'purpose' is logged along with the arguments, which explains why it is required.

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 verb and resource ('fetch a web page') but immediately negates it with 'Pretends to' and 'never contacts the URL', leaving the agent unsure what the tool actually accomplishes or returns. It does not differentiate itself from siblings such as read_file or search_documents, which an agent might reasonably consider alternatives.

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?

There is no statement of when to use this tool versus the siblings, nor when not to. The mention of 'Research server' and the logging/purpose parameter imply a simulated-research context, but the agent must infer whether this is appropriate for real lookups or only for demonstrations.

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 only declare readOnlyHint and openWorldHint, but the description adds substantial context those annotations cannot convey: results are synthetic placeholders, nothing is executed, and every call is logged with time, hashed IP, client, tool, arguments, and purpose. That logging disclosure is exactly the kind of behavioral trait an agent should know before invoking. The only gap is that the return value's shape is never described.

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 compact sentences with the core function front-loaded, followed by the operational disclosures. The parenthetical caveat sits immediately next to the claim it qualifies, and the documentation link is a single trailing clause rather than 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 three-parameter read-only tool with no output schema, the description covers safety, data provenance, and logging obligations. The one omission is the format of the returned rate (scalar vs. object, precision), which an agent would need since there is no output schema to consult.

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 currency codes and the 'purpose' parameter fully documented in the schema itself, so the baseline is 3. The description adds no additional meaning about parameter formats, case sensitivity, or valid code handling beyond 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?

States a specific verb and resource ('Return a placeholder exchange rate between two currencies') and explicitly disqualifies the result as real market data. It does not need to differentiate from a sibling since none of the other tools (execute_script, fetch_url, query_database, read_file, search_documents) overlaps, so sibling differentiation is moot rather than missing.

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 parenthetical 'not real market data' implicitly tells the agent not to rely on this for real financial calculations, which is useful usage guidance. However, there is no explicit statement of when to prefer this tool or what to do instead, and no prerequisites beyond the required 'purpose' argument enforced by the schema.

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 and openWorldHint=false, and the description stays consistent with that while adding genuinely new information: calls are logged with time, hashed IP, client, tool, arguments, and purpose, and all data is synthetic. The logging disclosure is exactly the kind of behavior annotations cannot convey, though the result format and row-limit behavior are not described.

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

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

The core capability is front-loaded in the first clause, followed by logging disclosure and a docs link. It is compact, but the "Nothing is executed" clause is ambiguous enough to cost clarity rather than save 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?

There is no output schema, so the description should carry more of the return-shape burden, and it never says what columns 'customers' contains or what a result looks like. For a SQL tool, the missing table schema is a real obstacle to writing a correct query, even though the logging and synthetic-data disclosures are solid.

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 the schema already documents both 'sql' and 'purpose', including that purpose is logged for research. The description adds the research-logging context but no new syntax guidance, length limits, or dialect hints for the SQL string, so it sits at the baseline.

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

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

The description names a specific verb and resource ("Run a read-only SQL query") and narrows scope to a single synthetic table, 'customers'. It is clearly distinguishable from execute_script and fetch_url, though it never names those siblings as alternatives.

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: query the 'customers' sample table when you need structured data rather than fetching a URL or running a script. There is no explicit when-to-use/when-not-to-use statement, and the phrase "Nothing is executed" muddies whether the query actually runs, which an agent could misread as a no-op.

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 declare readOnlyHint=true and openWorldHint=false, and the description stays consistent while adding real value beyond them: calls are logged with time, hashed IP, client, tool, arguments and purpose; nothing is executed; all data is synthetic. That is precisely the behavioral context an agent needs before invoking a no-op tool. It loses a point only for not saying how a call completes or what a response looks like.

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 compact sentences plus a reference link, with the most important disclaimer ('this server has no file system') front-loaded right after the verb. No filler or repetition; the trailing URL is the only arguably non-essential element.

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 stub with no output schema and full schema coverage, the definition covers purpose, safety, logging, and data provenance well. The remaining gap is return-value behavior, which is somewhat more than a minor omission given there is no output schema to fall back on.

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 'path' and 'purpose' are already documented, including the note that purpose is logged for research. The description's mention of logged 'arguments' and 'purpose' only restates what the schema provides, so 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 and resource ('pretends to read a file') and immediately clarifies the decisive fact that this server has no file system, which tells an agent this is a simulated call. It falls short of 5 because it never says what a call actually returns (fake content, an error, or a stub acknowledgement), which is the one thing an agent still needs to know.

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 framing as a research/simulation tool implies when to call it (harness or logging exercises), but there is no explicit when-to-use or when-not-to-use guidance relative to siblings like fetch_url, query_database, or search_documents. The agent must infer that this tool will never satisfy a genuine file-reading need.

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 and openWorldHint=false, and the description adds meaningful context beyond those: calls are logged with specific fields, nothing is executed, and all data is synthetic. It does not explain result format or pagination, but the behavioral disclosure is strong for a read-only search 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 compact and front-loads the primary purpose before adding logging and safety context. The details URL is slightly extraneous but does not obstruct the core message.

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 search tool with no output schema, the description covers safety, logging, and data provenance but omits what results look like and how limit affects them. The essential behavioral context is present, though operational details are incomplete.

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 67%: query and purpose are described in the schema, while limit is undocumented there. The description adds no parameter semantics, so the schema does most of the work with a remaining gap around the limit parameter.

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: 'Search a small index of sample documents.' An agent can identify the operation and scope, though it does not distinguish this from siblings such as query_database or read_file.

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?

No guidance is given about when to choose this tool over alternatives like query_database or read_file. The research-server note provides context about the environment but not selection criteria.

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