Two tools with minimal documentation. query_sparql has a basic description (56 chars) but lacks parameter descriptions and output schema documentation. get_repository_info has no parameters but also lacks output schema details. Neither tool documents what fields are returned, making it difficult for LLMs to plan downstream operations. No error handling guidance, no input validation constraints, and no mention of prerequisites or when to use each tool. Naming is acceptable (verb_noun pattern), but descriptions fall short of the 50-200 char LLM-optimized range and lack context about return values.

• Add a detailed description to the 'query' parameter: 'A valid SPARQL SELECT, CONSTRUCT, ASK, or DESCRIBE query. Must include proper PREFIX declarations for any custom namespaces. Example: SELECT ?s ?p ?o WHERE { ?s ?p ?o } LIMIT 10'
• Document the output schema for query_sparql: 'Returns a JSON object with head (variable names) and results (array of bindings). Each binding maps variable names to objects with type, value, and optional datatype/language fields.'
• Add error handling guidance to both tools: 'If the query fails, check syntax and PREFIX declarations. If the endpoint is unreachable, verify GRAPHDB_ENDPOINT and network connectivity. If authentication fails, ensure GRAPHDB_USERNAME and GRAPHDB_PASSWORD are set correctly.'
• Expand tool descriptions to 100-150 chars explaining when to use each: 'query_sparql: Execute SPARQL queries to retrieve or modify RDF data. Use for complex graph traversals, aggregations, or pattern matching. get_repository_info: Retrieve metadata about the connected repository (endpoint, name, auth status) before executing queries.'
• Add a parameter description for get_repository_info output: 'Returns endpoint URL, repository name, authentication status, and available graphs. Use this to verify connectivity before running queries.'