Query a CSV: select/filter/sort/limit. One of url or csv.
| Name | Required | Description | Default |
|---|---|---|---|
| csv | No | Raw CSV (alt. to url). | |
| url | No | CSV URL (alt. to csv). | |
| limit | No | Default 500, max 5000. | |
| filter | No | 'col op value'. | |
| format | No | Default json. | |
| select | No | Columns, comma-separated. | |
| headers | No | Headers to forward (Authorization, Cookie…). | |
| sort_by | No | Sort column. | |
| sort_dir | No | Default asc. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / csv / descriptionAdded value: +"Raw CSV (alt. to url)."Input schema / properties / format / descriptionAdded value: +"Default json."Input schema / properties / headers / descriptionAdded value: +"Headers to forward (Authorization, Cookie…)."Input schema / properties / limit / descriptionAdded value: +"Default 500, max 5000."Input schema / properties / select / descriptionAdded value: +"Columns, comma-separated."Input schema / properties / sort_by / descriptionAdded value: +"Sort column."Input schema / properties / sort_dir / descriptionAdded value: +"Default asc."Input schema / properties / url / descriptionAdded value: +"CSV URL (alt. to csv)."Input schema / properties / headersAdded value: +{
+ "type": "object"
+}Input schema / properties / csv / descriptionRemoved value: -"Alt. to url: raw CSV text to query. Provide this OR url, not both."Input schema / properties / url / descriptionRemoved value: -"URL of a CSV to fetch (http:// or https://). Provide this OR csv, not both."Input schema / properties / csv / descriptionAdded value: +"Alt. to url: raw CSV text to query. Provide this OR url, not both."Input schema / properties / url / descriptionAdded value: +"URL of a CSV to fetch (http:// or https://). Provide this OR csv, not both."Input schema / properties / csv / descriptionRemoved value: -"Raw CSV text (alternative to url)."Input schema / properties / filter / descriptionPrevious value: -"Row filter expression: 'column op value'. Operators: = != > >= < <= contains startswith endswith. E.g. 'age > 30' or 'country = US'."New value: +"'col op value'."Input schema / properties / format / descriptionRemoved value: -"Output format: 'json' (default) or 'csv'."Input schema / properties / limit / descriptionRemoved value: -"Maximum number of rows to return (default 500, max 5000)."Input schema / properties / select / descriptionRemoved value: -"Comma-separated column names to include (e.g. 'name,age,country'). Omit to include all columns."Input schema / properties / sort_by / descriptionRemoved value: -"Column name to sort by."Input schema / properties / sort_dir / descriptionRemoved value: -"Sort direction: 'asc' (default) or 'desc'."Input schema / properties / url / descriptionRemoved value: -"URL of the CSV file to fetch (http/https)."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds that the tool supports select/filter/sort/limit and requires a URL or CSV, which is useful but not deep. It does not disclose network behavior, timeouts, or response size limits beyond what the schema specifies. With annotations covering the read-only aspect, this is adequate but not exceptional.
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 short sentences front-load the purpose and include the key input constraint. Every word earns its place with no fluff. The phrase 'One of url or csv' is unambiguous and important.
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 9 parameters and no output schema, the description provides the essential high-level operations and input requirement. The schema covers all parameter details, so the description effectively serves as a purpose and input guide. It could mention the output format, but that is already available via the 'format' parameter. Overall, it is complete enough for accurate tool invocation.
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 baseline is 3. The description adds the crucial constraint that exactly one of 'url' or 'csv' must be provided, which is not explicitly required in the schema. This relationship adds semantic value beyond the individual parameter descriptions.
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 the verb 'Query' and the resource 'CSV', then enumerates core operations (select/filter/sort/limit). This clearly distinguishes it from sibling tools like json_query or fetch_html. The 'One of url or csv' qualifier further clarifies the input forms.
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: use when you need to query CSV data with operations like filtering and sorting. It provides an input requirement (one of url or csv) but does not explicitly state when not to use it or mention alternative tools. 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.
Add one secure layer between your agents and this server.
Several tools overlap in fetching and processing web content (fetch_extract, fetch_html, fetch_metadata, html_to_markdown), which could confuse an agent. However, descriptions clarify output types, so most tools are distinguishable.
Names follow mixed conventions: verb_noun (fetch_html, remove_background), noun_verb (csv_query, rss_parse), and noun_noun (tool_catalog, screenshot_url). Each name is descriptive, but the lack of a consistent pattern makes it harder to guess tool names.
With 17 tools, the count is slightly above the ideal 3-15 range but still manageable. The inclusion of 5 meta-tools (pricing, tool_catalog, task_recipes, memory_snippet, use_tool) inflates the count but serves a discovery purpose.
The toolkit covers a broad range of web and data tasks (fetch, parse, query, convert, image, SEO). Minor gaps exist (e.g., no OCR, no image editing), but use_tool can dynamically access additional tools, mitigating incompleteness.